[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

-----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...


>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.


>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 
>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...



>Best regards,
>-----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_get_urlarg_by_name(struct lws *wsi, const char *name, char *buf, 
>         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;

More information about the Libwebsockets mailing list