If I do: NSPR_LOG_FILE=C:\TMP\IMAP.LOG NSPR_LOG_MODULES=IMAP:5 the lines in "C:\TMP\IMAP.LOG" gets cut after 200 chars. Meaning that I can only see the first 199 chars. Is this a bug in the NSPR logging?

NSPR logging is buffered. The default buffer size is 200. This is why you won't see the chars after the first 200 chars until the buffer fills up again. You can use PR_LogFlush() to flush the data in the buffer. You can use PR_SetLogBufferig to use a different buffer size or turn off buffering (by specifying a buffer size of 0). The logging buffer size can also be changed at run time with the special log module "bufsize". To turn off buffering at run time, you can either set "bufsize" to 0 or specify the special log module "sync" (synchronous logging). Note that in the comments in "prlog.h" as well as in the NSPR documentation (http://www.mozilla.org/docs/refList/refNSPR/prlog.html) we misspelled the "bufsize" log module as "buffsize".

"This is why you won't see the chars after the first 200 chars until the buffer fills up again." Hmm.. I never see the rest of the line data... Check fx the IMAP log in bug 46295 http://bugzilla.mozilla.org/showattachment.cgi?attach_id=12000 At the end of the log all the lines are cut off. Can I change the bufsize from the command line like: NSPR_LOG_BUFSIZE=2000 ?

Larry, could you take into why buffer overflow seems to be discarded? Thanks. To change buffer size from the command line, the environment variable to use is NSPR_LOG_MODULES. Specify the special log module "bufsize:2000", or "sync" (to turn off buffering).

I looked at PR_LogPrint and found that there is indeed a hard 200-char limit on a line: char line[LINE_BUF_SIZE]; LINE_BUF_SIZE is 200. This 'line' buffer is NOT the log buffer. It has a fixed size of 200, which means each PR_LOG can write at most 200 chars. We should document this limit. We can use PR_smprintf and not use PR_snprintf(line,...), then we won't be subject to the size of 'line'. But PR_smprintf incurs a malloc call overhead. I am not sure if the malloc overhead is worth it.

Wan-Teh's assesment looks good to me. I also believe that using malloc is not a good idea. At the same time, 200 looks a bit small for a log buffer to begin with. I suggest seting the value of LINE_BUF_SIZE to 512. This does not solve the problem in the general case, but does provide a more reasonable size of buffer for log messages. The documentation for PR_LOG() will be changed to document the restriction on the size of a log message written by PR_LOG().

Checking in prlog.c; /cvsroot/mozilla/nsprpub/pr/src/io/prlog.c,v <-- prlog.c new revision: 3.19; previous revision: 3.18 done Marking as fixed.

Perhaps it's just me but: http://lxr.mozilla.org/seamonkey/source/nsprpub/pr/src/io/prlog.c#107 still says 200 ?

The fix was checked into the tip of NSPR. SeaMonkey uses the NSPRPUB_CLIENT_BRANCH of NSPR. This is why you don't see the fix in the SeaMonkey version of the file prlog.c. If you need this fix for SeaMonkey, we need to get approval from brendan or waterson. I would recommend that you work around this bug. Is it possible to change your logging code so that each line is < 200 char long?

Why would you "recommend that you work around this bug"?

SeaMonkey is using NSPR 4.0, a released product. We only fix critical bugs in a released product. Furthermore, all bug fixes in SeaMonkey must be approved by brendan or waterson now. Again, we need to make the case that this fix is critical. Since this bug can be worked around (by logging short lines), I don't consider it a critical bug. But I can be convinced. In any case, it will be fixed in NSPR 4.1.

I think it would be less than efficient to go change all the modules that use NSPR logging to break up their lines into less than 200 characters - I would much rather have this fixed in NSPR, especially since it is already fixed in NSPR. CC'ing Brendan and Chris for comments.

Sure, make the change on the branch.

Client Branch has been updated. There is still a fixed log assembly buffer; its size is now 512 bytes.

marking as fixed

I'm now able to see much more, but still not the entire log command.... Build 2000083004 on Windows 2000.

Just how big did you have in mind?

When debugging IMAP command there shouldn't be any cutoff....

... and if wishes were horses, beggars could ride. It is all technically possible to satisfy your requirement: unlimited buffer size for PR_LOG(). There is a performance penalty for using malloc() to allocate the buffer each time it is used. A large (how large?) buffer could be permanently allocated per thread to solve the malloc() performance problem, but now we have a memory footprint problem and still have not solved the "unlimited sized" requirement. A reasonable compromise is the larger (512 byte) fixed size buffer that we implemented.

Why is this a "performance problem", when it's only used in debugging mode? The average user would never see this problem, since the NSPR_LOG ENV settings aren't set. I as a developer could live with this "perf problem" when I want to debug an IMAP command. Personally it's more important for to see the entire IMAP command than to travel with max speed.