414013 - Forcing logging in nsThreadImpl.h causes crash on startup

Status: RESOLVED INCOMPLETE

(Core :: XPCOM, defect)

Description

[David Humphrey (:humph)]

Attachment: Crash Report from Apple

When I uncomment the following line in nsTimerImpl.h:

//#define FORCE_PR_LOG /* Allow logging in the release build */

then rebuild (opt-static, if that matters) and run, I see:

firefox-bin(36675,0xa078ef60) malloc: *** error for object 0xdcf0160: incorrect checksum for freed object - object was probably modified after being freed.
*** set a breakpoint in malloc_error_break to debug
firefox-bin(36675,0xa078ef60) malloc: *** error for object 0xdcf0160: incorrect checksum for freed object - object was probably modified after being freed.
*** set a breakpoint in malloc_error_break to debug
firefox-bin(36675,0xa078ef60) malloc: *** error for object 0xdcf0160: incorrect checksum for freed object - object was probably modified after being freed.
*** set a breakpoint in malloc_error_break to debug
firefox-bin(36675,0xa078ef60) malloc: *** error for object 0xed5f420: incorrect checksum for freed object - object was probably modified after being freed.
*** set a breakpoint in malloc_error_break to debug
firefox-bin(36675,0xa078ef60) malloc: *** error for object 0xed5f440: incorrect checksum for freed object - object was probably modified after being freed.
*** set a breakpoint in malloc_error_break to debug
firefox-bin(36675,0xa078ef60) malloc: *** error for object 0xed5f470: incorrect checksum for freed object - object was probably modified after being freed.
*** set a breakpoint in malloc_error_break to debug
firefox-bin(36675,0xa078ef60) malloc: *** error for object 0xed5f480: incorrect checksum for freed object - object was probably modified after being freed.
*** set a breakpoint in malloc_error_break to debug
firefox-bin(36675,0xa078ef60) malloc: *** error for object 0xed5f490: incorrect checksum for freed object - object was probably modified after being freed.
*** set a breakpoint in malloc_error_break to debug
firefox-bin(36675,0xa078ef60) malloc: *** error for object 0xed5f4b0: incorrect checksum for freed object - object was probably modified after being freed.
*** set a breakpoint in malloc_error_break to debug
Minefield.app/Contents/MacOS/run-mozilla.sh: line 131: 36675 Segmentation fault      "$prog" ${1+"$@"}

I'm also attaching the Apple generated report.

Comment 1

[David Humphrey (:humph)]

Confirmed on XP as well.

Comment 2

[Chris Tyler]

On Linux I tried this invocation line:

NSPR_LOG_MODULES=nsTimerImpl:5 NSPR_LOG_FILE=default.log ./firefox -P development --no-remote

It didn't crash, and it did create the logfile, but the logfile is empty.

Comment 3

[timeless]

can you provide a stack trace for windows (as an attachment)? the apple stack trace is strange...

Comment 4

[David Humphrey (:humph)]

Attachment: Windows XP stack for crash

I've run this numerous times, and it dies in xpcmaps.cpp:65, nscyclecollector.cpp:2087, free.c:110, malloc.c:163, and some more.  However, in every case, the following is at the bottom of the stack:

firefox.exe!nsTableFrame::CalcBCBorders()  Line 5663 + 0x1a bytes	C++

Comment 5

[timeless]

that's because you don't have symbols for windows, http://developer.mozilla.org/en/docs/How_to_get_a_stacktrace_with_WinDbg and http://developer.mozilla.org/en/docs/Using_the_Mozilla_symbol_server have instructions.

Comment 6

[David Humphrey (:humph)]

I built with mk_add_options MOZ_DEBUG_SYMBOLS=1 and ac_add_options --enable-debugger-info-modules.  I was under the impression that this would be enough to get the stack.  What more will the symbol server give me?

Comment 7

[Mike Shaver (:shaver emeritus)]

That stack definitely looks like it has symbols to me!

Comment 8

[timeless]

it'll give you symbols for the microsoft frames

ntdll.dll!7c911e58() 	
 	[Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll]	
Getting symbols for ntdll will get rid off that warning there.

and you'll also get symbols for:
 	kernel32.dll!7c816fd7() 	
which is basically the real process entry point, but because your system doesn't match mine perfectly I can't easily look it up. With that resolved, the debugger will understand that there isn't stuff below it and won't show you

the following is at the bottom of the stack:

firefox.exe!nsTableFrame::CalcBCBorders()  Line 5663 + 0x1a bytes       C++

Comment 9

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

(In reply to comment #0)
> When I uncomment the following line in nsTimerImpl.h:
> 
> //#define FORCE_PR_LOG /* Allow logging in the release build */

FORCE_PR_LOG is weird, and defining it in a header file could affect other files in strange ways (particularly if part of the relevant code includes nsTimerImpl and part doesn't).

What happens if you instead define it at the top (before any #includes) of all the .cpp files that use gTimerLog?  What about defining DEBUG_TIMERS without defining FORCE_PR_LOG ?