Please check my sanity regarding this backtrace

[Aleksandar Kuktin]

Hello all.

I'm debugging Polipo, a HTTP proxy whose source code repository is here:
http://git.wifi.pps.univ-paris-diderot.fr/?p=polipo.git;a=summary

A poster on polipo-users list posted a backtrace from a core dump
generated in a crash. At the bottom of the trace is the following which I
can not wrap my mind about:

#104808 0x0805994f in httpClientHandlerHeaders (event=0x9ce1ca8,
srequest=0x9ce1cb8, connection=0x9d2b638) at client.c:666
666 return httpClientRequest(request, url);
#104809 0x08059a89 in httpClientHandler (status=0, event=0x9ce1ca8,
request=0x9ce1cb8) at client.c:392
392 httpClientHandlerHeaders(event, request, connection);
#104810 0x0804bf64 in do_scheduled_stream (status=0, event=0x9ce1ca8)
at io.c:282
282 done = request->handler(-ENOMEM, event,
request);

The function call in io.c, on line 282 calls the function with the first
argument being -ENOMEM but the trace entry which corresponds to the
function thus called has 0 as its first argument. Furthermore, the next
entry in the trace proves httpClientHandler() behaved as if its first
argument really was 0.

I can see only three possibilities. One: the trace is invalid. No idea
how would that happen. Two: ENOMEM is defined as 0. This option is
virtually impossible. Three: the stack was smashed somewhere at some
time. But I have a very hard time fitting that explanation with
everything else.

 

[Eric Sosman]

Hello all.

I'm debugging Polipo, a HTTP proxy whose source code repository is here:
http://git.wifi.pps.univ-paris-diderot.fr/?p=polipo.git;a=summary

A poster on polipo-users list posted a backtrace from a core dump
generated in a crash. At the bottom of the trace is the following which I
can not wrap my mind about:

#104808 0x0805994f in httpClientHandlerHeaders (event=0x9ce1ca8,
srequest=0x9ce1cb8, connection=0x9d2b638) at client.c:666
666 return httpClientRequest(request, url);
#104809 0x08059a89 in httpClientHandler (status=0, event=0x9ce1ca8,
request=0x9ce1cb8) at client.c:392
392 httpClientHandlerHeaders(event, request, connection);
#104810 0x0804bf64 in do_scheduled_stream (status=0, event=0x9ce1ca8)
at io.c:282
282 done = request->handler(-ENOMEM, event,
request);

The function call in io.c, on line 282 calls the function with the first
argument being -ENOMEM but the trace entry which corresponds to the
function thus called has 0 as its first argument. Furthermore, the next
entry in the trace proves httpClientHandler() behaved as if its first
argument really was 0.

I can see only three possibilities. One: the trace is invalid. No idea
how would that happen. Two: ENOMEM is defined as 0. This option is
virtually impossible. Three: the stack was smashed somewhere at some
time. But I have a very hard time fitting that explanation with
everything else.

A brief look at client.c (where httpClientHandler() lives)
shows that the `status' argument is used a few times near the
beginning of the function, and not used thereafter. On many
systems the first few function arguments are passed in registers,
and registers are a comparatively scarce resource. Thus, if the
compiler notices that `status' is unused after line 382, it might
well choose to re-use that register for other purposes, perhaps
just not saving and restoring it around calls to other functions.

When the program crashes, the debugger tries to make sense
of what it finds in the core dump or whatever other post-mortem
traces remain. Knowing that register Rx is supposed to hold the
function's first argument, the debugger prints what it finds in
Rx and says it's the value of `status' -- when in fact it's some
other value that replaced `status' when `status' was no longer
relevant.

I'm not saying this *is* what happened in your case, but it's
a plausible scenario. An experienced (i.e., "scarred") programmer
always views such printouts with a little bit of skepticism.

 

[Kaz Kylheku]

The function call in io.c, on line 282 calls the function with the first
argument being -ENOMEM but the trace entry which corresponds to the
function thus called has 0 as its first argument.

This is probably because you're debugging optimized code. See if the problem
that you're debugging can reproduce with an unoptimized build of the software
(no optimization options on the compiler command line). Then things
will make more sense in the debugger.