http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1001
------- Comment #8 from gentoo-a7x@xxxxxxxxxxxxxxx 2006-07-27 16:55 GMT -------
Unfortunately, the patch didn't help, which was very unexpected. At first I
thought I had done something wrong when adding the "if (ptr)" line, but I
noticed that the gdb backtrace now said "except.c:372" instead of the usual
"except.c:371". The weird thing is that the backtrace said ptr=0x0, which
isn't possible since ptr would have to be non-zero in order to execute line
372.
It turns out that the gdb backtrace was lying. I discovered this by changing
except_free() in epan/except.c to this:
369 void except_free(void *ptr)
370 {
371 if (ptr) {
372 fprintf(stderr, "(%s line %i) ptr is %p\n", __FILE__, __LINE__,
ptr);
373 get_dealloc()(ptr);
374 } else {
375 fprintf(stderr, "(%s line %i) ptr is null\n", __FILE__, __LINE__);
376 }
377 }
I saw a bunch of "(except.c line 375) ptr is null" and then a single "(except.c
line 372) ptr is 0xbfb53db8" just before the crash. Oddly, the backtrace now
shows the correct ptr value instead of 0x0.
I recompiled without SSP and I never saw anything besides "(except.c line 375)
ptr is null".
I will attach the new backtrace shortly. It differs only in line numbers (due
to the above change) and glibc details (I recompiled glibc with -ggdb).
Something to note: The definition of ENDTRY has a line calling
except_free(except_ch.except_obj.except_dyndata). According to the gdb
backtrace, that value being passed is 0x0. Yet except_free() is reporting that
the pointer it was passed is 0xbfb53db8. I wonder if I should just chalk this
up to another case of gdb strangeness...
--
Configure bugmail: http://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
