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

RESOLVED WONTFIX

Status

()

Core
XPCOM
P3
normal
RESOLVED WONTFIX
17 years ago
16 years ago

People

(Reporter: Luke, Assigned: dougt)

Tracking

({crash})

Trunk
Other
Other
crash
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

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 :-?

Axel

Comment 2

17 years ago
I will submit a patch to fix this bug.
It depends on the patch for http://bugzilla.mozilla.org/show_bug.cgi?id=58514
But then I can do logging allright. Yep.

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

Axel
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
Hi,
as the fix for 58514 is in, here is the updated patch.
How about a review?

Axel

Updated

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
http://www.mozilla.org/hacking/reviewers.html

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 :-).

Axel

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
patch.

Thanks,

Axel
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?

/be

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.

Axel
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.

/be
Component: XP Utilities → XPCOM
(Assignee)

Comment 12

16 years ago
to default.
Assignee: warren → dougt

Comment 13

16 years ago
die, XPCOM logging, die.
nsLogging.cpp was removed, see
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=mozilla%2Fxpcom%2Fbase&file=nsLogging.cpp&filetype=match&who=&whotype=match&sortby=Who&hours=2&date=explicit&mindate=11%2F1%2F2001&maxdate=1%2F1%2F2002&cvsroot=%2Fcvsroot
setting resolution to WONTFIX, as the code is still buggy in the Attic.
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.