[Libwebsockets] seg fault in lib using test-server

Björn Grunwald b.grunwald at abberior-instruments.com
Thu Feb 4 14:43:32 CET 2016

Hi Andy,

I am using the current HEAD from two days ago (commit 4939a708f81c1df83a683b534102beade5407de4).

Actually I reverted my changes to parsers.c and restarted cmake with only those options that I really need:
cmake .. -G "MinGW Makefiles" \
 -DCMAKE_C_COMPILER="C:/Program Files (x86)/National Instruments/Eclipse/14.0/arm/sysroots/i686-nilrtsdk-mingw32/usr/bin/armv7a-vfp-neon-nilrt-linux-gnueabi/arm-nilrt-linux-gnueabi-gcc.exe" \
 -DCMAKE_MAKE_PROGRAM="C:/UnixUtils/make.exe" \
 -DZLIB_ROOT="C:/libs/zlib" \

Now the crash is gone. Please note that I previously used some options without the LWS_ prefix. So it's very likely that the crash only occurs with SSL or EXTENSIONS enabled. Or perhaps only with the NI massaged openssl libraries. I am not too keen to find that out.

n.b.: NI just adds some very, very secret real-time patches to the kernel and updates their software repos only if you buy a new version of Labview. It's a pain. For that reason I want to get rid of as much Labview stuff as possible.



-----Ursprüngliche Nachricht-----
Von: Andy Green [mailto:andy.green at linaro.org] Im Auftrag von Andy Green
Gesendet: Donnerstag, 4. Februar 2016 11:52
An: Björn Grunwald <b.grunwald at abberior-instruments.com>; libwebsockets at ml.libwebsockets.org
Cc: andy.green at linaro.org
Betreff: Re: [Libwebsockets] seg fault in lib using test-server

On February 4, 2016 4:19:45 PM GMT+07:00, "Björn Grunwald" <b.grunwald at abberior-instruments.com> wrote:
>I am using libwebsockets on a National Instruments sbRIO module (SoM 
>with a Xilinx Zynq dual core ARM/FPGA). For a start I use the

I'm very familiar with Zynq... but not the NI stuff.

>test-server to evaluate the performance of websockets for the target 
>When the test-server sends the big jpg picture via http with a click on 
>the link in the test page, it is displayed properly in the browser. But 
>I observe a seg fault of test-server just after the successful transfer 
>of the image. Everything else on the test page works fine.


>I tracked the problem down to wsi->u.hdr.ah being NULL in 
>lws_reset_header_table. Now I patched parsers.c to prevent the seg 
>The patch seems to work, but I am not sure if it violates the idea 
>behind using lws_reset_header_table() and lws_free_header_table() in

The presumption of calling lws_reset_header_table() is certainly that you have a live ah to reset.  So it could better have assert(wsi->u.hdr.ah) since something's busted if we got the idea to reset something we don't have.

>lws_http_transaction_completed(). Is it better to use
>lws_free_header_table() instead? This also works. But I am not sure why
>wsi->u.hdr.ah is NULL actually. Is this the bug perhaps?

Yes I think so.

Are you using current HEAD?  Basically when the http request completes, he should still have the ah, and he makes a decision whether to free it if no new header already waiting, or keep it and reset it if more data is already arrived (ie, headers for the next pipelined http transaction).

>Is there anything else I can do to analyse the problem?

It's possible this is already fixed if you master branch is more than 4 days old.



>                               Björn
>Technical stuff:
>The stack trace looks like this:
>Thread [1] 2541 [core: 0] (Suspended : Signal : SIGSEGV:Segmentation
>       0xb6d2ac20
>       lws_reset_header_table() at 0xf344
>       lws_http_transaction_completed() at 0x16b5c
>       callback_http() at test-server-http.c:466 0xbca4
>       user_callback_handle_rxflow() at 0xcb24
>       lws_server_socket_service() at 0x16f34
>       lws_service_fd_tsi() at 0xdf30
>       lws_plat_service_tsi() at 0x15934
>       main() at test-server.c:373 0xa934
>working patch:
>--- a/lib/parsers.c
>+++ b/lib/parsers.c
>@@ -64,10 +64,13 @@ void
>lws_reset_header_table(struct lws *wsi) {
>               lwsl_err("%s: wsi %p\n", __func__, wsi);
>-              /* init the ah to reflect no headers or data have
>appeared yet */
>-              memset(wsi->u.hdr.ah->frag_index, 0,
>-              wsi->u.hdr.ah->nfrag = 0;
>-              wsi->u.hdr.ah->pos = 0;
>+             if (wsi->u.hdr.ah)
>+             {
>+                             /* init the ah to reflect no headers or
>data have appeared yet */
>+                             memset(wsi->u.hdr.ah->frag_index, 0,
>+                             wsi->u.hdr.ah->nfrag = 0;
>+                             wsi->u.hdr.ah->pos = 0;
>+             }
>libwebsockets has been cross-compiled by me on Windows 7 with this 
>cmake command line:
>cmake .. -G "MinGW Makefiles" \
>-DCMAKE_C_COMPILER="C:/Program Files (x86)/National 
>    -DCMAKE_MAKE_PROGRAM="C:/UnixUtils/make.exe" \
>    -DWITH-SSL=0 \
>    -Wno-dev \
>    -DZLIB_ROOT="C:/libs/zlib" \
>    -DOPENSSL_ROOT_DIR="C:/libs/ssl"
>test-server has been cross-compiled in Eclipse using the same 
>The browser is Firefox 43 on Windows.
>Libwebsockets mailing list
>Libwebsockets at ml.libwebsockets.org

More information about the Libwebsockets mailing list