Closed
Bug 612093
Opened 14 years ago
Closed 14 years ago
PR_ASSERT should not be silent on Windows
Categories
(NSPR :: NSPR, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
4.8.7
People
(Reporter: jruderman, Assigned: jruderman)
Details
Attachments
(1 file, 1 obsolete file)
647 bytes,
patch
|
wtc
:
review+
|
Details | Diff | Splinter Review |
PR_ASSERT's silence confuses my fuzzer into thinking that Firefox exited suddenly for no reason at all. (In case you're curious, I'm hitting bug 345094.) wtc suggested this fix long ago (bug 183952 comment 5) and timeless objected for a reason I do not understand. See bug 561672 for why I included an fflush.
Attachment #490448 -
Flags: review?(wtc)
Comment 1•14 years ago
|
||
Jesse, On MSWindows, programs built to be "Windows" programs (as opposed to those built to be "console" programs, e.g. Unix-like filters) close stdin, stdout and stderr soon after startup. All Mozilla's programs on MSWindows are Windows programs. Consequently, the write and flush you propose to do to stderr will be writes to closed file descriptors on windows, when used in "Windows" (not "console") type programs. Your proposed change would work OK in (say) NSS and NSPR command line test programs, all of which are "console" programs, but would do nothing (or worse) in Mozilla products on MSWindows. In light of that fact, do you really want to go ahead with this change?
Assignee | ||
Comment 2•14 years ago
|
||
If I run a debug build of Firefox from the command line, I see plenty of stdout and stderr output. I tested the patch and it fixed a bug on Windows 7. So I don't know what you're talking about.
Comment 3•14 years ago
|
||
I personally had the experience of adding lots of debug printf to stderr, only to see it come to naught on Windows. But that was years ago. I'm assuming it's still true, but maybe this has changed in the last 8 years. It was certainly true for a long time.
jesse: in this case I object to you not pushing on in my bug. nelson: debug builds are console apps which is why jesse's "solution" would "fix" his version of the problem. And why it wouldn't help anyone else.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → DUPLICATE
Assignee | ||
Comment 5•14 years ago
|
||
The current patch in bug 183952 does not look like it fixes this bug.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Comment 6•14 years ago
|
||
Comment on attachment 490448 [details] [diff] [review] patch You can just remove this ifdef: >+#if defined(XP_UNIX) || defined(XP_OS2) || defined(XP_BEOS) || defined(WIN32) as it covers all the platforms. > fprintf(stderr, "Assertion failure: %s, at %s:%d\n", s, file, ln); >+ fflush(stderr); I believe we didn't add an fflush() because stderr is not buffered.
Assignee | ||
Comment 7•14 years ago
|
||
I needed fflush in JS_Assert (bug 561672), but maybe I don't need it here.
Assignee | ||
Comment 8•14 years ago
|
||
The fflush is needed here. I tested with automation.py and a testcase from bug 345094 on Windows 7. Without the fflush, the assertion message didn't come through.
Status: REOPENED → ASSIGNED
Assignee | ||
Comment 9•14 years ago
|
||
This version of the patch removes the ifdef.
Attachment #490448 -
Attachment is obsolete: true
Attachment #490823 -
Flags: review?(wtc)
Attachment #490448 -
Flags: review?(wtc)
Comment 10•14 years ago
|
||
Comment on attachment 490823 [details] [diff] [review] patch v2 r=wtc. Patch checked in on the NSPR trunk (NSPR 4.8.7). Checking in prlog.c; /cvsroot/mozilla/nsprpub/pr/src/io/prlog.c,v <-- prlog.c new revision: 3.53; previous revision: 3.52 done
Attachment #490823 -
Flags: review?(wtc) → review+
Updated•14 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 14 years ago → 14 years ago
Resolution: --- → FIXED
Target Milestone: --- → 4.8.7
You need to log in
before you can comment on or make changes to this bug.
Description
•