Closed
Bug 388993
Opened 17 years ago
Closed 6 years ago
Crash when opening a new tab [@ js_GetScriptLineExtent] [@ NSGetModule]
Categories
(Other Applications Graveyard :: Venkman JS Debugger, defect)
Other Applications Graveyard
Venkman JS Debugger
Tracking
(Not tracked)
RESOLVED
WONTFIX
People
(Reporter: ironiridis, Assigned: rginda)
References
Details
(Keywords: crash, Whiteboard: [firebug-p5])
Crash Data
Attachments
(5 files)
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.4) Gecko/20070515 Firefox/2.0.0.4
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.4) Gecko/20070515 Firefox/2.0.0.4
See backtrace. Crash occurred after opening a new tab with Command-T. Got the beachball for a few seconds before the crash hit. Only had one page open (no tab bar) before the key combo was pressed. Was viewing http://www.woot.com , but never had an issue with it before.
Reproducible: Couldn't Reproduce
about:buildconfig
Build platform
target
powerpc-apple-darwin8.7.0
Build tools
Compiler Version Compiler flags
gcc-3.3 -arch ppc gcc version 3.3 20030304 (Apple Computer, Inc. build 1819) -Wall -W -Wno-unused -Wpointer-arith -Wcast-align -Wno-long-long -nostdinc -isystem /Developer/SDKs/MacOSX10.2.8.sdk/usr/include/gcc/darwin/3.3 -isystem /Developer/SDKs/MacOSX10.2.8.sdk/usr/include -F/Developer/SDKs/MacOSX10.2.8.sdk/System/Library/Frameworks -fpascal-strings -no-cpp-precomp -fno-common -I/Developer/SDKs/MacOSX10.2.8.sdk/Developer/Headers/FlatCarbon
g++-3.3 -arch ppc gcc version 3.3 20030304 (Apple Computer, Inc. build 1819) -fno-rtti -fno-exceptions -Wall -Wconversion -Wpointer-arith -Wcast-align -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wno-long-long -nostdinc -nostdinc++ -I/Developer/SDKs/MacOSX10.2.8.sdk/usr/include/gcc/darwin/3.3/c++ -I/Developer/SDKs/MacOSX10.2.8.sdk/usr/include/gcc/darwin/3.3/c++/ppc-darwin -I/Developer/SDKs/MacOSX10.2.8.sdk/usr/include/gcc/darwin/3.3/c++/backward -isystem /Developer/SDKs/MacOSX10.2.8.sdk/usr/include/gcc/darwin/3.3 -isystem /Developer/SDKs/MacOSX10.2.8.sdk/usr/include -F/Developer/SDKs/MacOSX10.2.8.sdk/System/Library/Frameworks -fpascal-strings -no-cpp-precomp -fno-common -fshort-wchar -I/Developer/SDKs/MacOSX10.2.8.sdk/Developer/Headers/FlatCarbon -I/usr/X11R6/include
Configure arguments
--target=powerpc-apple-darwin8.7.0 --with-macos-sdk=/Developer/SDKs/MacOSX10.2.8.sdk --enable-application=browser --enable-update-channel=release --enable-official-branding '--enable-optimize=-O2 -g' --disable-debug --disable-tests --enable-update-packaging --enable-static --disable-shared --enable-prebinding --enable-svg --enable-canvas
Build platform
target
i386-apple-darwin8.7.0
Build tools
Compiler Version Compiler flags
gcc-4.0 -arch i386 gcc version 4.0.1 (Apple Computer, Inc. build 5250) -Wall -W -Wno-unused -Wpointer-arith -Wcast-align -Wno-long-long -isysroot /Developer/SDKs/MacOSX10.4u.sdk -fpascal-strings -no-cpp-precomp -fno-common -I/Developer/SDKs/MacOSX10.4u.sdk/Developer/Headers/FlatCarbon
g++-4.0 -arch i386 gcc version 4.0.1 (Apple Computer, Inc. build 5250) -fno-rtti -fno-exceptions -Wall -Wconversion -Wpointer-arith -Wcast-align -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wno-long-long -isysroot /Developer/SDKs/MacOSX10.4u.sdk -fpascal-strings -no-cpp-precomp -fno-common -fshort-wchar -I/Developer/SDKs/MacOSX10.4u.sdk/Developer/Headers/FlatCarbon
Configure arguments
--target=i386-apple-darwin8.7.0 --with-macos-sdk=/Developer/SDKs/MacOSX10.4u.sdk --enable-application=browser --enable-update-channel=release --enable-official-branding '--enable-optimize=-O2 -g' --disable-debug --disable-tests --enable-update-packaging --enable-static --disable-shared --enable-svg --enable-canvas
I'm marking the severity as "Critical" since it meets the criteria of the software crashing. However, I've never before encountered this issue, so in practice it is a fairly minor issue.
Reporter | ||
Comment 1•17 years ago
|
||
Attaching backtrace.
Updated•17 years ago
|
Keywords: crash
Summary: EXC_BAD_ACCESS in Mac OS X when opening a new tab → Crash when opening a new tab [@ js_GetScriptLineExtent] [@ NSGetModule]
Version: unspecified → 2.0 Branch
Comment 2•17 years ago
|
||
I am unable to reproduce in Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.9a7pre) Gecko/2007072204 Minefield/3.0a7pre
Have you been able to reproduce this either? If not, please could you close the bug and mark it a WORKSFORME?
Thanks
Reporter | ||
Comment 3•17 years ago
|
||
I have not been able to reproduce it, however, isn't this effectively a buffer overflow issue in js_GetScriptLineExtent? I'll leave it to you to close; as I stated in my report, I can't reproduce.
http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/js/src/jsscript.c&rev=3.151&mark=1687-1703#1686
no. it's crashing there, but the problem is elsewhere. usually the problem is that the script was freed or equivalent. there's no way that js_GetScriptLineExtent and similar functions can protect themselves from this.
picture this. you're Wile E Coyote, and you're twenty feet away from the ledge (off the edge of the cliff). You look down, you see you aren't standing on solid ground. What do you do? Answer: you fall. What else can you do? not much. You can only not fall *before* you run off the edge of the cliff, not after.
Reporter | ||
Comment 5•17 years ago
|
||
That's a really good visual for a crash. ;)
So is there no point in submitting a crash bug with backtrace if one can't reproduce? I understand if there is no information other than "it crashed", but what can be included that would help with the diagnostic? I basically gave you everything I had (Backtrace, circumstances, and detailed build info) what else would make this a valuable bug?
yes, i like it. i'll have to include it in the doc i'm writing.
crash bugs w/ backtraces can either be sufficient or frustrating. it's very hit or miss, and unless you're me there's not much chance in you knowing which it'll be. there's nothing wrong with filing bugs. filing them with back traces is a lot better than filing them w/o. the triagers are fairly good at spotting duplicates, patterns, etc.
really the only other thing that helps is steps to reproduce. when you don't have them, what you've included is the best we can get. Sometimes it's worth listing which extensions and plugins you have in case either of them have interesting traits. Note that for official builds, we don't really need build information (we can figure it out), build info is important if the build isn't one we made (and then the first thing we'll ask is for you to reproduce it with one we did make!).
I'm slowly writing http://docs.google.com/Doc?id=dhmd4jxt_58ftzb2h (url might change, dunno). We'll see where it goes.
Comment on attachment 273145 [details]
Backtrace
oh, one important thing!
if the build is one we made, on most platforms you can't use gdb to get a useful stack trace because we don't ship symbols which means what you'll see has nothing to do with what actually crashed. in these cases we request people use Talkback instead. (did you use gdb yourself or did this come from apple's crash reporter? -- normally on os x we do have symbols, but NSGetModule usually indicates a lack of symbols. Alternatively. Assuming most of the frames are correct, there's a section of apple crash reports indicating loaded modules. What module does it say is loaded around 0x01aeb000..0x01af0000?
Reporter | ||
Comment 8•17 years ago
|
||
I used gdb myself. I'm also noting that in the build configuration, debug is explicitly disabled. I've never had talkback work on OS X. I'd love if it did...
I don't know how to answer your last question.
the -g in '--enable-optimize=-O2 -g' gives it symbols.
did apple's crash reporter fire? if so there'd be a stack in Console.app's crashreporter logs.
info sharedlibrary would probably give the address (not sure how to get upper limit).
Reporter | ||
Comment 10•17 years ago
|
||
Aha. Missed the -g flag. Attaching firefox-bin.crash.log as generated by the Apple's crash reporter. Running "info sharedlibrary" didn't turn up any info documents, though I'm not sure that's what you meant.
Reporter | ||
Comment 11•17 years ago
|
||
Oh, color me dumb. I didn't realize you were replying to what I said in comment #8. Running the command on this very instance of Firefox generates the attached.
Comment 12•17 years ago
|
||
actually the format of apple's crash report tells me the things i want to know faster. (libraryname, start, stop).
how about:
ls -lh /Applications/Firefox.app/Contents/MacOS/*.dylib /Applications/Firefox.app/Contents/MacOS/components/*.dylib
something funny is going on. All the other libraries seem to have correct symbols. It almost looks like jsd doesn't. I'm wondering if it's from somewhere else.
Also, do |file libjsd.dylib; file libmozjs.dylib| (you need correct current working directory for these two)
Reporter | ||
Comment 13•17 years ago
|
||
Ask, and I shall execute.
Comment 14•17 years ago
|
||
I've had the same problem three times in the past 2 days on Windows. I have a minidump, and the stack looks identical to the one Chris has. Unfortunately symbols are gibberish as they tend to be in release mode. If the minidump can be of use please let me know. The problem isn't reproducible consistently.
I never had this problem before 2.0.0.7 so IMO it would be worth looking at what changed since 2.0.0.6 that might be the culprit.
Comment 15•17 years ago
|
||
I also experienced this problem some time ago (even before 2.0.0.7). However, due to bug #395478 I uninstalled the SwitchProxy extension. From this time on, I did not have this problem any more. You could check whether one of your extensions (SwitchProxy?) is causing this bug.
Moreover, you could try whether the problem also exists with a clean profile (see
<http://kb.mozillazine.org/Profile_manager> for how to create one).
Reporter | ||
Comment 16•17 years ago
|
||
I do not use SwitchProxy, so I do not believe that was the root of the bug.
Comment 17•17 years ago
|
||
Here's a crash trace from 2.0.0.9 / Leopard, looks like the same crash.
Comment 18•17 years ago
|
||
I also have two other stack traces for this crash - let me know if it would be useful to post them. Of the eight times Firefox has crashed for me in the past two weeks, three of them are this bug.
Comment 19•17 years ago
|
||
Another data point: this seems to happen every time I open a new tab (which for some reason on my machine takes a couple of seconds) and click in the FF search box before the tab opens. This is on Windows. On my Macs I don't have the problem at all.
I suspect this is the result of a particular combination of overlays. My extensions:
AllPeers 0.70.1
Firebug 1.05
FireFTP 0.97.1
Flashblock 1.5.4.1
ForecastFox 0.9.6
Live HTTP Headers 0.13.1
When I have time I'll do some experimentation to see if selectively disabling extensions fixes the problem.
Reporter | ||
Comment 20•17 years ago
|
||
Interesting common extensions:
Firebug
FireFTP
Live HTTP Headers
Don't know what versions they were when they were installed; had a major failure after this crash, started over, use different extensions.
Comment 21•17 years ago
|
||
I also use Firebug, but I don't have any of the other extensions.
Comment 22•17 years ago
|
||
I uninstalled Firebug and the problem instantly vanished (including the delay when opening a new tab). Unless someone is having the problem and does not have Firebug, I'd be inclined to say that it's the culprit.
Reporter | ||
Comment 23•17 years ago
|
||
Agreed; haven't re-installed Firebug since the crash, haven't had the issue. So is this technically a Firefox bug? Or an extension bug?
Comment 24•17 years ago
|
||
Interesting. But, as so many devs use Firebug, I think it maybe warrants some investigation by the Firefox devs to see whether it's a bug in Firefox functionality that Firebug is using, or something that needs to be in the Firebug codebase.
Comment 25•17 years ago
|
||
I have had at least three crashes with this stack signature on GNU/Linux, at least two of them when browsing Wikipedia, after or when opening a new tab: TB38418757G, TB38419087H.
Some of the extensions I have installed right now are Firebug 1.05 (not enabled for the sites) and Live HTTP Headers 0.13.1.
Changing the OS and Platform to All.
OS: Mac OS X → All
Hardware: Macintosh → All
Comment 26•17 years ago
|
||
I like the windows flavor better.
fun_apply is moderately interesting.
Incident ID: 38418757
Stack Signature js_GetScriptLineExtent() 672df407
Product ID Firefox2
Build ID 2007102514
Trigger Time 2007-11-24 14:08:44.0
Platform LinuxIntel
Operating System Linux 2.6.22-2-amd64
Module libmozjs.so + (00075b29)
URL visited
User Comments
Since Last Crash 13 sec
Total Uptime 115 sec
Trigger Reason SIGSEGV: Segmentation Fault: (signal 11)
Source File, Line No. /builds/tinderbox/Fx-Mozilla1.8-release/Linux_2.4.21-27.0.4.EL_Depend/mozilla/js/src/jsscript.c, line 1668
Stack Trace
js_GetScriptLineExtent() [mozilla/js/src/jsscript.c, line 1668]
JS_GetScriptLineExtent() [mozilla/js/src/jsdbgapi.c, line 969]
jsd_GetScriptLineExtent() [mozilla/js/jsd/jsd_scpt.c, line 475]
JSD_GetScriptLineExtent() [mozilla/js/jsd/jsdebug.c, line 308]
jsdScript::jsdScript() [mozilla/js/jsd/jsd_xpc.cpp, line 986]
jsdService::EnumerateScripts() [mozilla/js/jsd/jsd_xpc.cpp, line 155]
XPTC_InvokeByIndex()
XPCWrappedNative::CallMethod(XPCCallContext&, XPCWrappedNative::CallMode)() [mozilla/js/src/xpconnect/src/xpcwrappednative.cpp, line 2168]
XPC_WN_CallMethod() [mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp, line 1455]
js_Invoke() [mozilla/js/src/jsinterp.c, line 1375]
js_Interpret() [mozilla/js/src/jsinterp.c, line 3947]
js_Invoke() [mozilla/js/src/jsinterp.c, line 1394]
nsXPCWrappedJSClass::CallMethod() [mozilla/js/src/xpconnect/src/xpcwrappedjsclass.cpp, line 1453]
nsXPCWrappedJS::CallMethod() [mozilla/js/src/xpconnect/src/xpcwrappedjs.cpp, line 468]
PrepareAndDispatch() [mozilla/xpcom/reflect/xptcall/src/md/unix/xptcstubs_gcc_x86_unix.cpp, line 100]
XPTC_InvokeByIndex()
XPCWrappedNative::CallMethod(XPCCallContext&, XPCWrappedNative::CallMode)() [mozilla/js/src/xpconnect/src/xpcwrappednative.cpp, line 2168]
XPC_WN_CallMethod() [mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp, line 1455]
js_Invoke() [mozilla/js/src/jsinterp.c, line 1375]
js_Interpret() [mozilla/js/src/jsinterp.c, line 3947]
js_Invoke() [mozilla/js/src/jsinterp.c, line 1394]
fun_apply() [mozilla/js/src/jsfun.c, line 1696]
js_Invoke() [mozilla/js/src/jsinterp.c, line 1375]
js_Interpret() [mozilla/js/src/jsinterp.c, line 3947]
js_Invoke() [mozilla/js/src/jsinterp.c, line 1394]
nsXPCWrappedJSClass::CallMethod() [mozilla/js/src/xpconnect/src/xpcwrappedjsclass.cpp, line 1453]
nsXPCWrappedJS::CallMethod() [mozilla/js/src/xpconnect/src/xpcwrappedjs.cpp, line 468]
PrepareAndDispatch() [mozilla/xpcom/reflect/xptcall/src/md/unix/xptcstubs_gcc_x86_unix.cpp, line 100]
XPTC_InvokeByIndex()
XPCWrappedNative::CallMethod(XPCCallContext&, XPCWrappedNative::CallMode)() [mozilla/js/src/xpconnect/src/xpcwrappednative.cpp, line 2168]
XPC_WN_CallMethod() [mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp, line 1455]
js_Invoke() [mozilla/js/src/jsinterp.c, line 1375]
fun_apply() [mozilla/js/src/jsfun.c, line 1696]
js_Invoke() [mozilla/js/src/jsinterp.c, line 1375]
js_Interpret() [mozilla/js/src/jsinterp.c, line 3947]
js_Invoke() [mozilla/js/src/jsinterp.c, line 1394]
nsXPCWrappedJSClass::CallMethod() [mozilla/js/src/xpconnect/src/xpcwrappedjsclass.cpp, line 1453]
nsXPCWrappedJS::CallMethod() [mozilla/js/src/xpconnect/src/xpcwrappedjs.cpp, line 468]
PrepareAndDispatch() [mozilla/xpcom/reflect/xptcall/src/md/unix/xptcstubs_gcc_x86_unix.cpp, line 100]
XPTC_InvokeByIndex()
XPCWrappedNative::CallMethod(XPCCallContext&, XPCWrappedNative::CallMode)() [mozilla/js/src/xpconnect/src/xpcwrappednative.cpp, line 2168]
XPC_WN_CallMethod() [mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp, line 1455]
js_Invoke() [mozilla/js/src/jsinterp.c, line 1375]
js_Interpret() [mozilla/js/src/jsinterp.c, line 3947]
js_Invoke() [mozilla/js/src/jsinterp.c, line 1394]
nsXPCWrappedJSClass::CallMethod() [mozilla/js/src/xpconnect/src/xpcwrappedjsclass.cpp, line 1453]
nsXPCWrappedJS::CallMethod() [mozilla/js/src/xpconnect/src/xpcwrappedjs.cpp, line 468]
PrepareAndDispatch() [mozilla/xpcom/reflect/xptcall/src/md/unix/xptcstubs_gcc_x86_unix.cpp, line 100]
nsDocLoader::FireOnStateChange() [mozilla/uriloader/base/nsDocLoader.cpp, line 848]
Assignee: nobody → rginda
Component: General → JavaScript Debugger
Product: Firefox → Other Applications
QA Contact: general → venkman
Version: 2.0 Branch → 1.8 Branch
Comment 27•17 years ago
|
||
It would be helpful to know which version of firebug was used? 1.05? If so, trying the test with 1.1 would be useful, http://fireclipse.xucia.com.
John
Comment 28•17 years ago
|
||
I guess I'm the only one who is confused by timeless saying "I like the windows flavor better" and then posting a linux stack?
Also: crash . Timeless, let me know if that no longer works. Everyone else, ignore this paragraph. Sorry for spam.
Comment 29•17 years ago
|
||
#define windows not(mac)
:(. the mac stack traces seem to be victims of optimizers, the linux (..) stack trace i posted doesn't seem to suffer from optimizers and is therefore easier to follow.
Comment 30•17 years ago
|
||
(In reply to comment #27)
On December 1st, I have updated Firebug from 1.05 to 1.1.0b10 from that site, and the crash hasn’t happened to me since (yet).
Comment 31•17 years ago
|
||
I had the same silent crash today with Firfox2 and Firebug 1.05. First ten frames looks like:
0 libmozjs.dylib 0x00c8f16d js_LineNumberToPC + 29
1 libjsd.dylib 0x01a52889 NSGetModule + 14389
2 libjsd.dylib 0x01a52be2 NSGetModule + 15246
3 libxpcom_core.dylib 0x00e5a8d9 XPTC_InvokeByIndex + 81
4 org.mozilla.firefox 0x00370b23 XPCWrappedNative::CallMethod(XPCCallContext&, XPCWrappedNative::CallMode) + 743
5 org.mozilla.firefox 0x00362dc3 XPC_WN_CallMethod(JSContext*, JSObject*, unsigned, long*, long*) + 261
6 libmozjs.dylib 0x00c5a657 js_Invoke + 858
7 libmozjs.dylib 0x00c4cde1 js_Interpret + 4632
8 libmozjs.dylib 0x00c5adfe js_Invoke + 2817
9 org.mozilla.firefox 0x005c1d72 nsXPCWrappedJSClass::CheckForException(XPCCallContext&, char const*, char const*) + 2454
10 org.mozilla.firefox 0x005bef6b nsXPCWrappedJS::SystemIsBeingShutDown(JSRuntime*) + 483
Status: UNCONFIRMED → NEW
Ever confirmed: true
Updated•17 years ago
|
Whiteboard: [firebug-p2]
Comment 32•17 years ago
|
||
Based on comment #30, sounds like this problem does not occur with Firebug 1.1. Aleksej, I assume you've not seen this since then?
Talkback shows @js_GetScriptLineExtent as topcrash #244 (81 crashes in the last day), so this doesn't seem too common.
Whiteboard: [firebug-p2] → [firebug-p5]
Comment 34•17 years ago
|
||
(In reply to comment #32)
Guess not; and I have switched to trunk (still without FireBug) sometime in January.
Comment 35•17 years ago
|
||
Another metoo, this time in Linux: I've been seeing this maybe every other day lately, but this is the first time I've gotten a core from it so I could see where it was crashing. I do have Firebug installed, but it's 1.01, so I'll try upgrading it. I don't have any of the other extensions mentioned.
Comment 36•16 years ago
|
||
has this been fixed in Firefox 3.0.1, Firebug 1.1+? I've been running the latest 3.0.1 candidate with Firebug 1.2 all day without a crash.
Were there any particular steps to reproduce this when creating a new tab? Was firebug enabled, for instance?
Comment 37•16 years ago
|
||
I've had no similar crashes since switching to Firefox 3.0 and 1.2.0b4 in almost a month of use - at the least, a far lower rate than before.
Comment 38•15 years ago
|
||
if we're not seeing these bugs anymore can we mark this closed?
Updated•13 years ago
|
Crash Signature: [@ js_GetScriptLineExtent]
[@ NSGetModule]
Comment 39•6 years ago
|
||
Closing because no crash reported since 12 weeks.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
Updated•6 years ago
|
Product: Other Applications → Other Applications Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•