Bugzilla

Reporter

Updated

•

16 years ago

Status: UNCONFIRMED → NEW

Ever confirmed: true

:Gavin Sharp [email: gavin@gavinsharp.com]

Reporter

Comment 1

•

16 years ago

[continuing from comment #0]
Frame   Signature       Source

Signature	@0x870b1c0
UUID	e1bf51c2-fd91-11dc-87f7-001a4bd43e5c
Time	2008-03-29 06:12:35-07:00
Uptime	1
Product	Firefox
Version	3.0pre
Build ID	2008032904
OS	Linux
OS Version	0.0.0 Linux 2.6.22-3-k7 #1 SMP Sun Feb 10 21:04:14 UTC 2008 i686 GNU/Linux
CPU	x86
CPU Info	AuthenticAMD family 1 model 44 stepping 2
Crash Reason	SIGSEGV
Crash Address	0x870b1c0

Updated

•

16 years ago

Product: Firefox → Core

QA Contact: general → general

timeless

Comment 2

•

16 years ago

shaver: is our rooting story correct here?

Component: General → XPConnect

QA Contact: general → xpconnect

timeless

Updated

•

16 years ago

Summary: Crash on startup with my profile. [@0x870b1c0] → Crash on startup with my profile. [@0x870b1c0 - js_InternalInvoke - JS_CallFunctionValue - mozJSComponentLoader::LoadModule]

Henrik Skupin [:whimboo][⌚️UTC+1]

Reporter

Comment 3

•

16 years ago

I got rid of the crash somehow by an unknown combination of:
- disabling all the extensions
- removing compreg.dat
- enabling the extensions back in Mozilla/5.0 (X11; U; Linux i686; eo; rv:1.9pre) Gecko/2008033004 Minefield/3.0pre

Just doing them in that order does not help — crash happens when restarting after enabling any extension.

Comment 4

•

16 years ago

Please try to get the faulty extension by disabling/uninstalling them step by step.

Comment 5

•

16 years ago

I also used to crash this way on startup, using a 2008-03-30 build.
It doesn't seem related to a faulty extension. After I deleted one extension and restarted, I didn't crash anymore. But after undoing the deletion of the extension and restarting again, I still didn't crash. Now, I don't even crash with the original profile anymore, even.

Comment 6

•

16 years ago

Ok, I still crash with one of my profiles.
This is the stack I get in a debug build:
*** registering nsWebHandlerApp.js: [ A web handler for protocols and content ]
*** registering storage-Legacy.js: [ LoginManagerStorage_legacy ]
*** registering WebContentConverter.js: [ Web Content Handler Registrar ]
Assertion failure: FUN_INTERPRETED(fun), at c:/mozilla-build/mozilla/js/src/jsfu
n.c:2338
 	ntdll.dll!_DbgBreakPoint@0() 	
>	js3250.dll!JS_Assert(const char * s=0x00ae2598, const char * file=0x00ae2570, int ln=2338)  Line 59	C
 	js3250.dll!js_AddLocal(JSContext * cx=0x0136e178, JSFunction * fun=0x04622cc0, JSAtom * atom=0x03913864, JSLocalKind kind=JSLOCAL_ARG)  Line 2338 + 0x25 bytes	C
 	js3250.dll!fun_xdrObject(JSXDRState * xdr=0x0425f0e8, JSObject * * objp=0x0425f698)  Line 1309 + 0x18 bytes	C
 	js3250.dll!js_XDRObject(JSXDRState * xdr=0x0425f0e8, JSObject * * objp=0x0425f698)  Line 4831 + 0x10 bytes	C
 	js3250.dll!js_XDRScript(JSXDRState * xdr=0x0425f0e8, JSScript * * scriptp=0x0012f3d4, int * hasMagic=0x00000000)  Line 595 + 0x41 bytes	C
 	js3250.dll!JS_XDRScript(JSXDRState * xdr=0x0425f0e8, JSScript * * scriptp=0x0012f3d4)  Line 690 + 0xf bytes	C
 	xpc3250.dll!ReadScriptFromStream(JSContext * cx=0x0136e178, nsIObjectInputStream * stream=0x013b7238, JSScript * * script=0x0012f3d4)  Line 381 + 0xe bytes	C++
 	xpc3250.dll!mozJSComponentLoader::ReadScript(nsIFastLoadService * flSvc=0x013b1ad8, const char * nativePath=0x0425f1b0, nsIURI * uri=0x0425ef08, JSContext * cx=0x0136e178, JSScript * * script=0x0012f3d4)  Line 1000 + 0x19 bytes	C++
 	xpc3250.dll!mozJSComponentLoader::GlobalForLocation(nsILocalFile * aComponent=0x0136b758, JSObject * * aGlobal=0x0424f09c, char * * aLocation=0x0424f0a0)  Line 1140 + 0x3f bytes	C++
 	xpc3250.dll!mozJSComponentLoader::LoadModule(nsILocalFile * aComponentFile=0x0136b758, nsIModule * * aResult=0x0012f68c)  Line 624 + 0x2a bytes	C++
 	xpcom_core.dll!nsComponentManagerImpl::AutoRegisterComponent(nsILocalFile * aComponentFile=0x0136b758, nsTArray<DeferredModule> & aDeferred={...}, int minLoader=0)  Line 2988 + 0x33 bytes	C++
 	xpcom_core.dll!nsComponentManagerImpl::LoadLeftoverComponents(nsCOMArray<nsILocalFile> & aLeftovers={...}, nsTArray<DeferredModule> & aDeferred={...}, int minLoader=0)  Line 3043 + 0x1d bytes	C++
 	xpcom_core.dll!nsComponentManagerImpl::AutoRegister(nsIFile * aSpec=0x00000000)  Line 3307	C++
 	xpcom_core.dll!NS_InitXPCOM3_P(nsIServiceManager * * result=0x0012fbc4, nsIFile * binDirectory=0x003f8e80, nsIDirectoryServiceProvider * appFileLocationProvider=0x0012fcdc, const nsStaticModuleInfo * staticComponents=0x100394bc, unsigned int componentCount=1)  Line 661	C++
 	xul.dll!ScopedXPCOMStartup::Initialize()  Line 960 + 0x26 bytes	C++
 	xul.dll!XRE_main(int argc=1, char * * argv=0x003fac30, const nsXREAppData * aAppData=0x003f8c68)  Line 2966 + 0xb bytes	C++
 	firefox.exe!NS_internal_main(int argc=1, char * * argv=0x003fac30)  Line 158 + 0x12 bytes	C++
 	firefox.exe!wmain(int argc=1, unsigned short * * argv=0x003f8b10)  Line 87 + 0xd bytes	C++
 	firefox.exe!__tmainCRTStartup()  Line 583 + 0x19 bytes	C
 	firefox.exe!wmainCRTStartup()  Line 403	C
 	kernel32.dll!_BaseProcessStart@4()  + 0x23 bytes

OS: Linux → All

Comment 7

•

16 years ago

I get a regression range of this crash between 2008-03-29 04:25 and 2008-03-29 06:53:
http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&date=explicit&mindate=1206789900&maxdate=1206798839
So I guess this is a regression from bug 424964, somehow.

Blocks: 424964

Comment 8

•

16 years ago

Given the code the violated FUN_INTERPRETED(fun) means that just-allocated fun most-likely was GC-ed when js_AddLocal was called. The bug 424964 just exposed that since it has added debug-only code to fill the released objects with JS_FREE_PATTERN.

Can you trigger the assertion with the debugger? I am particularly interesting in the values cx->requestDepth, cx->tempValueRooters and &tvr at fun_xdrObject from the crash stack.

Comment 9

•

16 years ago

To Martijn Wargers: 

One more thing: can you reproduce this with a build from the latest trunk?

Comment 10

•

16 years ago

Unfortunately, I suddenly can't reproduce it at all anymore with that profile.
Even a restoring a back-up of the crashing profile, I can't reproduce the crash with anymore.

Comment 11

•

16 years ago

(In reply to comment #10)
> Unfortunately, I suddenly can't reproduce it at all anymore with that profile.
> Even a restoring a back-up of the crashing profile, I can't reproduce the crash
> with anymore.

Do you test this with the latest trunk build?

Comment 12

•

16 years ago

Yes, but older trunk builds also don't trigger the crash anymore, while I know that they used to.

Comment 13

•

16 years ago

(In reply to comment #12)
> Yes, but older trunk builds also don't trigger the crash anymore, while I know
> that they used to.
> 

OK, but what was the list of extensions?

Comment 14

•

16 years ago

Chatzilla 0.9.81 (disabled), DOM Inspector 2.0.0 (disabled), Java Quick Starter 1.0 (weird one, I don't think I ever installed this one).

Reporter

Comment 15

•

16 years ago

Adblock Plus 0.7.5.3
Adblock Plus: Element Hiding Helper 1.0.2
ChatZilla 0.9.81
Discordian date 0.0.2.5 (I think it was disabled, and certainly not on a toolbar; http://deletesoftware.geekworld.dk/software/mozilla/ )
FaviconizeTab 0.9.7.5
FoxyProxy 2.7.1
Greasemonkey 0.7.20080121.0
Html Validator 0.8.4.3
Metrics Collector 2a6
Mozilla QA Companion 0.1.10
Nightly Tester Tools 1.3
NoScript 1.5.2 (or something like that; 1.5.6 now)
Operator 0.9
RefControl 0.8.9
Russian spell dictionary 0.1
Server Spy 0.1.3
XHTML Ruby Support 1.4.2006100801

LONG DISABLED:
Live HTTP Headers 0.13.1
Torbutton 1.0.4.01
tweez 0.2


FoxyProxy and NTT were the ones I suspected after a few tries, but then enabling something simple (either XHTML Ruby Support, or Discordian date) also did cause crash.

Comment 16

•

16 years ago

Attached file stacktrace and hopefully the info you wanted — Details

Ok, I now crash again with the latest trunk build with a certain profile on startup.
This is the stacktrace again from a debug build with hopefully the requested info that Igor wanted in comment 8.

I don't know why I started crashing again in that profile. I remember that I first started a 2008-03-26 build and then tried a 2008-03-30 build, which then crashed.

Joe Sabash [:JoeS1]

Comment 17

•

16 years ago

FWIW I ran into this same problem when running an older build of Thunderbird with a profile that was generated by a current trunk build.
Here's my scenario:
Running fine on current trunk

Ran Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b5pre) Gecko/2008032602
Thunderbird/3.0a1pre ID:2008032602 with no problems.

Got the following crash when attempting to run current trunk with that same profile
http://crash-stats.mozilla.com/report/index/ee3f8b91-05d4-11dd-bcd5-001cc4e2bf68

My fix was to run software update (full d/l) on the 20080326 build which seemed
to make my profile usable again.

So it seems, something in the 20080326 build is changing something in my profile
that makes it unusable in newer builds ???
Or requires some functionality which shows this bug.

For Tbird, jumping between those dates does require rebuilding certain profile files. Compreg.dat for one.

timeless

Updated

•

16 years ago

Attachment #314342 - Flags: review?(igor)