[Libwebsockets] libwebsocket problem

Wei, Catherine catherine.wei at commscope.com
Thu May 23 08:32:40 CEST 2019


Thanks, the api that you offered works in my case mentioned in my early email. Calling it when I disconnect the connection from server side will disconnect the connection and also send callback to the server in my case.

However, in another case, I found that when a client request a connection, the websocket server will receive a callback to handle the new connection. When the server handles the new connection, it rejects the connection directly by the api lws_set_timeout(). At this time, when I disconnect the connection from the server side using api lws_set_timeout() when the client request a connection will lead to libwebsocket crash.
The process in detail:
1,Client request a connection   ->libwebsocket   
2.Server HandleNewConnection callback, and call "lws_set_timeout()", then the process of websocket server will report segment fault error like follow:


Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7f4b498 in lws_process_ws_upgrade (wsi=wsi at entry=0x42e240) at ../libwebsockets-3.0.1/lib/roles/ws/server-ws.c:372
372    ../libwebsockets-3.0.1/lib/roles/ws/server-ws.c: 没有那个文件或目录..
(gdb) bt
#0  0x00007ffff7f4b498 in lws_process_ws_upgrade (wsi=wsi at entry=0x42e240) at ../libwebsockets-3.0.1/lib/roles/ws/server-ws.c:372
#1  0x00007ffff7f5321b in lws_handshake_server (wsi=wsi at entry=0x42e240, buf=buf at entry=0x7fffffffd4a8, len=<optimized out>, len at entry=227) at ../libwebsockets-3.0.1/lib/roles/http/server/server.c:1627
#2  0x00007ffff7f47795 in lws_read_h1 (wsi=wsi at entry=0x42e240, buf=<optimized out>, len=227) at ../libwebsockets-3.0.1/lib/roles/h1/ops-h1.c:75
#3  0x00007ffff7f47bc1 in lws_h1_server_socket_service (pollfd=0x7fffffffd580, wsi=0x42e240) at ../libwebsockets-3.0.1/lib/roles/h1/ops-h1.c:378
#4  rops_handle_POLLIN_h1 (pt=<optimized out>, wsi=0x42e240, pollfd=0x7fffffffd580) at ../libwebsockets-3.0.1/lib/roles/h1/ops-h1.c:533
#5  0x00007ffff7f411e2 in lws_service_fd_tsi (context=0x41fea0, pollfd=0x7fffffffd580, tsi=tsi at entry=0) at ../libwebsockets-3.0.1/lib/core/service.c:899
#6  0x00007ffff7f412bb in lws_service_fd (context=<optimized out>, pollfd=pollfd at entry=0x7fffffffd580) at ../libwebsockets-3.0.1/lib/core/service.c:945
#7  0x0000000000406a62 in WebSocket::TLwsBase::HandleEvent (this=<optimized out>, fd=<optimized out>, event=<optimized out>) at TLwsBase.cpp:347
#8  0x00007ffff7fb48b0 in TPollSet::ProcessPendingEvents (this=0x41eca0) at TPollSet.cpp:302
#9  0x00007ffff7fb5df5 in TUnixEventLoop::RunOnce (this=0x41f9b0, timeout=timeout at entry=-1) at TUnixEventLoop.cpp:141
#10 0x0000000000404169 in (anonymous namespace)::TClientHandler::SendAndReceive (messageType=WebSocket::IConnection::TMessageType::TEXT, message=..., this=0x425970) at unittests/TestServer.cpp:50
#11 TestServer_ConnectionRejectedByServer_Test::TestBody (this=0x41f9a0) at unittests/TestServer.cpp:184
#12 0x00007ffff7f16de9 in testing::internal::HandleSehExceptionsInMethodIfSupported<testing::Test, void> (location=0x7ffff7f1fae3 "the test body", method=<optimized out>, object=0x41f9a0)
    at googletest-release-1.8.0/googletest/src/gtest.cc:2383
#13 testing::internal::HandleExceptionsInMethodIfSupported<testing::Test, void> (object=object at entry=0x41f9a0, method=<optimized out>, location=location at entry=0x7ffff7f1fae3 "the test body")
    at googletest-release-1.8.0/googletest/src/gtest.cc:2438
#14 0x00007ffff7f0aae2 in testing::Test::Run (this=0x41f9a0) at googletest-release-1.8.0/googletest/src/gtest.cc:2474
#15 testing::Test::Run (this=0x41f9a0) at googletest-release-1.8.0/googletest/src/gtest.cc:2465
#16 0x00007ffff7f0abe9 in testing::TestInfo::Run (this=0x41edf0) at googletest-release-1.8.0/googletest/src/gtest.cc:2656
#17 testing::TestInfo::Run (this=0x41edf0) at googletest-release-1.8.0/googletest/src/gtest.cc:2630
#18 0x00007ffff7f0ad0f in testing::TestCase::Run (this=0x41f400) at googletest-release-1.8.0/googletest/src/gtest.cc:2774
#19 testing::TestCase::Run (this=0x41f400) at googletest-release-1.8.0/googletest/src/gtest.cc:2759
#20 0x00007ffff7f0b858 in testing::internal::UnitTestImpl::RunAllTests (this=0x41f110) at googletest-release-1.8.0/googletest/src/gtest.cc:4649
#21 testing::internal::UnitTestImpl::RunAllTests (this=0x41f110) at googletest-release-1.8.0/googletest/src/gtest.cc:4551
#22 0x00007ffff7f0b9a3 in testing::internal::HandleSehExceptionsInMethodIfSupported<testing::internal::UnitTestImpl, bool> (location=0x7ffff7f1fc22 "auxiliary test code (environments or event listeners)", 
    method=(bool (testing::internal::UnitTestImpl::*)(testing::internal::UnitTestImpl * const)) 0x7ffff7f0b636 <testing::internal::UnitTestImpl::RunAllTests()>, object=<optimized out>)
    at googletest-release-1.8.0/googletest/src/gtest.cc:2383
#23 testing::internal::HandleExceptionsInMethodIfSupported<testing::internal::UnitTestImpl, bool> (location=0x7ffff7f1fc22 "auxiliary test code (environments or event listeners)", 
    method=(bool (testing::internal::UnitTestImpl::*)(testing::internal::UnitTestImpl * const)) 0x7ffff7f0b636 <testing::internal::UnitTestImpl::RunAllTests()>, object=0x41f110)
    at googletest-release-1.8.0/googletest/src/gtest.cc:2438
#24 testing::UnitTest::Run (this=<optimized out>) at googletest-release-1.8.0/googletest/src/gtest.cc:4257
#25 0x0000000000407a6f in RUN_ALL_TESTS () at ../../../dist/host/3pp/include/gtest/gtest.h:2233
#26 UnitTestMain (argc=<optimized out>, argv=<optimized out>) at main.cpp:14
#27 0x00007ffff7637580 in __libc_start_main () from /lib64/libc.so.6
#28 0x0000000000403809 in _start () at /usr/local/kreatv/toolchain/host/2.13.0/x86_64-kreatv-linux-gnu/include/c++/9.1.0/ext/new_allocator.h:89
(gdb)

-----Original Message-----
From: Andy Green <andy at warmcat.com> 
Sent: 2019年5月17日 11:28
To: Wei, Catherine <catherine.wei at commscope.com>; libwebsockets at ml.libwebsockets.org
Subject: RE: [Libwebsockets] libwebsocket problem

Message received from external source. Exercise caution when opening attachments, clicking links, or exchanging information.

 


On May 16, 2019 7:48:58 PM PDT, "Wei, Catherine" <catherine.wei at commscope.com> wrote:

>Thanks, if I use the lws_hdr_copy_fragment, I need to know how many

Nope... just try fragment 0, 1 etc until you get a failure... then you discovered how many there were.  You don't need to know going in.  CGI already does this...

https://secure-web.cisco.com/1marvqLD4ckiUpaISo-FYJ-NcMTdj4YodmtwqukhAmJUazxNxOS-9OKwjGillQKI4qBao9WOS6UzEJurglT3C8uZXRHJLMWy3CHil5L8Uj0G0vcLYtm-z2feG43vU7Zgf_2mMOHhqiMmGzqv8MsKgUvv-47RFdr1BZkJS2XX3ylcFVktTiGxElwyPbmamwvgFJQdGBkYmpbF-Gjm5Fd3e9fwUkuaRv6c6iL-QEbNaRzBTActmL0nR-ioNQ972DvloGX3Xq1JNWnpWizSMkef5xLvFzuXcpVyiLEptbVuHQcd4siv17dOD34IogDiQdonU/https%3A%2F%2Flibwebsockets.org%2Fgit%2Flibwebsockets%2Ftree%2Flib%2Froles%2Fcgi%2Fcgi-server.c#n277-295

>fragments; if I use lws_get_urlarg_by_name, I need to know parameter 
>name. However, all these are unknown to me. I think comment out the 
>parse about "?" in the path seems the most simple and direct way to me.
>I will use this way for debug at present, but still thanks for your 
>suggestion and letting me know such interfaces.

Okay...

>Another problem that I met:
>When I want to disconnect the websocket connection (protocol: ws) using 
>the "close(lws_get_socket_fd(&lwsConnection));" from the websocket

You're literally closing the socket without letting lws do the necessary steps.

>server side, I found there is no callback with reason
>(LWS_CALLBACK_DEL_POLL_FD) coming, and without this, the file 
>descriptor will not be removed. If I manually exit the running 
>websocket client, I can receive the callback with reason 
>LWS_CALLBACK_WSI_DESTROY and LWS_CALLBACK_DEL_POLL_FD.
>
>Do you know why this happened?

Yes... don't randomly close the socket using POSIX stuff.

Lws is flexible but it isn't quite so free-form.

You can usually close the wsi by returning nonzero from most callbacks.

If that doesn't fit the situation, use a related api...

https://secure-web.cisco.com/1tVPSU51-z7ldfqLk82vbwhDQOPZa8O3EyVmNxsn1jO-_nxA_Se7HR4VrlXXpGnXNMYxzn19MeidMrDxaZUiBrTEFGjVNXSMpvBC84IS3NBjEG31xskUTzFopn2TwAcIb4OpsKLK39RWeCFwyrcDpo9JIyVVJj09x25hd5P8QzXwdPjpKJE4eKtYKI-dV4sMhLILeEsBkeA8eL72v4zWvtpXSU7tZJIrNzo0Fjueqt8Sr5ljpsbUy3BZ2bOQCDTEBZibcpvoqVSFYjKt9A_55klKG9PSfMQeX66uqC9pWmg8QCS8br6Mewl7HqXT6z_bh/https%3A%2F%2Flibwebsockets.org%2Fgit%2Flibwebsockets%2Ftree%2Finclude%2Flibwebsockets%2Flws-timeout-timer.h#n79-105

-Andy

>Best regards,
>Catherine
>
>-----Original Message-----
>From: Andy Green <andy at warmcat.com>
>Sent: 2019年5月16日 18:19
>To: Wei, Catherine <catherine.wei at commscope.com>; 
>libwebsockets at ml.libwebsockets.org
>Subject: Re: [Libwebsockets] libwebsocket problem
>
>Email Security Warning:
>
>The following message was sent from an external e-mail address.
>Exercise caution when opening attachments, clicking links, or 
>exchanging information.
>
>
>On 5/16/19 9:12 AM, Wei, Catherine wrote:
>> Thanks for the API, since the number of the parameters are also
>unknow, so I didn't use the API. I added a patch to keep the parameters 
>to the url, so I can easily get the request url with parameters with 
>current interface. Still thanks. By the way, if there is any unproper 
>place in my patch, please let me know.
>
>I appreciate the urge to send me code, but the existing apis can do 
>everything you needed... look at the implementation of the by_name() 
>api... it's based on the other api.  It just looks at each fragment 
>until it finds it has asked for one that doesn't exist.
>
>LWS_VISIBLE LWS_EXTERN const char *
>lws_get_urlarg_by_name(struct lws *wsi, const char *name, char *buf, 
>int
>len)
>{
>         int n = 0, sl = (int)strlen(name);
>
>         while (lws_hdr_copy_fragment(wsi, buf, len,
>                           WSI_TOKEN_HTTP_URI_ARGS, n) >= 0) {
>
>                 if (!strncmp(buf, name, sl))
>                         return buf + sl;
>
>                 n++;
>         }
>
>         return NULL;
>}
>
>https://secure-web.cisco.com/1mswPXN1cJ-CTUPjOeut2csQnynvsV_6Xw9GFKPUiL
>tyUo2vcsqBojsHA3VtbbyBss5zP1FtfJ1LoaxrosqWO2xFY0k7xN9Em2idcv59hENyaim73
>HCVHyBUKKDvRJYW5HcLqehmBNvVc3SiUKoswfv0Cc1TyzPQT_4aT4RR1_H1o6gk4pyqkahf
>9bkxPff9BemK-5FMrOj9VbP-MzNDvyMu23TvrRTkG-N96jkXwr6P9qKHlu9mA1XpQw8yplU
>4pOmDCHLBsHLepGbeGc56Rs2vLqNxvYA8wgCN2t02Nj67W7E3yPQjFGMwA6OyMJtAK/http
>s%3A%2F%2Flibwebsockets.org%2Fgit%2Flibwebsockets%2Ftree%2Flib%2Fcore-net%2Fwsi.c#n504-519
>
>-Andy


More information about the Libwebsockets mailing list