set NSPR_LOG_MODULES=nsComponentManager:5 in the environment crashes mozilla at startup




17 years ago
16 years ago


(Reporter: Luke, Assigned: dougt)




Firefox Tracking Flags

(Not tracked)



(2 attachments)



17 years ago
I have

set NSPR_LOG_MODULES=nsComponentManager:5

as part of my build config.

When I start mozilla, it crashes at startup in xpcom.dll.
I can't get a stack trace, because if I load mozilla using
the debugger, it doesn't crash.

Comment 1

17 years ago
Here my research, copied from a mail to warren:

In nsLoggingService::Init, the environment variable NSPR_LOG_FILE is
read, and the log is opened.

in nsLogging.cpp:183, outputPath is set to the scope local variable
nspr_log_file, so in line 216, there is garbage in it, it goes to
error:, clears the gLogMonitor, and I'm doomed for the rest. That is, when
opening the log, the gLogMonitor is null.

It should be fixed, if we directly set outputPath in 179, instead of using the
local variable nspr_log_file.

I may test that later.

Btw, that error seems to be there since rev 1.1 :-?


Comment 2

17 years ago
I will submit a patch to fix this bug.
It depends on the patch for
But then I can do logging allright. Yep.

warren, r=?, sr by scc?, 58514 misses a sr, too. Should go in together, IMHO.

Depends on: 58514
Keywords: review

Comment 3

17 years ago
Created attachment 18637 [details] [diff] [review]
patch to fix NSPR_LOG_FILE, includes patch from 58514

Comment 4

17 years ago
Created attachment 19077 [details] [diff] [review]
updated fix

Comment 5

17 years ago
as the fix for 58514 is in, here is the updated patch.
How about a review?



17 years ago
Keywords: crash

Comment 6

17 years ago
what's happening of this one...?
if the fix is still valid, get a review using

Comment 7

17 years ago
Hi Henrik,
the patch should still be valid, I poked scc a few times, he's got a mail about
this in his inbox, what's more to do? Yes, poke again. Thanx :-).


Comment 8

17 years ago
Hi brendan,
care to take this one off of scc's broken hands? It's a half-a-brain 4 line


The fact that nspr_log_file is block-local means nothing, because the pointer it
contains is either null, or a valid pointer to a static string in the
environment passed on the stack by the kernel when the process was exec'd.  So I
don't understand the bug, but the patch still looks ok to me, because it
eliminates an unnecessary variable.

Hope I'm not just sleepy -- can someone enlighten me as to what bug this patch
is fixing?


Comment 10

17 years ago
Hi Brendan,
I'm on solaris, compiling with gcc. It used to free my buffer the moment I
leave the scope of nspr_log_file, thus giving me a segmentation fault.
I tried to reproduce this error today, without success. But this may be because
I couldn't make mozilla write something to a logfile. It openend allright the
logfile allright, but no content. IIRC, this crasher appeared while writing the
log. Wow, it's been a while.
Could we get this in anyway? I don't have time shortly to do a logging testcase.

What buffer gets freed?  As I wrote, the returned pointer from getenv points to
stack storage that lives as long as the process lives.

But the gratuitous variable elimination (nspr_log_file is unnecessary) works for
me, so go ahead and check in.  I just don't believe this will cure any crash bug
unless you have a broken compiler.

Component: XP Utilities → XPCOM

Comment 12

16 years ago
to default.
Assignee: warren → dougt

Comment 13

16 years ago
die, XPCOM logging, die.
nsLogging.cpp was removed, see
setting resolution to WONTFIX, as the code is still buggy in the Attic.
Last Resolved: 16 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.