Closed Bug 632007 Opened 13 years ago Closed 9 years ago

vast numbers of zero (nul) bytes wrote into the log file by child process (log file concurrency)

Categories

(Core :: Networking: HTTP, defect)

Product:
Core
Component:
Networking: HTTP
Platform:
x86_64
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 1219466

People

(Reporter: hsivonen, Unassigned)

References

(
URL
)

Details

Steps to reporoduce:
 1) Make a debug build of the trunk on Linux64 (I used Ubuntu Maverick)
 2) Enable HTTP logging per instructions in https://developer.mozilla.org/en/HTTP_Logging#Linux
 3) Launch Firefox.
 4) Navigate to http://nol.hu/index.html
 5) View Source.
 6) Quit the app.
 7) Read the HTTP logging log file using the command 'less'.

Actual results:
less asks if you want to view a binary file. When viewed, it has a lot of zero bytes. After the zero bytes, there's some logging data, but clearly not all the logging data there was supposed to be.

Expected results:
No zero bytes in the log file. All HTTP activity logged.


Marking as having severity of "blocker", because this blocks me from investigating bug 622579.

Marking security-sensitive in case the zeros come from a buffer overrun somewhere.
Is this a regression? If so, can you provide a regression range?
Severity: blocker → normal
I can reproduce with a fresh profile, the STR from comment 0 and installed latest flash plugin.

-> me
Assignee: nobody → honzab.moz
Status: NEW → ASSIGNED
So, the cause is, that plugin-container opens the log file again.  At that moment the file is filled with zero bytes.  This seems to be some bug in windows' crt implementation.  We use newLogFile = fopen(file, "w"); to access the file.


I believe this is more or less duplicate of bug 534764.
Depends on: 534764
> I believe this is more or less duplicate of bug 534764.

Well, fixing bug 534764 will fix this.  But keeping this bug open so users who sees the null bytes will see a bug description that's sensible.

Henri:  for you purposes you should be able to proceed with debugging by applying the patch from bug 534764 comment 31.  (Note you'll need to set NSPR_LOG_FILE_CHILD, too.  And note that this probably won't be our actual method for solving the bug in the long run).
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → DUPLICATE
Sigh.  Meant to keep this open.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Just a note that a patch in that bug is more or less experimental and I have absolutely no feedback on it so far.  So it might in general be quit wrong.
Jason -- based on bug 534764 comment 51, is this a security bug? Should it be kept hidden?
No, this is not a security bug
Group: core-security
Depends on: 638375
Assignee: honzab.moz → nobody
Status: REOPENED → NEW
Summary: HTTP logging writes vast numbers of zero (nul) bytes into the log file → vast numbers of zero (nul) bytes wrote into the log file by child process (log file concurrency)
LazyLogModule has fixed this for us
Status: NEW → RESOLVED
Closed: 13 years ago → 9 years ago
Resolution: --- → FIXED
Resolution: FIXED → DUPLICATE
You need to log in before you can comment on or make changes to this bug.