Closed Bug 276955 Opened 20 years ago Closed 20 years ago

Installing a theme causes firefox to segfault on ia64

Categories

(Core :: XPCOM, defect)

Product:
Core
Component:
XPCOM
Platform:
HP
Linux
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED DUPLICATE of bug 291378

People

(Reporter: jonas_arndt, Unassigned)

Details

To reproduce:
Tools => Themes => Get more themes
Chose a theme and install. 
When pressing OK in the popup window a segmentation fault causes Firefox to crash.

Note that this seems to be only on ia64 (not x86).

More details...
In the file mozilla/xpcom/reflect/xptcall/src/md/unix/xptcstubs_ipf64.cpp there
seem to be a problem with the dispatchParams array. When paramCount comes in as
10 and i=7 (dispatchParams[7]), line 107:
dp->val.u64 = *(fargs);
changes the whole dispatchParams[7] to some weird values.

Later the segfault happens, as a result of the above, in the file
mozilla/js/src/jsstr.c on line 2731
for (t = s; *t != 0; t++)
It seems that s is pointing to some strange memory.

This is the stack trace:

(gdb) bt
#0  js_strlen (s=0x4) at /opt/build/mozilla/js/src/jsstr.c:2731
#1  0x200000000015bee0 in js_NewStringCopyZ (cx=0x6000000000070870, s=0x4,
gcflag=0) at /opt/build/mozilla/js/src/jsstr.c:2562
#2  0x2000000000077e90 in JS_NewUCStringCopyZ (cx=0x6000000000070870, s=0x4) at
/opt/build/mozilla/js/src/jsapi.c:3847
#3  0x2000000001902df0 in XPCConvert::NativeData2JS (ccx=@0x60000fffffff9520,
d=0x60000fffffff9768, s=0x60000fffffff97f8, type=@0x60000fffffff9760,
iid=0x60000fffffff9510, scope=0x60000000003c05e0, pErr=0x0) at
/opt/build/mozilla/js/src/xpconnect/src/xpcconvert.cpp:379
#4  0x200000000193a1f0 in nsXPCWrappedJSClass::CallMethod
(this=0x2000000285653b00, wrapper=0x0, methodIndex=13, info=0x6000000000a79c10,
nativeParams=0x60000fffffff97c0) at
/opt/build/mozilla/js/src/xpconnect/src/xpcwrappedjsclass.cpp:1226
#5  0x200000000192e1d0 in nsXPCWrappedJS::CallMethod (this=0x2000000285697070,
methodIndex=13, info=0x6000000000a79c10, params=0x60000fffffff97c0) at
/opt/build/mozilla/js/src/xpconnect/src/xpcwrappedjs.cpp:449
#6  0x200000000039d7a0 in PrepareAndDispatch (self=0x2000000285697070,
methodIndex=13, intargs=0x60000fffffff9938, floatargs=0x60000fffffff9938,
restargs=0x60000fffffff9920) at
/opt/build/mozilla/xpcom/reflect/xptcall/src/md/unix/xptcstubs_ipf64.cpp:139
#7  0x20000000003a66d0 in SharedStub () at
/opt/build/mozilla/xpcom/glue/nsWeakReference.cpp:30
#8  0x200000000039de80 in nsXPTCStubBase::Stub13 (this=0x2000000285697070,
a1=2305843020042337344, a2=2305843020045103808, a3=2305843020041449008,
a4=2305843020041449008, a5=2305843020041515168, a6=18446744073709551615,
a7=2305843020041914848) at xptcstubsdef.inc:15
#9  0x20000000003a6830 in XPTC_InvokeByIndex () at
/opt/build/mozilla/xpcom/glue/nsWeakReference.cpp:30
#10 0x2000000001948b70 in XPCWrappedNative::CallMethod (ccx=@0x60000fffffff9c00,
mode=CALL_SETTER) at
/opt/build/mozilla/js/src/xpconnect/src/xpcwrappednative.cpp:2033
#11 0x200000000195a780 in XPC_WN_CallMethod (cx=0x6000000000070870,
obj=0x60000000003c0ec0, argc=10, argv=0x200000028629ae60, vp=0x60000fffffff9d20)
at /opt/build/mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp:1287
#12 0x20000000000cd350 in js_Invoke (cx=0x6000000000070870, argc=10, flags=0) at
/opt/build/mozilla/js/src/jsinterp.c:941
#13 0x20000000000e6c20 in js_Interpret (cx=0x6000000000070870,
result=0x60000fffffff9f80) at /opt/build/mozilla/js/src/jsinterp.c:2977
#14 0x20000000000cd470 in js_Invoke (cx=0x6000000000070870, argc=3, flags=2) at
/opt/build/mozilla/js/src/jsinterp.c:958
#15 0x200000000193a870 in nsXPCWrappedJSClass::CallMethod
(this=0x60000000003280f0, wrapper=0x0, methodIndex=3, info=0x6000000000304358,
nativeParams=0x60000fffffffa250) at
/opt/build/mozilla/js/src/xpconnect/src/xpcwrappedjsclass.cpp:1339
#16 0x200000000192e1d0 in nsXPCWrappedJS::CallMethod (this=0x2000000285610100,
methodIndex=3, info=0x6000000000304358, params=0x60000fffffffa250) at
/opt/build/mozilla/js/src/xpconnect/src/xpcwrappedjs.cpp:449
#17 0x200000000039d7a0 in PrepareAndDispatch (self=0x2000000285610100,
methodIndex=3, intargs=0x60000fffffffa318, floatargs=0x60000fffffffa340,
restargs=0x60000fffffffa3b0) at
/opt/build/mozilla/xpcom/reflect/xptcall/src/md/unix/xptcstubs_ipf64.cpp:139
#18 0x20000000003a66d0 in SharedStub () at
/opt/build/mozilla/xpcom/glue/nsWeakReference.cpp:30
#19 0x200000000039d8e0 in nsXPTCStubBase::Stub3 (this=0x2000000285610100,
a1=2305843020041651488, a2=2305843020055672552, a3=0, a4=6917546619827102688,
a5=6917546619827102688, a6=2305843020041355520, a7=4611686018427657092) at
xptcstubsdef.inc:5
#20 0x2000000000293830 in nsObserverService::NotifyObservers
(this=0x60000fffffffa3d0, aSubject=0x2000000285658520, aTopic=0x20000002863b76e8
"xpinstall-download-started", someData=0x0) at
/opt/build/mozilla/xpcom/ds/nsObserverService.cpp:208
#21 0x200000028639bc20 in nsXPInstallManager::OpenProgressDialog
(this=0x60000fffffffa560, aPackageList=0x60000fffffffa4a0, aCount=4294943872,
aObserver=0x60000fffffffa490) at
/opt/build/mozilla/xpinstall/src/nsXPInstallManager.cpp:482
#22 0x2000000286399b30 in nsXPInstallManager::InitManagerInternal
(this=0x6000000000c9c9d0) at
/opt/build/mozilla/xpinstall/src/nsXPInstallManager.cpp:287
#23 0x200000028639fad0 in nsXPInstallManager::OnCertAvailable
(this=0x6000000000c9c9d0, aURI=0x6000000000a6da10, context=0x0,
aStatus=2152398850, aPrincipal=0x0) at
/opt/build/mozilla/xpinstall/src/nsXPInstallManager.cpp:1141
#24 0x200000028633a7b0 in CertReader::OnStopRequest (this=0x6000000000bd2d40,
request=0x60000000008a7370, context=0x0, aStatus=2152398850) at
/opt/build/mozilla/xpinstall/src/CertReader.cpp:254
#25 0x20000000020dec90 in nsStreamListenerTee::OnStopRequest
(this=0x2000000285635370, request=0x60000000008a7370, context=0x0,
status=2152398850) at /opt/build/mozilla/netwerk/base/src/nsStreamListenerTee.cpp:65
#26 0x20000000022026a0 in nsHttpChannel::OnStopRequest (this=0x60000000008a7370,
request=0x60000000008657d0, ctxt=0x0, status=2152398850) at
/opt/build/mozilla/netwerk/protocol/http/src/nsHttpChannel.cpp:3652
#27 0x200000000208f8a0 in nsInputStreamPump::OnStateStop
(this=0x60000000008657d0) at
/opt/build/mozilla/netwerk/base/src/nsInputStreamPump.cpp:498
#28 0x200000000208eb70 in nsInputStreamPump::OnInputStreamReady
(this=0x60000000008657d0, stream=0x60000000008657f0) at
/opt/build/mozilla/netwerk/base/src/nsInputStreamPump.cpp:339
#29 0x2000000000300d80 in nsInputStreamReadyEvent::EventHandler
(plevent=0x6000000000c0f080) at /opt/build/mozilla/xpcom/io/nsStreamUtils.cpp:118
#30 0x2000000000344a60 in PL_HandleEvent (self=0x6000000000c0f088) at
/opt/build/mozilla/xpcom/threads/plevent.c:673
#31 0x2000000000344770 in PL_ProcessPendingEvents (self=0x60000000000823e0) at
/opt/build/mozilla/xpcom/threads/plevent.c:608
#32 0x200000000034a9f0 in nsEventQueueImpl::ProcessPendingEvents
(this=0x6000000000081260) at /opt/build/mozilla/xpcom/threads/nsEventQueue.cpp:398
#33 0x2000000001cd06e0 in event_processor_callback (source=0x6000000000289860,
condition=G_IO_IN, data=0x6000000000081260) at
/opt/build/mozilla/widget/src/gtk2/nsAppShell.cpp:67
#34 0x2000000000dd7a50 in g_io_unix_dispatch () from /opt/gnome/lib/libglib-2.0.so.0
#35 0x2000000000d8d760 in g_main_context_dispatch () from
/opt/gnome/lib/libglib-2.0.so.0
#36 0x2000000000d926b0 in g_main_context_iterate () from
/opt/gnome/lib/libglib-2.0.so.0
#37 0x2000000000d92ce0 in g_main_loop_run () from /opt/gnome/lib/libglib-2.0.so.0
#38 0x20000000007532f0 in gtk_main () from /opt/gnome/lib/libgtk-x11-2.0.so.0
#39 0x2000000001cd1480 in nsAppShell::Run (this=0x6000000000084cb0) at
/opt/build/mozilla/widget/src/gtk2/nsAppShell.cpp:142
#40 0x2000000001a246d0 in nsAppShellService::Run (this=0x6000000000084cb0) at
/opt/build/mozilla/xpfe/appshell/src/nsAppShellService.cpp:494
#41 0x400000000001dff0 in xre_main (argc=0, argv=0x60000fffffffb138,
aAppData=0x600000000000b398) at /opt/build/mozilla/toolkit/xre/nsAppRunner.cpp:1907
#42 0x4000000000013640 in main (argc=0, argv=0x60000fffffffb138) at
/opt/build/mozilla/browser/app/nsBrowserApp.cpp:58
(gdb)
Just to make life easier, I can provide whoever will work on this with a login
(through ssh) to my ia64 box where the problem can be reproduced.

// Jonas
Assignee: bugs → general
Component: Extension/Theme Manager → JavaScript Engine
Product: Firefox → Core
QA Contact: bugs → pschwartau
Version: 1.0 Branch → Trunk
What were the weird values?

*farg = ?
dp->val.u64 = ?
Hi,

The weird values is in dispatchParams[7].

This is the original values when entering PrepareAndDispatch

dispatchParams[7]

i8:	2
i16:	2
i32:	2
i64:	42949667298
u8:	2
u16:	2
u32:	2
u64:	42949667298
f:	2.80259693e-45
d:	2.1219957....e-314
b:	b
c:	2
wc:	2
p:	0x100000002

Then after
p->val.u64 = *(fargs);


dispatchParams[7]

i8:	4
i16:	4
i32:	4
i64:	4
u8:	4
u16:	4
u32:	4
u64:	4
f:	5.6051938..e-45
d:	1.97626258...e-323
b:	4
c:	4
wc:	4
p:	0x4

I was thinking that only the u64 value would change. In fact, whenever the u64
value is changed, all the values seem to change in the array even in other calls
to PrepareAndDispatch. However, it is only when paramCount is 10 and i = 7 you
have the weird p = 0x4 value. It is also this part of the array that seems to
cause the segfault later.

If you feel that you can contribute to solve this issue, please let me know if
access to the system will help you.

Thanks,

// Jonas
The variant is a union so each member shares some memory space. I don't think
there's anything going wrong there.

If there was something wrong in the xptcall logic I would have expected to bomb
way before you could even get to theme switching. It's possible, though from the
values given unlikely, that it could be broken and work with only the lower
portion. Make sure that __LP64__ is getting defined. It's used here
http://lxr.mozilla.org/seamonkey/source/xpcom/reflect/xptcall/src/md/unix/xptcstubs_ipf64.cpp#94

At this time I don't have enough time (finishing up end of year review :-( ) to
log on and do a debugging session. If progress hasn't been made in a week or so
I may have time freed up to take a look.
Hi David,

I saw there was code in there for __LP64__. Where do I define that? Might be
stupid, but I thought that this would be done in the configure part. Perhaps I
need to set something manually? Apart from that, it doesn't look like the code
ever goes in to test the __LP64__ part 

if(param.IsOut() || !type.IsArithmetic()) never goes true on line 76 (at least
it doesn't look that way from my debuggin sessions)

Also, indeed the dispatchParam[7] is what is causing the segfault later, at
least according to my findings.

I am not in a huge hurry to get this fixed, as I can always use the default
theme. In case you have other stuff to do, I can wait.

Any other hints or tests I could try in the mean time? Any document describing
how this works that I could read?


Thanks for your help,

// Jonas
>if(param.IsOut() || !type.IsArithmetic()) never goes true on line 76
>(at least it doesn't look that way from my debuggin sessions)

Well that might be a problem, I was expecting it to treat it as a pointer time, 
but it's been a while since I've been in this code in any detail. But as long 
as all pointers are no larger than u64 it's probably ok.

Ideally the __LP64__ should be defined automatically. To verify this, you could 
put a #error "__LP64__ is defined" pragma after the #ifdef and see if the 
compile aborts. There's probably a better way, but I'm not well versed in the 
build mechanics.

Thanks David,

I have verified that the __LP64__ is set.

Cheers,

// Jonas
Hi David,

Did you get a chance to further look into this?

Thanks,

// Jonas

*** This bug has been marked as a duplicate of 291378 ***
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Component: JavaScript Engine → XPCOM
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.