Closed Bug 70235 Opened 24 years ago Closed 15 years ago

crash on start if /dev/zero not writable

Categories

(Core :: XPCOM, defect)

Product:
Core
Component:
XPCOM
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED INCOMPLETE

People

(Reporter: johannes.lehtinen, Unassigned)

References

Details

(Keywords: crash) 

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.18 i586; en-US; 0.8) Gecko/20010215
BuildID:    2001021503

Mozilla 0.8 binary dist with talkback crashes on startup if /dev/zero is not
writable. It tries to open /dev/zero in O_RDWR mode (is there any reason to do
so?) and fails to handle the error situation nicely.

Reproducible: Always
Steps to Reproduce:
to reproduce:
  chmod a-w /dev/zero
  mozilla

workaround:
  chmod a+rw /dev/zero


Actual Results:  Mozilla segfaults before opening any windows. See the strace
and backtrace in additional information.



Expected Results:  Startup view opened.

Detected on:
  Linux 2.0.18
  glibc 2.1.2
  custom setup of Linux

Strace on segfault:

...
open("/dev/zero", O_RDWR) = -1 EACCES (Permission denied)
old_mmap(NULL, 1056768, PROT_READ|PROT_WRITE, MAP_PRIVATE, -1, 0) = -1 EBADF
(Bad file descriptor)
close(-1) = -1 EBADF (Bad file descriptor)
mkdir("/home/jle/.fullcircle", 0777) = -1 EEXIST (File exists)
stat("/home/jle/.fullcircle", {st_mode=S_IFDIR|0750, st_size=1024, ...}) = 0
open("/dev/zero", O_RDWR) = -1 EACCES (Permission denied)
old_mmap(NULL, 1056768, PROT_READ|PROT_WRITE, MAP_PRIVATE, -1, 0) = -1 EBADF
(Bad file descriptor)
close(-1) = -1
EBADF (Bad file descriptor)
--- SIGSEGV (Segmentation fault)
--- +++ killed by SIGSEGV +++ 


Backtrace on segfault:

(gdb) bt
#0  0x4024a4de in __sigsuspend (set=0xbfffe4bc) at
../sysdeps/unix/sysv/linux/sigsuspend.c:48
#1  0x401ba823 in __pthread_create_2_1 (thread=0xbfffe608, attr=0xbfffe610,
start_routine=0x401a435c <PR_Select+692>, arg=0x81098e8) at restart.h:32
#2  0x401a475c in PR_Select ()
#3  0x401a489c in PR_CreateThread ()
#4  0x400cb669 in nsThread::Init ()
#5  0x400cb742 in NS_NewThread ()
#6  0x40808f53 in NSGetModule ()
#7  0x40808d60 in NSGetModule ()
#8  0x400c0f69 in nsGenericFactory::CreateInstance ()
#9  0x400bebba in nsComponentManagerImpl::CreateInstance ()
#10 0x400c5d48 in nsComponentManager::CreateInstance ()
#11 0x400c68bf in nsServiceManagerImpl::GetService ()
#12 0x400c6e10 in nsServiceManager::GetService ()
#13 0x40803dcc in NSGetModule ()
#14 0x4080415e in NSGetModule ()
#15 0x400c0f69 in nsGenericFactory::CreateInstance ()
#16 0x400bebba in nsComponentManagerImpl::CreateInstance ()
#17 0x400c5d48 in nsComponentManager::CreateInstance ()
#18 0x400c68bf in nsServiceManagerImpl::GetService ()
#19 0x400c6e10 in nsServiceManager::GetService ()
#20 0x40460bbd in NSGetModule ()
#21 0x40466bb8 in NSGetModule ()
#22 0x40467013 in NSGetModule ()
#23 0x400c0f69 in nsGenericFactory::CreateInstance ()
#24 0x400bebba in nsComponentManagerImpl::CreateInstance ()
#25 0x400c5d48 in nsComponentManager::CreateInstance ()
#26 0x400c68bf in nsServiceManagerImpl::GetService ()
#27 0x400c6c9d in nsServiceManagerImpl::GetService ()
#28 0x400c6f18 in nsServiceManager::GetService ()
#29 0x400c61ac in nsGetServiceByContractID::operator() ()
#30 0x400d1321 in nsCOMPtr_base::assign_from_helper ()
#31 0x400aaa88 in nsFSStringConversion::PrepareFSCharset ()
#32 0x400aab48 in nsFSStringConversion::PrepareEncoder ()
#33 0x400aad65 in nsFSStringConversion::UCSToNewFS ()
#34 0x400ab248 in NS_NewUnicodeLocalFile ()
#35 0x407e8e91 in NSGetModule ()
#36 0x407e6135 in NSGetModule ()
#37 0x407e4d29 in NSGetModule ()
#38 0x407dee57 in NSGetModule ()
#39 0x407e4b40 in NSGetModule ()
#40 0x400c0f69 in nsGenericFactory::CreateInstance ()
#41 0x400bebba in nsComponentManagerImpl::CreateInstance ()
#42 0x400c5d48 in nsComponentManager::CreateInstance ()
#43 0x400c68bf in nsServiceManagerImpl::GetService ()
#44 0x400c6c9d in nsServiceManagerImpl::GetService ()
#45 0x400c6f18 in nsServiceManager::GetService ()
#46 0x400c61ac in nsGetServiceByContractID::operator() ()
#47 0x400d1321 in nsCOMPtr_base::assign_from_helper ()
#48 0x804d33b in JS_PushArguments ()
#49 0x804dbf5 in JS_PushArguments ()
#50 0x804e595 in JS_PushArguments ()
#51 0x402445ce in __libc_start_main (main=0x804e468 <JS_PushArguments+12460>,
argc=1, argv=0xbffffa74, init=0x804af1c <_init>, fini=0x8053d84 <_fini>,
rtld_fini=0x40009950 <_dl_fini>, stack_end=0xbffffa6c) at
../sysdeps/generic/libc-start.c:90
(gdb)
Probably due to
http://lxr.mozilla.org/seamonkey/source/xpcom/build/malloc.c#1425 -- we open
/dev/zero O_RDWR and then mmap it without checking the return value of open()....
updating component
Assignee: asa → scc
Status: UNCONFIRMED → NEW
Component: Browser-General → XPCOM
Ever confirmed: true
QA Contact: doronr → kandrot
Why would /dev/zero not be writable?

Is /dev/null more likely to be writable than /dev/zero (and does it work in the 
same way)?
/dev/null is more likely to be writable than /dev/zero, yes.  If only because
writing to /dev/null is such a common way to ditch program output that any
sysadmin who disabled writing to /dev/null would change his/her mind _really_
quickly.
Alright, so how about changing the filename to /dev/null, and adding an 
assertion that the open succeeded.  (Couldn't the open fail for other reasons, 
such as having too many files open, btw?)
Unfortunately, _reading_ from /dev/null just gives EOF.

Basically, we need to check the return value of that open() and do something
sane of failure.

is this why with each new build loaded the very first launch crashes??
subsequent launches proceed fine.

I've been seeing that behavior on the daily builds for some time now.
I saw this on windows with commercial build 2001-03-07-06-mtrunk
OS: Linux → All
Hardware: PC → All
This also crashes on Linux (2001-03-07-08-Mtrunk)after first time launching
the browser.
I did not see this yesterday nor today on linux commercial build 
2001-03-13-05-mtrunk
Severity: normal → critical
Keywords: crash
Bug 149493 says Slackware 8.0 makes /dev/zero read-only by default.
*** Bug 149493 has been marked as a duplicate of this bug. ***
I think this must have been fixed once, and then resurfaced for 1.0 - builds up
to and including 1.0rc3 worked fine for me.

Whatever's writing to /dev/zero should write to /dev/null instead, yes?
I suspect the code at 
http://lxr.mozilla.org/seamonkey/source/xpcom/build/malloc.c#1425 is the 
issue...  Also, the search for /dev/zero shows us opening it as O_RDWR in  a 
number of places.... 
(http://lxr.mozilla.org/seamonkey/search?string=%2Fdev%2Fzero)
*** Bug 150564 has been marked as a duplicate of this bug. ***
*** Bug 302857 has been marked as a duplicate of this bug. ***
*** Bug 245999 has been marked as a duplicate of this bug. ***
QA Contact: kandrot → nobody
Assignee: scc → nobody
QA Contact: nobody → xpcom
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.