Closed Bug 221048 Opened 22 years ago Closed 22 years ago

mozilla-cvs dies with signal 11, but no core dump

Categories

(SeaMonkey :: General, defect)

Product:
SeaMonkey
Component:
General
Platform:
Sun
SunOS
Type:
defect
Priority:
Not set
Severity:
blocker

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 221422

People

(Reporter: lhecking, Unassigned)

Details

User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.5b) Gecko/20030901 Build Identifier: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.5b) Gecko/20030901 Solaris 8/SPARC 2/02 I was away for a while, and after I came back, I updated my working copy from cvs as usual. However, none of the sources pulled in from cvs this week (29/09/03+)generate a working browser. After starting mozilla from the compile directory, it eventually dies with exit code 11. No core dump is generated. Compiler, 3rd party software, machine, OS, patch level are all the same as before my holidays. I have several hundred kB of truss output, if someone wants to take a look; I can't make much sense of it. Reproducible: Always Steps to Reproduce: 1. ./dist/bin/mozilla 2. watch ... 3. Actual Results: $ ./dist/bin/mozilla $ echo $? 11 $ Expected Results: Open window etc.
This has been my experience as well on Linux with the last 2 nightly builds. My Linux is Redhat 9.0 with all current updates, running on an Athlon laptop. The browser fails to run at all, and produces no output. If I run MozillaFirebird -P I get /home/tim/data/rcv/MozillaFirebird/run-mozilla.sh: line 454: 1156 Segmentation fault "$prog" ${1+"$@"} on standard error.
The problem on Solaris is probably a dup of Bug 220777.
Yes, this is very possible. My compiler is gcc 2.95.3, and gtk+/glib are version 1.2.10, compiled with the same gcc. Anyway, I run mozilla under truss all night, but it didn't segv (similar to bug #220777). The program seems to be caught in an endless loop, and I'm reproducing the repeating parts from truss here: [...] 24071: sigprocmask(SIG_UNBLOCK, 0xFEB6FA00, 0x00000000) = 0 24071: read(8, 0xFFBEE24B, 1) Err#11 EAGAIN 24071: ioctl(3, FIONREAD, 0xFFBEE4F4) = 0 24071: poll(0x0029B7D8, 3, -1) (sleeping...) 24071: signotifywait() (sleeping...) 24071: poll(0xFDD81878, 1, -1) (sleeping...) 24071: lwp_sema_wait(0xFC531E30) (sleeping...) 24071: door_return(0x00000000, 0, 0x00000000, 0) (sleeping...) 24071: lwp_cond_wait(0xFEB75550, 0xFEB75560, 0xFEB6EDB8) (sleeping...) 24071: lwp_sema_wait(0xFEB6FA10) (sleeping...) 24071: Received signal #14, SIGALRM, in lwp_sema_wait() [caught] 24071: lwp_sema_wait(0xFEB6FA10) Err#91 ERESTART 24071: sigprocmask(SIG_SETMASK, 0xFE60BDE4, 0x00000000) = 0 24071: lwp_sema_post(0xFC531E30) = 0 24071: lwp_sema_wait(0xFC531E30) = 0 24071: sigprocmask(SIG_SETMASK, 0xFEB7AD70, 0x00000000) = 0 24071: setcontext(0xFE60B6C8) 24071: sigprocmask(SIG_BLOCK, 0xFEB6FA00, 0x00000000) = 0 24071: sigprocmask(SIG_UNBLOCK, 0xFEB6FA00, 0x00000000) = 0 24071: poll(0x0029B7D8, 3, -1) = 1 24071: write(13, "FA", 1) = 1 24071: write(11, " 8", 1) = 1 24071: poll(0xFDD81878, 1, -1) = 1 24071: read(10, " 8", 1024) = 1 24071: lwp_sema_post(0xFDD81E30) = 0 24071: lwp_sema_wait(0xFDD81E30) = 0 24071: lwp_mutex_wakeup(0xFEB75560) = 0 24071: lwp_mutex_lock(0xFEB75560) = 0 24071: lwp_sema_post(0xFC531E30) = 0 24071: lwp_sema_wait(0xFC531E30) = 0 24071: lwp_mutex_wakeup(0xFEB75560) = 0 24071: lwp_mutex_lock(0xFEB75560) = 0 24071: read(12, "FA", 1) = 1 24071: lwp_sema_post(0xFEB6FA10) = 0 24071: lwp_sema_wait(0xFEB6FA10) = 0 24071: sigprocmask(SIG_BLOCK, 0xFEB6FA00, 0x00000000) = 0 24071: setitimer(ITIMER_REAL, 0xFE60BC68, 0x00000000) = 0 24071: sigprocmask(SIG_UNBLOCK, 0xFEB6FA00, 0x00000000) = 0 24071: read(8, 0xFFBEE24B, 1) Err#11 EAGAIN 24071: ioctl(3, FIONREAD, 0xFFBEE4F4) = 0 24071: poll(0x0029B7D8, 3, -1) (sleeping...) 24071: signotifywait() (sleeping...) 24071: poll(0xFDD81878, 1, -1) (sleeping...) 24071: lwp_sema_wait(0xFC531E30) (sleeping...) 24071: door_return(0x00000000, 0, 0x00000000, 0) (sleeping...) 24071: lwp_cond_wait(0xFEB75550, 0xFEB75560, 0xFEB6EDB8) (sleeping...) 24071: lwp_sema_wait(0xFEB6FA10) (sleeping...) 24071: Received signal #14, SIGALRM, in lwp_sema_wait() [caught] 24071: lwp_sema_wait(0xFEB6FA10) Err#91 ERESTART 24071: sigprocmask(SIG_SETMASK, 0xFE60BDE4, 0x00000000) = 0 24071: lwp_sema_post(0xFC531E30) = 0 [...]
Does this work when you don't run it from the compile directory, but rather specify a full path when you run it? (i.e. instead of ./mozilla, type /path/to/mozilla/dist/bin/mozilla)
Yep, it does! Using it right now.
*** This bug has been marked as a duplicate of 221422 ***
Status: UNCONFIRMED → RESOLVED
Closed: 22 years ago
Resolution: --- → DUPLICATE
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.