Reproduce: 1. Define DEBUG_BenB (activates some printfs in mozTXTToHTMLConv) and recompile netwerk/streamconv/converters 2. Create (with any mailer) a plain text msg with a string <number>% <char> e.g. 7% s 3. View the msg. Actual Result: You see ScanTXT original: 7¸Õ;@¸Õ;@ ScanTXT result: on the console, immediately followed by a crash. Expected Result: ScanTXT original: 7% s ScanTXT result: 7% s Additional Comments: - Appearently correct output in the msg pane (without crash), if DEBUG_BenB is not defined - It's not the nsString.ToNewCString, which crashes - I'm using UW-IMAP - 4.x seems to have no problem - I have no idea, what's going on :-)

Ben, can you give a stack trace? Need to know if we're using NSPR's printf, or if it's the native CRT printf.

Putting crash in the keyword field.

I'll give the stacktrace, when I have more time.

Waiting for stack trace, or some other clue to know who the right owner for this bug is.

Yes, you'll get that stacktrace (assuming I can get gdb to work), this is still on my tasklist :-)

Reassign back to Ben.

(gdb) bt #0 0x4051372a in _IO_vfprintf (s=0xbfffc2d4, format=0x858e530 "7% s\n", ap=0xbfffea44) at vfprintf.c:1259 #1 0x405166b4 in buffered_vfprintf (s=0x404a3180, format=0x858e530 "7% s\n", args=0xbfffea40) at vfprintf.c:1758 #2 0x40511f66 in _IO_vfprintf (s=0x404a3180, format=0x858e530 "7% s\n", ap=0xbfffea40) at vfprintf.c:1029 #3 0x40519f70 in printf (format=0x858e530 "7% s\n") at printf.c:31 #4 0x4063c4c6 in mozTXTToHTMLConv::ScanTXT (this=0x85fc548, text=@0xbfffecb4, whattodo=14) at mozTXTToHTMLConv.cpp:982 #5 0x4063caf2 in mozTXTToHTMLConv::ScanTXT (this=0x85fc548, text=0x8929950, whattodo=14, _retval=0xbfffee4c) at mozTXTToHTMLConv.cpp:1118 (Not the tree version of mozTXTToHTMLConv, so don't trust the line numbers.)

I am not sure why this is assigned to the NSPR module; there are no NSPR functions in the stack trace.

I didn't know, where the function is implemented. NSPR is better than mailnews :). So, this is a glibc-bug? I'm using glibc 2.1.2 from RH6.1 on an originally RH6.0 system.

Assigning to browser component.

Erm... this looks like a bug in the code in |void mozTXTToHTMLConv::ScanTXT|. The stack trace shows the string being printed has a "% s" in it. This isn't directly in the code, so it's clear that it must come from the lines: printf(tmp.ToNewCString()); which dereference a pointer to garbage when there is a "% s" in tmp. I'd think what you want is (for 1041-1045 and 1096-1100): nsCString tmp; tmp.AssignWithConversion(aInString); /* second time aOutString */ printf("ScanHTML orginal: %s\n",tmp.ToNewCString()); You don't want to use random user input as the first argument to a printf, since it might contain "%". My memory of variable argument handling in C is a little rusty, but I don't know how printf is supposed to know when its arguments are done to prevent this crash. Reassigning to reporter and changing component.

David, I didn't know, that "%" is always a special character in |printf|s forst argument (I prefer to ignore C whenever I can). Thanks for the note and workaround. This bug is propably a libc bug then (I still consider this being a bug, because it is a crash). Marking INVALID.

VERIFIED: per email from wtc

yeah, verified "Reporter had no clue".