Closed
Bug 5661
Opened 25 years ago
Closed 25 years ago
Solaris: Apprunner crashes on startup (xptcall)
Categories
(Core :: JavaScript Engine, defect, P3)
Tracking
()
VERIFIED
FIXED
M6
People
(Reporter: mcafee, Assigned: mcafee)
References
()
Details
(Whiteboard: no fix in hand -take on the m5 branch?)
Attachments
(1 file)
(deleted),
patch
|
Details | Diff | Splinter Review |
Apprunner is crashing in timer code on startup, Solaris.
Linux seems to be Ok.
Assignee | ||
Updated•25 years ago
|
Target Milestone: M5
Assignee | ||
Comment 2•25 years ago
|
||
Just starting up apprunner:
#0 0xedfb3460 in __sigprocmask ()
#1 0xedfab02c in _resetsig ()
#2 0xedfaa8f0 in _sigon ()
#3 0xedfad4fc in _thrp_kill ()
#4 0xee0ba4c0 in abort ()
#5 0xee6a5394 in PR_Abort () at prlog.c:461
#6 0xef72529c in nsDebug::Abort (
aFile=0xec87e6c8 "xptcinvoke_unsupported.cpp", aLine=27)
at nsDebug.cpp:93
#7 0xef72533c in nsDebug::Break (
aFile=0xec87e6c8 "xptcinvoke_unsupported.cpp", aLine=27)
at nsDebug.cpp:108
#8 0xef725534 in nsDebug::Assertion (
aStr=0xec87e688 "XPTC_InvokeByIndex called on unsupported platform",
aExpr=0xec87e6c0 "0", aFile=0xec87e6c8 "xptcinvoke_unsupported.cpp",
aLine=27) at nsDebug.cpp:140
#9 0xec8768f4 in XPTC_InvokeByIndex (that=0x2a7758, methodIndex=4,
paramCount=1, params=0xefffdfb8) at xptcinvoke_unsupported.cpp:27
#10 0xec952e68 in nsXPCWrappedNativeClass::CallWrappedMethod (
this=0x294290, cx=0x28f7d8, wrapper=0x294488, desc=0x2942f0,
isAttributeSet=0, argc=0, argv=0x0, vp=0xefffe354)
at xpcwrappednativeclass.cpp:539
#11 0xec956004 in nsXPCWrappedNativeClass::GetAttributeAsJSVal (
this=0x294290, cx=0x28f7d8, wrapper=0x294488, desc=0x2942f0,
vp=0xefffe354) at xpcprivate.h:483
#12 0xec9539cc in WrappedNative_GetProperty (cx=0x28f7d8, obj=0x2a1460,
id=1427672, vp=0xefffe354) at xpcwrappednativeclass.cpp:730
#13 0xee756a30 in js_Interpret (cx=0x28f7d8, result=0xefffe59c)
at jsinterp.c:2155
#14 0xee74c680 in js_Execute (cx=0x28f7d8, chain=0x310908,
script=0x399aa8, fun=0x0, down=0x0, debugging=0, result=0xefffe59c)
at jsinterp.c:815
#15 0xee71ca84 in JS_EvaluateUCScriptForPrincipals (cx=0x28f7d8,
obj=0x310908, principals=0x0, chars=0x3a1770, length=2098,
filename=0x1ef560
"file:////export2/mcafee/cmonkey/mozilla/dist/bin/res/rdf/flash.xul", lineno=0,
rval=0xefffe59c) at jsapi.c:2390
#16 0xeef2929c in nsJSContext::EvaluateString (this=0x287eb8,
aScript=@0x39b900,
aURL=0x1ef560
"file:////export2/mcafee/cmonkey/mozilla/dist/bin/res/rdf/flash.xul", aLineNo=0,
aRetValue=@0xefffe618, aIsUndefined=0xefffe614)
at nsJSEnvironment.cpp:117
#17 0xed27c50c in XULContentSinkImpl::EvaluateScript (this=0x28ee28,
aScript=@0x39b900, aLineNo=0) at nsXULContentSink.cpp:1536
#18 0xed27c23c in XULContentSinkImpl::DoneLoadingScript (aLoader=0x1db7d0,
aData=@0x39b900, aRef=0x28ee28, aStatus=0) at nsXULContentSink.cpp:1491
#19 0xef19de74 in nsUnicharStreamLoader::OnStopBinding (this=0x1db7d0,
aURL=0x351f98, aStatus=0, aMsg=0xefffe860) at nsNetStreamLoader.cpp:156
#20 0xef13ff30 in nsDocumentBindInfo::OnStopBinding (this=0x351e58,
aURL=0x351f98, aStatus=0, aMsg=0xefffe860) at nsDocLoader.cpp:2128
#21 0xef1a2b8c in stub_complete (stream=0x3773c0) at nsStubContext.cpp:765
#22 0xef3d4f18 in net_ProcessFile (cur_entry=0x288970) at mkfile.c:1360
#23 0xef1ee1ac in NET_ProcessNet (ready_fd=0x0, fd_type=1)
at mkgeturl.c:3355
#24 0xef1fa420 in NET_PollSockets () at mkselect.c:298
#25 0xef198e68 in nsNetlibService::NetPollSocketsCallback (
aTimer=0x135fc8, aClosure=0x139f80) at nsNetService.cpp:1263
#26 0xef4c5144 in TimerImpl::FireTimeout (this=0x135fc8) at nsTimer.cpp:73
#27 0xef4c58fc in nsTimerExpired (aCallData=0x135fc8) at nsTimer.cpp:189
#28 0xee408304 in g_timeout_dispatch (source_data=0x39b630,
current_time=0xeffff018, user_data=0x135fc8) at gmain.c:1147
#29 0xee406fe4 in g_main_dispatch (current_time=0xeffff018) at gmain.c:647
#30 0xee40781c in g_main_iterate (block=1072, dispatch=1) at gmain.c:854
#31 0xee407a2c in g_main_run (loop=0xfd410) at gmain.c:912
#32 0xee5447d0 in gtk_main () at gtkmain.c:475
#33 0xef6504bc in nsAppShell::Run (this=0x10c3d0) at nsAppShell.cpp:202
#34 0xef77a2fc in nsAppShellService::Run (this=0x141510)
at nsAppShellService.cpp:186
#35 0x1cdc4 in main (argc=1, argv=0xeffff3a4) at nsAppRunner.cpp:447
Assignee | ||
Updated•25 years ago
|
Component: Apprunner → JavaScript
Assignee | ||
Comment 3•25 years ago
|
||
This looks like the xptcall stuff.
Assignee | ||
Comment 4•25 years ago
|
||
Related bug: http://bugzilla.mozilla.org/show_bug.cgi?id=5733
Assignee | ||
Updated•25 years ago
|
Summary: Solaris: Apprunner crashes on startup (Timers) → Solaris: Apprunner crashes on startup (xptcall)
Updated•25 years ago
|
Whiteboard: related to 5733?
Updated•25 years ago
|
Whiteboard: related to 5733? → related to 5733? need status update
Assignee | ||
Comment 6•25 years ago
|
||
Yes, probably related to 5733.
Comment 8•25 years ago
|
||
xptcall Porting Status is also tracked on the following page,
http://lxr.mozilla.org/mozilla/source/xpcom/libxpt/xptcall/status.html
Updated•25 years ago
|
Whiteboard: related to 5733? need status update → no fix in hand -take on the m5 branch?
Comment 10•25 years ago
|
||
*Currently* xpconnect (and thus xptcall) is only actually called by waterson's
rdf using sidebar stuff. So, for now we can safely avoid the assert by just not
copying libxpconnect.so into the dist components directory. Soon xpconnect will
be used by more stuff and mozilla won't run without it. But for now we can
sidestep the problem. The logic in
mozilla/xpcom/libxpt/xptcall/src/md/unix/Makefile.in will work just fine. I'll
check this in to mozilla/js/src/xpconnect/src/Makefile.in for now to unbreak
Solaris while the xptcall stuff gets fixed.
***you will have to manually remove the copy of libxpconnect.so from your
components direcotry***
Comment 11•25 years ago
|
||
Comment 12•25 years ago
|
||
I know soon the world will end if xptcall isn't ported to your platform, but can
we make it fail soft, at least on Solaris, until we know that lacking it is a
non-starter? I.e., change the assertion into and if statement whose then part
bails out without stopping the program from running?
I'm concerned because (until jband's update to this bug today), Bruce Mitchener
thought he was blocked by this for too long.
/be
Assignee | ||
Comment 13•25 years ago
|
||
Ok, graceful failure that brendan wants is now:
http://bugzilla.mozilla.org/show_bug.cgi?id=5932
Steps to solve this problem:
Invoke: Build the .so & test in xptcall directory
Stub: Build stub stuff, js/src/xpconnect/tests
Currently the .s & .cpp files are colliding, it looks like this
has never really compiled yet.
Comment 14•25 years ago
|
||
Hey, you guys didn't see my comment above? I already checked in the 'fail
gracefully' stuff. I marked http://bugzilla.mozilla.org/show_bug.cgi?id=5932 as
fixed.
Assignee | ||
Comment 15•25 years ago
|
||
I've got libxptcmd.so building on solaris, uncomment the
Solaris clause in mozilla/xpcom/libxpt/xptcall/src/md/unix/Makefile.in
to build this. It builds the "unsupported" version by default still
to support the "remove libxpconnect.so and you can still run solaris"
workaround.
Assignee | ||
Comment 16•25 years ago
|
||
I've got libxptcmd.so building on solaris, uncomment the
Solaris clause in mozilla/xpcom/libxpt/xptcall/src/md/unix/Makefile.in
to build this. It builds the "unsupported" version by default still
to support the "remove libxpconnect.so and you can still run solaris"
workaround.
Assignee | ||
Updated•25 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Comment 17•25 years ago
|
||
I've checked in changes to
mozilla/xpcom/libxpt/xptcall/src/md/unix
to get the xptcall stuff building, now the tests
are failing:
mozilla/xpcom/libxpt/xptcall/tests/TestXPTCInvoke
mozilla/js/src/xpconnect/tests/TestXPC
Assignee | ||
Updated•25 years ago
|
Assignee: mcafee → rogerl
Status: ASSIGNED → NEW
Assignee | ||
Comment 18•25 years ago
|
||
Cool, rogerl is debugging this now. Over to him for now.
Assignee | ||
Comment 19•25 years ago
|
||
Roger says he's got one of the tests working,
not checked in yet.
Assignee | ||
Updated•25 years ago
|
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 20•25 years ago
|
||
The tests appear to be working, I have turned on xpconnect now.
The test for this is: does solaris start up & work ok, AND does
the side bar appear to be working. It is hard for me to
test this over the wire (ISDN), but Solaris looks like it is working.
Marking fixed.
Assignee | ||
Updated•25 years ago
|
Status: RESOLVED → REOPENED
Assignee | ||
Updated•25 years ago
|
Assignee: rogerl → mcafee
Status: REOPENED → NEW
Assignee | ||
Updated•25 years ago
|
Resolution: FIXED → ---
Assignee | ||
Comment 21•25 years ago
|
||
Reopening, some straggling compiler issues. (gcc, egcs, native, etc.)
Assignee | ||
Updated•25 years ago
|
Status: NEW → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 22•25 years ago
|
||
I think this is generally working, marking fixed.
Will re-open separate bug for different compiler/hardware problems.
Comment 23•25 years ago
|
||
Updating QA Contact
Comment 24•25 years ago
|
||
come on you guys, this is xpcom stuff, not core javascript.
Updated•25 years ago
|
Status: RESOLVED → VERIFIED
Comment 25•25 years ago
|
||
Works great here (apart from something that I'll file as a separate bug some
day). Thanks all.
Comment 26•25 years ago
|
||
whatever. seriously, this isn't my problem. if you have issues, please talk
to clayton.
Comment 27•25 years ago
|
||
Changing component to "Javascript Engine". "Javascript" component is being
retired.
You need to log in
before you can comment on or make changes to this bug.
Description
•