158240 - setting NSPR_LOG_FILE causing mozilla to crash on startup global constructors keyed to TimerThread::AddRef(

Status: RESOLVED FIXED

(NSPR :: NSPR, defect)

Description

[Paul]

Mozilla will crash on startup, with a segment violation, if NSPR_LOG_FILE is set.

loading symbols
segment violation occurred
strlen:
strlen:
+0031  ec068d91:   *          088b    movl    (%eax), %ecx
mozilla-bin:sc
   frame         retaddr
fcfffaa0   ecb2bd0c  dosprintf + 0000091c
fcfffbc8   ecb2c2b0  PR_vsnprintf + 00000078
fcfffbfc   ecb29c42  PR_LogPrint + 000000aa
fcfffe24   ecb2ec8b  _PR_InitLinker + 00000087
fcfffe3c   ecb36a5a  _PR_InitStuff + 0000020e
fcfffe48   ecb36a99  _PR_ImplicitInitialization + 00000015
fcfffe54   ecb29a1f  PR_NewLogModule + 00000023
fcfffe64   ec99a744  global constructors keyed to TimerThread::AddRef(void) +
00000020
fcfffe74   ec9d89c6  __do_global_ctors_aux + 00000026
fcfffe84   ec9244f5  ._init + 0000001c
fcfffe90   ec083eae  call_routine_in_order + 0000012e
fd0012f8   ec08427a  _call_init_routines_ + 000000a6
fd001750   8001bc5a  _start + 00000056

Comment 1

[timeless]

xpcom timers?

Comment 2

[Wan-Teh Chang]

Paul,

Please use a debug build NSPR library to get more debug
information, such as line numbers and variable values.

Comment 3

[Wan-Teh Chang]

Also, what is the value of NSPR_LOG_FILE?

Comment 4

[Paul]

I have debug enabled, or does NSPR use its own debug flags?
Oh, and I had NSRP_LOG_FILE=logfile.txt
It created the file empty file before it crashed.

Comment 5

[Doug Turner (:dougt)]

http://www.mozilla.org/projects/nspr/reference/html/prlog.html

What is your NSPR_LOG_MODULES set to?

Comment 6

[Paul]

I had it set to all:5 (everything)
If NSPR_LOG_FILE was not set, all the PRLog info went to stderr just fine.

Comment 7

[Wan-Teh Chang]

Mozilla passes its configure options to NSPR, so if
you have debug enabled, then you have a debug NSPR
build.

I have no idea what's wrong.  Is it possible for you
to get a stack trace with file names and line numbers?

Comment 8

[Paul]

Sergei, can you see if you can reproduce this problem?  I want to make sure it is not 
just my build :)

Comment 9

[Sergei Dolgov]

Confirming.

Comment 10

[Sergei Dolgov]

Attachment: nspr.log file

Reason for crash is simle
No #ifdef XP_BEOS
in
http://lxr.mozilla.org/nspr/source/nsprpub/pr/src/linking/prlink.c#186

nspr.log is obtained by duplicating XP_UNIX code for XP_BEOS with some
exclusions

Comment 11

[Sergei Dolgov]

Attachment: quick patch

Hope nspr gurus will look at this patch with more competent sight.
I excluded there part of code for shared libs - to get it compiled

Comment 12

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Back to NSPR based on above comments and patch.

Comment 13

[Paul]

Comment on attachment 92727 [details] [diff] [review]
quick patch

Even though BeOS does not USE_DLFCN, it does not hurt to have it there.

Comment 14

[Wan-Teh Chang]

The correct fix is to find out whether BeOS has a special
image_id that represents the executable program image, that
is, the equivalent of Windows' GetModuleHandle(NULL) and
Unix's dlopen(0, RTLD_LADY).

If not, the second best fix is to replace

#ifndef XP_MAC

by

#if !defined(XP_MAC) && !defined(XP_BEOS)

in _PR_InitLinker.  (There are two occurrences of XP_MAC.)

Comment 15

[Wan-Teh Chang]

Comment on attachment 92727 [details] [diff] [review]
quick patch

This patch is incorrect if USE_DLFCN is undefined
because 'h' is not initialized.  BeOS does not
define USE_DLFCN.

'h' should be set to the image_id that represents
the executable program image.

Comment 16

[Paul]

Attachment: updated patch as per wtc's comments

Updated patch, thanks wtc.  Tested, and can set NSPR_LOG_FILE with this patch
applied

Comment 17

[Paul]

Comment on attachment 126268 [details] [diff] [review]
updated patch as per wtc's comments

wtc, if you could review/check this it, that would be great!  (i don't have
access to check in code under nsprpub)

Comment 18

[timeless]

cls/wtc, could one of you please check this in?

Comment 19

[Paul]

Could someone kindly check this patch in?  I do not have access to the NSPR
branch, otherwise I would do it.

Thanks!

Comment 20

[Wan-Teh Chang]

Paul, I can check this in when the Mozilla tree reopens for
Mozilla 1.6 alpha.

Comment 21

[Wan-Teh Chang]

Fix checked into the NSPR trunk (NSPR 4.5) and
NSPRPUB_PRE_4_2_CLIENT_BRANCH (Mozilla 1.6 alpha).