Closed
Bug 414013
Opened 17 years ago
Closed 16 years ago
Forcing logging in nsThreadImpl.h causes crash on startup
Categories
(Core :: XPCOM, defect)
Tracking
()
RESOLVED
INCOMPLETE
People
(Reporter: humph, Unassigned)
References
()
Details
Attachments
(2 files)
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.
Reporter | ||
Comment 1•17 years ago
|
||
Confirmed on XP as well.
Comment 2•17 years ago
|
||
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.
Updated•17 years ago
|
can you provide a stack trace for windows (as an attachment)? the apple stack trace is strange...
Reporter | ||
Comment 4•17 years ago
|
||
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++
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.
Reporter | ||
Comment 6•17 years ago
|
||
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•17 years ago
|
||
That stack definitely looks like it has symbols to me!
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++
(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 ?
Updated•16 years ago
|
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → INCOMPLETE
You need to log in
before you can comment on or make changes to this bug.
Description
•