Closed Bug 5661 Opened 25 years ago Closed 25 years ago

Solaris: Apprunner crashes on startup (xptcall)

Categories

(Core :: JavaScript Engine, defect, P3)

Product:
Core
Component:
JavaScript Engine
Platform:
Sun
Solaris
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: mcafee, Assigned: mcafee)

References

(
URL
)

Details

(Whiteboard: no fix in hand -take on the m5 branch?)

Attachments

(1 file)

this is the Makefile.in patch
672 bytes, patch
Details | Diff | Splinter Review 
Apprunner is crashing in timer code on startup, Solaris.
Linux seems to be Ok.
*** Bug 5106 has been marked as a duplicate of this bug. ***
Target Milestone: M5
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
URL: http://www.mozilla.org/scriptable/xpt...
Component: Apprunner → JavaScript
This looks like the xptcall stuff.
Summary: Solaris: Apprunner crashes on startup (Timers) → Solaris: Apprunner crashes on startup (xptcall)
*** Bug 5805 has been marked as a duplicate of this bug. ***
Whiteboard: related to 5733?
Whiteboard: related to 5733? → related to 5733? need status update
Yes, probably related to 5733.
*** Bug 5823 has been marked as a duplicate of this bug. ***
xptcall Porting Status is also tracked on the following page,

http://lxr.mozilla.org/mozilla/source/xpcom/libxpt/xptcall/status.html
Whiteboard: related to 5733? need status update → no fix in hand -take on the m5 branch?
*** Bug 5891 has been marked as a duplicate of this bug. ***
*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***
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
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.
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.
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.
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.
Status: NEW → ASSIGNED
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: mcafee → rogerl
Status: ASSIGNED → NEW
Cool, rogerl is debugging this now.  Over to him for now.
Roger says he's got one of the tests working,
not checked in yet.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
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.
Status: RESOLVED → REOPENED
Assignee: rogerl → mcafee
Status: REOPENED → NEW
Resolution: FIXED → ---
Reopening, some straggling compiler issues. (gcc, egcs, native, etc.)
Status: NEW → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
I think this is generally working, marking fixed.
Will re-open separate bug for different compiler/hardware problems.
QA Contact: 3853 → 4590
Updating QA Contact
QA Contact: 4590 → 4015
QA Contact: 4015 → 4590
QA Contact: 4590 → 4015
come on you guys, this is xpcom stuff, not core javascript.
Status: RESOLVED → VERIFIED
Works great here (apart from something that I'll file as a separate bug some
day). Thanks all.
QA Contact: 4015 → 4590
QA Contact: 4590 → 3849
whatever.  seriously, this isn't my problem.  if you have issues, please talk
to clayton.
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.

Attachment

General

Creator:
Created:
Updated:
Size: