Re: [libmicrohttpd] libmicrohttpd trigger Segmentation fault

[Christian Grothoff]

On 02/19/2013 12:12 PM, hzm wrote:
> Hi,
> 
>   We use libmicrohttpd 0.9.14 (read from configure.ac) under linux/ARM
> devices. A Segmentation fault was detected today for the first time.I
> debugged the core file with gdb, and it showed as follow:
> 
> ....
> Program terminated with signal 11, Segmentation fault.
> (gdb) bt
> #0  0x00000000 in ?? ()
> #1  0x4030d300 in free_atfork () from ./lib/libc.so.6
> #2  0x405e0330 in MHD_cleanup_connections (daemon=0x74398) at
> daemon.c:1193
> #3  0x405e12a0 in MHD_select_thread (cls=0x74398) at daemon.c:1618
> #4  0x404049bc in start_thread () from ./lib/libpthread.so.0
> #5  0x40373b28 in clone () from ./lib/libc.so.6
> #6  0x40373b28 in clone () from ./lib/libc.so.6
> Backtrace stopped: previous frame identical to this frame (corrupt
> stack?)
> (gdb) p *pos
> $3 = {next = 0x0, prev = 0x0, daemon = 0x74398, headers_received = 0x0,
> response = 0x0, pool = 0x131e90, 
>   client_context = 0x0, method = 0x0, url = 0x0, version = 0x0,
> read_buffer = 0x406f9000 <Address 0x406f9000 out of bounds>, 
>   write_buffer = 0x0, last = 0x406f905a <Address 0x406f905a out of
> bounds>, 
>   colon = 0x406f906a <Address 0x406f906a out of bounds>, addr =
> 0x12de38, pid = 1081050224, read_buffer_size = 5918, 
>   read_buffer_offset = 0, write_buffer_size = 0,
> write_buffer_send_offset = 0, write_buffer_append_offset = 0, 
>   remaining_upload_size = 0, response_write_position = 0,
> continue_message_write_offset = 0, addr_len = 16, 
>   last_activity = 1361264679, connection_timeout = 0, client_aware = 0,
> socket_fd = 4, read_closed = 1, thread_joined = 0, 
>   state = MHD_CONNECTION_CLOSED, responseCode = 0, response_unready = 0,
> have_chunked_upload = 0, current_chunk_size = 0, 
>   current_chunk_offset = 0, read_handler = 0x405dd58c
> <MHD_connection_handle_read>, 
>   write_handler = 0x405dd68c <MHD_connection_handle_write>, idle_handler
> = 0x405ddac4 <MHD_connection_handle_idle>, 
>   recv_cls = 0x405df5c4 <recv_param_adapter>, send_cls = 0x405df67c
> <send_param_adapter>}
> 
> As it seems everything occured within libmicrohttpd, would it be a
> problem from libmicrohttpd itself?

It seems unlikely.  I don't know what calls 'free_atfork' from your
trace, but it must be some internal libc cleanup function, which then
jumps to NULL.  Obviously, libc should "never" do that.  The data inside
of '*pos' (read buffer out of bounds? PID of 1081050224?) also doesn't
look too likely, so my best guess is that the heap is corrupted at the
time of the crash --- and that corruption could come just as likely from
your application logic as from MHD.

I suggest you first of all update to a mroe recent MHD version (just in
case) and then try to reproduce your problem while running your code
with 'valgrind' -- that might help catch memory corruption.

If libc still jumps to NULL, check if you do anything like registering
'atexit' handlers (for threads?) and check if you registered those
_correctly_ (and not with a NULL argument in the wrong place...). At
least that's my best idea right now given the limited data from the
stack trace.


Happy hacking!

-Christian