Closed Bug 33839 Opened 25 years ago Closed 24 years ago

segmentation fault on startup before any window appears

Categories

(Core Graveyard :: Profile: BackEnd, defect, P3)

Sun
Solaris
defect

Tracking

(Not tracked)

VERIFIED WORKSFORME

People

(Reporter: kolya, Assigned: selmer)

References

()

Details

(Whiteboard: [need update][6/23])

From Bugzilla Helper: User-Agent: Mozilla/4.61C-CCK-MCD [en] (X11; U; SunOS 5.6 sun4m) BuildID: M14(?) -- unable to determine since browser does not open When starting Mozilla on Solaris 2.6 on a Sparc 5 for the first time, it displays the profile creation window, and I can go through it and hit "Finish", upon which time the profile creation window closes, it does something for a while, and then crashes with a segfault. Starting again results in a segmentation fault every time. Reproducible: Always Steps to Reproduce: See above; simply start mozilla with no profile, create a profile by choosing all the defaults, and watch mozilla-bin crash.. Running ./mozilla subsequently doesn't produce the profile window (presumably because it already finds it there), yet mozilla-bin still crashes. Actual Results: This crash is with a profile already having been created: pepsi/u/kolya/mozilla/package284> ./mozilla .//run-mozilla.sh ./mozilla-bin MOZILLA_FIVE_HOME=/var/u/kolya/mozilla/package LD_LIBRARY_PATH=/var/u/kolya/mozilla/package:/usr/openwin/lib:/mit/aui/arch/su n4x_56/lib SHLIB_PATH=/var/u/kolya/mozilla/package LIBPATH=/var/u/kolya/mozilla/package MOZ_PROGRAM=./mozilla-bin MOZ_TOOLKIT= moz_debug=0 moz_debugger= GLib-WARNING **: getpwuid_r(): failed due to: No such user 31818. Profile Manager : Profile Wizard and Manager activites : Begin Profile Manager : Command Line Options : Begin Profile Manager : Command Line Options : End ProfileManager : GetProfileDir ProfileManager : GetProfileDir Profile Manager : Profile Wizard and Manager activites : End WEBSHELL+ = 1 WEBSHELL+ = 2 assuming d&d is off for Navigator nsCollationUnix::Initialize mLocale = C nsCollationUnix::Initialize mCharset = ISO-8859-1 Segmentation Fault - core dumped Expected Results: Start without crashing. Unfortunately, the pre-built binaries from mozilla.org don't seem to include symbols everywhere, so this stack trace is of limited usefulness.. #0 0xedd5f10c in RDFServiceImpl::GetDataSource () from /var/u/kolya/mozilla/package/components/librdf.so #1 0xeddbfe70 in nsXULDocument::CheckTemplateBuilder () from /var/u/kolya/mozilla/package/components/librdf.so #2 0xeddbba9c in nsXULDocument::ResumeWalk () from /var/u/kolya/mozilla/package/components/librdf.so #3 0xeddbd638 in nsXULDocument::OnStreamComplete () from /var/u/kolya/mozilla/package/components/librdf.so #4 0xee590730 in nsStreamLoader::OnStopRequest () from /var/u/kolya/mozilla/package/components/libnecko.so #5 0xee4b9e4c in nsResChannel::OnStopRequest () from /var/u/kolya/mozilla/package/components/libnecko_res.so #6 0xee4797d4 in nsFileChannel::OnStopRequest () from /var/u/kolya/mozilla/package/components/libnecko_file.so #7 0xee571f04 in nsOnStopRequestEvent::HandleEvent () from /var/u/kolya/mozilla/package/components/libnecko.so #8 0xee5715e0 in nsStreamListenerEvent::HandlePLEvent () from /var/u/kolya/mozilla/package/components/libnecko.so #9 0xef6099f8 in PL_HandleEvent () from /var/u/kolya/mozilla/package/libxpcom.so #10 0xef609918 in PL_ProcessPendingEvents () from /var/u/kolya/mozilla/package/libxpcom.so #11 0xef60ac80 in nsEventQueueImpl::ProcessPendingEvents () from /var/u/kolya/mozilla/package/libxpcom.so #12 0xee300778 in nsAppShell::SetDispatchListener () from /var/u/kolya/mozilla/package/libwidget_gtk.so #13 0xee300378 in keysym2ucs () from /var/u/kolya/mozilla/package/libwidget_gtk.so #14 0xee055340 in g_io_unix_dispatch (source_data=0x1e78b0, current_time=0xeffff230, user_data=0x196410) at giounix.c:135 #15 0xee057074 in g_main_dispatch (current_time=0xeffff230) at gmain.c:656 #16 0xee05788c in g_main_iterate (block=0, dispatch=1) at gmain.c:874 #17 0xee057aac in g_main_run (loop=0xfeb68) at gmain.c:932 #18 0xee1cad18 in gtk_main () at gtkmain.c:476 #19 0xee300f70 in nsAppShell::Run () from /var/u/kolya/mozilla/package/libwidget_gtk.so #20 0xee677a98 in nsAppShellService::Run () from /var/u/kolya/mozilla/package/components/libnsappshell.so #21 0x182f0 in NS_CanRun () #22 0x18a38 in main ()
Target Milestone: --- → M14
kolya@MIT.EDU, Thanks for the report but the Target Milestone field is reserved for developer triage. When a bug get's assigned the developer will set a Target Milestone based on when s/he thinks that they can get it fixed. I'm setting it back to null for now. This may be a duplicate of bug 26035. Can you take a look there and report back. Thanks
Target Milestone: M14 → ---
26035 doesn't seem terribly similar; looking at that bug's description seems to indicate mozilla just hangs in poll() there, whileas here it crashes with a segmentation fault. I would imagine the two are probably not the same bug.
kolya@mit.edu: can you let us know the build id (number in the lower right hand corner of the browser window).
Assignee: cbegle → selmer
Component: Browser-General → Profile Manager BackEnd
QA Contact: asadotzler → gbush
Determining the build ID by looking at the lower right hand corner of the window is fairly hard, since, as the bug report says, the window never opens :-)
kolya@MIT.EDU - are you still seeing this problem on recent builds of Mozilla? If you download it from a numbered directory in ftp://ftp.mozilla.org/pub/mozilla/nightly/ you can get the Build ID that way :-) Gerv
I'm still seeing this problem with the M14 binary. Unfortunately, I can't seem to be able to find any Solaris 2.6 binary more recent than that. Could you suggest a possible version to try?
It appears Solaris 2.6 versions of M15 have not been produced. There is also no Tinderbox for Solaris 2.6 at the moment (though I swear there used to be one). kolya@MIT.EDU - are you able to build Mozilla yourself? Gerv
From what I've seen so far, it looks like building mozilla would be rather involved and time-consuming, and thus I probably won't be able to build it myself for at least the next few weeks..
kolya@MIT.EDU - if you go to: http://tinderbox.mozilla.org/showbuilds.cgi?tree=SeaMonkey there's a tinderbox there for SunOS 5.6 which is currently green. This means that this machine is successfully building Mozilla for that platform. So, it seems that, if you did want to do more testing, getting Mozilla to compile wouldn't be too hard. We'd be very pleased to have you file bugs on that version of Mozilla :-) Gerv
need an update on whether this is still happening in recent nightlies
Keywords: qawanted
Whiteboard: need update
putting on [need update][6/16] radar. I'll close this bug up on 6/16 if no one with Solaris can still reproduce it (last known occurrence of this was with an old april M14 build)
Whiteboard: need update → [need update][6/16]
kolya@MIT.EDU, there are sparc-solaris binaries, the latest under http://ftp.mozilla.org/pub/mozilla/nightly/latest/mozilla-sparc-sun-solaris2.6.t ar.gz Please download it and report if your problem still occurrs or not. I will move the [need update] field to 06/23 to give you the time to test. Otherwise that bug will be closed.
Whiteboard: [need update][6/16] → [need update][6/23]
I've grabbed the last Solaris 2.6 build, and it appears to no longer crash. Thanks! I think that wraps up this bug report.
Resolving WORKFORME per comment of bug reporter
Status: UNCONFIRMED → RESOLVED
Closed: 24 years ago
Resolution: --- → WORKSFORME
ok
Status: RESOLVED → VERIFIED
Keywords: qawanted
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.