[Libwebsockets] Segfault

"Andy Green (林安廸)" andy at warmcat.com
Fri Jan 25 23:24:37 CET 2013


On 25/01/13 23:04, the mail apparently from Jack Mitchell included:
> On 25/01/13 14:29, Jack Mitchell wrote:
>> On 25/01/13 13:11, "Andy Green (林安廸)" wrote:
>>> <snip>
>>>
>>> I studied it thisevening and changed this code around somewhat.
>>> Basically you should use libwebsockets_broadcast_foreign() from
>>> another thread now and it will take care of things properly without
>>> needing to use libwebsockets_fork_service_loop().  I added some
>>> documentation about it to README.coding also in this patch:
>>>
>>> http://git.libwebsockets.org/cgi-bin/cgit/libwebsockets/commit/?id=52f28ce67acd96f468d9ebbfe6f61fea5be4502b
>>>
>>> <snip>
>>>
>>
>> Hi Andy,
>>
>> Ok, so this seem to have successfully stopped the segfaulting.
>
> Apologies, I take that back. This has done something odd and it seems as
> though only some of the data gets through, almost like it's only writing
> the last piece of data? I'm not 100% as my websocket data isn't
> deterministic...

How much data are we trying to write at once?

It must pass through a socket to synchronize with the service loop, you 
will have to check the return code of libwebsockets_broadcast_foreign() 
to see if the send succeeded.  If there's a big spam it will have to 
wait until the service loop gets to it.

>> However there seems to be a small issue with the socket function as
>> Valgrind kindly points out:
>>
>> ==3475== Thread 5:
>> ==3475== Syscall param socketcall.send(msg) points to uninitialised
>> byte(s)
>> ==3475==    at 0x4FEEF374: send (in /lib/libpthread-2.16.so)
>> ==3475==    by 0x498AA0B: libwebsockets_broadcast_foreign
>> (libwebsockets.c:2186)
>> ==3475==    by 0xEF4B: webSock_broadcastJsonObject
>> (webInterface_webSockets.c:223)
>> ==3475==    by 0xAFDB: XX86_processFPGAData (XX86.c:141)
>> ==3475==    by 0xDA13: XX86_tickCheck (XX86_init.c:118)
>> ==3475==    by 0x4FEE6F5B: start_thread (pthread_create.c:313)
>> ==3475==    by 0x4FE2E0D7: ??? (in /lib/libc-2.16.so)
>> ==3475==  Address 0x6f75d42 is on thread 5's stack
>> ==3475==
>> ==3475== Thread 1:
>> ==3475== Syscall param socketcall.send(msg) points to uninitialised
>> byte(s)
>> ==3475==    at 0x4FEEF374: send (in /lib/libpthread-2.16.so)
>> ==3475==    by 0x498AA0B: libwebsockets_broadcast_foreign
>> (libwebsockets.c:2186)
>> ==3475==    by 0xEF4B: webSock_broadcastJsonObject
>> (webInterface_webSockets.c:223)
>> ==3475==    by 0xD88B: XX86socket_handleReceive (XX86_socket.c:110)
>> ==3475==    by 0xEE3B: webSock_genericSendRecieve
>> (webInterface_webSockets.c:147)
>> ==3475==    by 0x498B3E7: user_callback_handle_rxflow
>> (libwebsockets.c:1347)
>> ==3475==    by 0x498D61B: libwebsocket_rx_sm (parsers.c:968)
>> ==3475==    by 0x498D72B: libwebsocket_interpret_incoming_packet
>> (parsers.c:1037)
>> ==3475==    by 0x498D973: libwebsocket_read (handshake.c:233)
>> ==3475==    by 0x498BB2F: libwebsocket_service_fd (libwebsockets.c:884)
>> ==3475==    by 0x498BC13: libwebsocket_service (libwebsockets.c:1047)
>> ==3475==    by 0xA947: main (R0005.c:108)
>> ==3475==  Address 0xbd8999ba is on thread 1's stack

Hm this is wrong, you should not call libwebsockets_broadcast_foreign() 
from your service loop.  libwebsockets_broadcast() is the one for that. 
  I guess this is the reason for your data loss.

>> I also get the following (which isn't a new problem, just one I've
>> ignored for a bit):
>>
>> ==3475== Conditional jump or move depends on uninitialised value(s)
>> ==3475==    at 0x498B7F8: libwebsocket_service_fd (libwebsockets.c:716)
>> ==3475==    by 0x498BC13: libwebsocket_service (libwebsockets.c:1047)
>> ==3475==    by 0xA947: main (R0005.c:108)
>>
>> I think this small snippet is trying to service a now closed context?
>> As for the big snippet I'm not so sure about that...

716 is currently this

		if (context->started_with_parent && kill(context->started_with_parent, 
0) < 0)

context gets memset after allocation IIRC.

-Andy



More information about the Libwebsockets mailing list