While filling the data uing the "Prefill Form" menu option the application crashes. This again is a problem only on a 64 bit OS. Upon investigation, the problems seems to be in typecasting the pointer "wallet_list" while passing in buffer.AppendInt. Here is the stack trace. (dbx) where > 0 __nxm_thread_kill(0x11fffc010, 0x0, 0x3ff805c3e30, 0x11fff56d8, 0x11fff6130) [0x3ff805c13f8] 1 pthread_kill(0x0, 0x1, 0x11fffc010, 0x0, 0x0) [0x3ff805b0c14] 2 (unknown)() [0x3ff805c45b4] 3 (unknown)() [0x3ff807f373c] 4 exc_unwind(0x11fff5928, 0xabadabad00beed00, 0x11fff5bc0, 0x30045feaf28, 0x3ff807f3b30) [0x3ff807f383c] 5 exc_raise_signal_exception(0xb0ffe0003, 0x86, 0x0, 0x300045d396c, 0x1) [0x3ff807f3b2c] 6 (unknown)() [0x3ff805b2580] 7 WLLT_PrefillReturn() ["wallet.cpp":3205, 0x300045d3968] 8 WALLET_PrefillReturn__18nsWalletlibServiceX12nsAutoString() ["nsWalletService.cpp":144, 0x300045c0100] 9 SetValue__17WalletPreviewImplXPCUsP20nsIDOMWindowInternal() ["nsWalletPreview.cpp":123, 0x30004c21620] 10 XPTC_InvokeByIndex() ["xptcinvoke_asm_osf1_alpha.s":73, 0x3ffbff309ac] 11 CallMethod__16XPCWrappedNativeXR14XPCCallContext8CallMode() ["xpcwrappednative.cpp":1883, 0x3ffbfd7cc70] 12 XPC_WN_CallMethod__XP9JSContextP8JSObjectUiPlPl() ["xpcwrappednativejsops.cpp":1252, 0x3ffbfd8c78c] 13 js_Invoke(cx = 0x141196200, argc = 2, flags = 0) ["jsinterp.c":807, 0x3ffbffab4ac] 14 js_Interpret(cx = 0x141196200, result = 0x11fff7418) ["jsinterp.c":2697, 0x3ffbffb6e70] 15 js_Invoke(cx = 0x141196200, argc = 1, flags = 2) ["jsinterp.c":824, 0x3ffbffab52c] 16 js_InternalInvoke(cx = 0x141196200, obj = 0x140fa2470, fval = 5389152432, flags = 0, argc = 1, argv = 0x11fff7758, rval = 0x11fff7670) ["jsinterp.c":896, 0x3ffbffab818] 17 JS_CallFunctionValue(cx = 0x141196200, obj = 0x11fff6580, fval = 1, argc = 536832716, argv = 0x1, rval = (nil)) ["jsapi.c":3349, 0x3ffbff819e8] 18 CallEventHandler__11nsJSContextXPvPvUiPvPii() ["nsJSEnvironment.cpp":952, 0x3ffbf2e4138] 19 HandleEvent__17nsJSEventListenerXP11nsIDOMEvent() ["nsJSEventListener.cpp":138, 0x3ffbf36d32c] 20 HandleEventSubType__22nsEventListenerManagerXP16nsListenerStructP11nsIDOMEventP17nsIDOMEventTargetUiUi() ["nsEventListenerManager.cpp":1196, 0x30003a20b2c] 21 HandleEvent__22nsEventListenerManagerXP14nsIPresContextP7nsEventPP11nsIDOMEventP17nsIDOMEventTargetUiP13nsEventStatus() ["nsEventListenerManager.cpp":2186, 0x30003a23078] 22 HandleDOMEvent__12nsXULElementXP14nsIPresContextP7nsEventPP11nsIDOMEventUiP13nsEventStatus() ["nsXULElement.cpp":3706, 0x30003c94f08] .........
*** Bug 96263 has been marked as a duplicate of this bug. ***
It looks like (in line # 2665 of wallet.cpp) buffer.AppendInt(NS_PTR_TO_INT32(wallet_list)); treats the pointer as a 32 bit integer. Our machine needs all the 64 bits. But since this is a 32 bit integer we lose the rest of the bits and the application crashes.
Reassigning it to cls.
Reassigning to Morse as the underlying logic of that function assumes that pointers are 32bits. All the NS_PTR_TO_INT32 macro did was make the assumption explicit.
Can we get some priority set to this bug, so that its not slipped off.
I sure wish someone with a 64-bit OS would take ownership of this because I have no way of testing out any changes that I make.
I will be glad to test the changes. And I have no idea of how to fix it.
Created attachment 52035 [details] [diff] [review] no longer pass the 32-bit pointer from c++ to js and back
Above attachment still works fine on a 32-bit OS. Reporter, please verify that this no longer crashes on a 64-bit OS. cc'ing matt and alecf for reviews
This works fine on a 64 bit (Tru64 UNIX) OS too. Is this possible to submit this to 0_9_4_BRANCH? Our release is based on MOZILLA_0_9_4_BRANCH.
That's up to drivers and/or pdt. Nominate it as such if you want to see that happen.
Marking as nsbranch to nominate for the 094 branch.
Comment on attachment 52035 [details] [diff] [review] no longer pass the 32-bit pointer from c++ to js and back oh my lord. Let's never ever do this again. sr=alecf
Comment on attachment 52035 [details] [diff] [review] no longer pass the 32-bit pointer from c++ to js and back r=matt
checked in on trunk
PDT- per Rob Jaworski comments in PDT.
OK, this won't go on the branch. Since I previously checked it in on the trunk, I can now mark it fixed.
Verified fix checked into lxr.mozilla.org