Closed
Bug 124891
Opened 24 years ago
Closed 14 years ago
Random crashes in CrawlStack when doing JProf's
Categories
(Testing :: General, defect, P3)
Tracking
(Not tracked)
RESOLVED
INCOMPLETE
Future
People
(Reporter: jesup, Unassigned)
References
()
Details
(Keywords: crash)
Attachments
(2 files)
mozilla 20020211xx pull/build, -O2, Linux RH 7.1, dual-450's
(where do tools like jprof get reported to (Product/component)? It's
not a "web-based tool"...)
I crash semi-randomly when doing jprofs. It's repeatable at the URL
above within a minute of just watching the background change. To repeat:
setenv JPROF_FLAGS "JP_DEFER JP_PERIOD=0.0015"
./mozilla &
./jprofsig start
<browse to the URL above and wait, or randomly browse the web for a fair
while>
crash
GDB backtrace:
#0 0x40220c1a in CrawlStack ()
from
/home/jesup/src/mozilla_trunk/mozilla/obj-i686-pc-linux-gnu/dist/bin/libjprof.so
(gdb) bt
#0 0x40220c1a in CrawlStack ()
from
/home/jesup/src/mozilla_trunk/mozilla/obj-i686-pc-linux-gnu/dist/bin/libjprof.so
#1 0x40220d60 in Log ()
from
/home/jesup/src/mozilla_trunk/mozilla/obj-i686-pc-linux-gnu/dist/bin/libjprof.so
#2 0x40220ebc in StackHook ()
from
/home/jesup/src/mozilla_trunk/mozilla/obj-i686-pc-linux-gnu/dist/bin/libjprof.so
#3 0x40210b13 in pthread_sighandler_rt (signo=27, si=0xbfffdce0,
uc=0xbfffdd60) at signals.c:121
#4 <signal handler called>
#5 0x40564ef5 in strchr () from /lib/i686/libc.so.6
#6 0xbfffe088 in ?? ()
Error accessing memory address 0xff010101: No such process.
Can you at least get disassembly / registers of the crash from gdb? Any idea if
we've walked off the end of the stack into garbage or if the stack is corrupted?
Putting this bug on my list for now since I'm sure Asa doesn't want it.
Assignee: asa → dbaron
| Reporter | ||
Comment 2•24 years ago
|
||
Severity: major → critical
Status: NEW → ASSIGNED
Priority: -- → P3
Target Milestone: --- → Future
Comment 3•23 years ago
|
||
I get this consistently when locally loading the testcase from bug 109885
mozilla/tools/jprof does not seem to show up under lxr. I guess that is anoterh
bug :-(
Comment 5•23 years ago
|
||
Updated•21 years ago
|
Product: Browser → Seamonkey
Updated•20 years ago
|
Product: Mozilla Application Suite → Core
QA Contact: doronr → nobody
Updated•17 years ago
|
QA Contact: nobody → general
Updated•16 years ago
|
Assignee: dbaron → nobody
Product: Core → Testing
QA Contact: general → general
Comment 6•16 years ago
|
||
This is a mass change. Every comment has "assigned-to-new" in it.
I didn't look through the bugs, so I'm sorry if I change a bug which shouldn't be changed. But I guess these bugs are just bugs that were once assigned and people forgot to change the Status back when unassigning.
Status: ASSIGNED → NEW
Comment 7•14 years ago
|
||
Is this still relevant? If so, do we have crash signatures?
If it's not relevant any more, can we close it out?
| Reporter | ||
Comment 8•14 years ago
|
||
Too old, and too many changes for this bug to be relevant.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → INCOMPLETE
You need to log in
before you can comment on or make changes to this bug.
Description
•