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)

defect
Not set
critical

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.
Attached file Backtrace
Attaching backtrace.
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
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
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.
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?
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).
Attached file More better crash log
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.
Attached file Shared Library list
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.
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)
Attached file Commands requested
Ask, and I shall execute.
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.
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).
I do not use SwitchProxy, so I do not believe that was the root of the bug.
Here's a crash trace from 2.0.0.9 / Leopard, looks like the same crash.
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.
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.
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.
I also use Firebug, but I don't have any of the other extensions.
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.
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?
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.
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
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
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
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.
#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.
(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).
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
Whiteboard: [firebug-p2]
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]
Version: 1.8 Branch → Trunk
(In reply to comment #32)
Guess not; and I have switched to trunk (still without FireBug) sometime in January.
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.
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?
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.

if we're not seeing these bugs anymore can we mark this closed?
Crash Signature: [@ js_GetScriptLineExtent] [@ NSGetModule]
Closing because no crash reported since 12 weeks.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
Product: Other Applications → Other Applications Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: