Closed Bug 245999 Opened 22 years ago Closed 21 years ago

segmentation fault in pthread_mutex_init

Categories

(SeaMonkey :: General, defect)

Product:
SeaMonkey
Component:
General
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 70235

People

(Reporter: jarausch, Unassigned)

Details

(Keywords: crash)

User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040608 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040608 Version 1.7RCx 1 <= x <= 3 runs fine on my P3 based Linux-From-Scratch system with glibc 2.3.2 But on the same system on an AMD based machine I get a segmentation fault: 4 % /usr/local/mozilla-1.7RC3/mozilla --debug --debugger gdb /usr/local/mozilla-1.7RC3/run-mozilla.sh -g -d gdb /usr/local/mozilla-1.7RC3/mozilla-bin MOZILLA_FIVE_HOME=/usr/local/mozilla-1.7RC3 LD_LIBRARY_PATH=/usr/local/mozilla-1.7RC3:/usr/local/mozilla-1.7RC3/plugins:/usr/local/lib/mre/mre-1.7 DISPLAY=localhost:10.0 DYLD_LIBRARY_PATH=/usr/local/mozilla-1.7RC3:/usr/local/lib/mre/mre-1.7 LIBRARY_PATH=/usr/local/mozilla-1.7RC3:/usr/local/mozilla-1.7RC3/components:/usr/local/lib/mre/mre-1.7 SHLIB_PATH=/usr/local/mozilla-1.7RC3:/usr/local/lib/mre/mre-1.7 LIBPATH=/usr/local/mozilla-1.7RC3:/usr/local/lib/mre/mre-1.7 ADDON_PATH=/usr/local/mozilla-1.7RC3 MOZ_PROGRAM=/usr/local/mozilla-1.7RC3/mozilla-bin MOZ_TOOLKIT= moz_debug=1 moz_debugger=gdb /usr/local/bin/gdb /usr/local/mozilla-1.7RC3/mozilla-bin -x /tmp/mozargs3871 GNU gdb 6.0 Copyright 2003 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-linux-gnu"... (no debugging symbols found)... (gdb) run Starting program: /LOCAL/nlocal/mozilla-1.7RC3/mozilla-bin (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...[New Thread 16384 (LWP 3877)] (no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...[New Thread 32769 (LWP 3879)] [New Thread 16386 (LWP 3880)] (no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)... Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 3877)] 0x400e187d in pthread_mutex_init () from /lib/libpthread.so.0 Reproducible: Always Steps to Reproduce: 1. just start mozilla 2. 3.
Is your AMD 64-bit or 32-bit ?
Keywords: crash
SOLVED Beginning with version 1.7 mozilla opens /dev/zero in read/write mode It doesn't seem to check the open where it gets 'permission denied' on my system, since I have no world write access to /dev/zero .
Helmut Jarausch: Should this bug be resolved as WORKSFORME or there is still any issue?
(In reply to comment #3) > Helmut Jarausch: Should this bug be resolved as WORKSFORME or there is still any > issue? Well, removing write permissions from /dev/zero makes mozilla (1.7) segfault reproducably. Normally /dev/zero is used for input only (in contrast to /dev/null). Anyway, mozilla should check if opening /dev/zero for output succeeds. It was just by chance that I found out the reason for this segfault. A message "opening /dev/zero permission denied" would be much clearer.
Product: Browser → Seamonkey
*** This bug has been marked as a duplicate of 70235 ***
Status: UNCONFIRMED → RESOLVED
Closed: 21 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.