928 - Multiple windows crash - fix

Status: VERIFIED FIXED

(MozillaClassic Graveyard :: NetLib, defect, P2)

Description

[Bryce Harrington]

Don't know if NetLib is the right component or not...

I'm running WinNT4.0 SR3, on a 166MHz Dell Pentium with 64MB RAM and
200MB swap.  In addition to WinNT processes and mozilla, I am running
cdplayer.exe, MSACCESS, TASKMGR, MSDEV, CRT, and a notepad-like editor.

This bug occurs after multiple windows are opened.  For example, opening 4-8
links in a new window.  The bug seems to occur 15-30 sec after opening the last
window.

Here's the stack trace (sorry, kinda long):

strlen() line 66
cvt_s(SprintfStateStr * 0x0012f328, char * 0xdddddddd, int 0x00000000, int
0x0000076c, int 0x00000001) line 369 + 19 bytes
dosprintf(SprintfStateStr * 0x0012f328, char * 0x00952bc0, char * 0x0012f584)
line 971 + 25 bytes
PR_vsnprintf(char * 0x0012f368, unsigned int 0x00000200, char * 0x00952b68, char
* 0x0012f574) line 1180 + 17 bytes
_MK_TraceMsg(char * 0x00952b68) line 86 + 28 bytes
NET_ProcessNet(PRFileDesc * 0x00000000, int 0x00000001) line 3451 + 82 bytes
net_process_slow_net_timer_callback(void * 0x00000000) line 216 + 9 bytes
wfe_ProcessTimeouts(unsigned long 0x05f4ea17) line 303 + 12 bytes
FireTimeout(HWND__ * 0x000c035c, unsigned int 0x00000113, unsigned int
0x00000309, unsigned long 0x05f4ea17) line 60 + 9 bytes
USER32! 77e71ab7()
USER32! 77e71a77()
NTDLL! 77f7624f()
USER32! 77e7288d()
USER32! 77e72918()
CWnd::DefWindowProcA(unsigned int 0x00000112, unsigned int 0x0000f077, long
0x013603f4) line 938 + 32 bytes
CWnd::WindowProc(unsigned int 0x00000112, unsigned int 0x0000f077, long
0x013603f4) line 1523 + 26 bytes
AfxCallWndProc(CWnd * 0x00b51470 {CNetscapeView hWnd=0x000608ee}, HWND__ *
0x000608ee, unsigned int 0x00000112, unsigned int 0x0000f077, long 0x013603f4)
line 210 + 26 bytes
AfxWndProc(HWND__ * 0x000608ee, unsigned int 0x00000112, unsigned int
0x0000f077, long 0x013603f4) line 363 + 25 bytes
AfxWndProcBase(HWND__ * 0x000608ee, unsigned int 0x00000112, unsigned int
0x0000f077, long 0x013603f4) line 203 + 21 bytes
USER32! 77e7288d()
USER32! 77e72918()
PaneProc(HWND__ * 0x000608ee, unsigned int 0x00000112, unsigned int 0x0000f077,
long 0x013603f4) line 1422 + 26 bytes
USER32! 77e71ab7()
USER32! 77e71a77()
NTDLL! 77f7624f()
USER32! 77e7288d()
USER32! 77e72918()
CWnd::DefWindowProcA(unsigned int 0x000000a1, unsigned int 0x00000007, long
0x013603f4) line 938 + 32 bytes
CWnd::WindowProc(unsigned int 0x000000a1, unsigned int 0x00000007, long
0x013603f4) line 1523 + 26 bytes
AfxCallWndProc(CWnd * 0x00b51470 {CNetscapeView hWnd=0x000608ee}, HWND__ *
0x000608ee, unsigned int 0x000000a1, unsigned int 0x00000007, long 0x013603f4)
line 210 + 26 bytes
AfxWndProc(HWND__ * 0x000608ee, unsigned int 0x000000a1, unsigned int
0x00000007, long 0x013603f4) line 363 + 25 bytes
AfxWndProcBase(HWND__ * 0x000608ee, unsigned int 0x000000a1, unsigned int
0x00000007, long 0x013603f4) line 203 + 21 bytes
USER32! 77e7288d()
USER32! 77e72918()
PaneProc(HWND__ * 0x000608ee, unsigned int 0x000000a1, unsigned int 0x00000007,
long 0x013603f4) line 1422 + 26 bytes
USER32! 77e71250()
013603f4()


This bug seems to have its start in mkgeturl.c.  Here's the code (line 3461):

else
{
	/* XP_OS2_FIX IBM-MAS: limit size of URL string to 100 to keep from
blowing trace message buffer! */
      TRACEMSG(("End of transfer, entry (soc=%d, con=%d) being removed from list
with %d status: %-.1900s",
			tmpEntry->socket, tmpEntry->con_sock, tmpEntry->status,
/* >> */		(tmpEntry->URL_s->address ? tmpEntry->URL_s->address :
"")));
	/* catch out of memory errors at the lowest
	 * level since we don't do it at all the out
	 * of memory condition spots
	 */
	if(tmpEntry->status == MK_OUT_OF_MEMORY
			&& !tmpEntry->URL_s->error_msg)
    		{

The error seems to crop up as a result of the trace message, so try #ifdef'ing
it out:

else
{
	/* XP_OS2_FIX IBM-MAS: limit size of URL string to 100 to keep from
blowing trace message buffer! */
#ifdef DONTUSE
      TRACEMSG(("End of transfer, entry (soc=%d, con=%d) being removed from list
with %d status: %-.1900s",
			tmpEntry->socket, tmpEntry->con_sock, tmpEntry->status,
 			(tmpEntry->URL_s->address ? tmpEntry->URL_s->address :
"")));
#endif
	/* catch out of memory errors at the lowest
	 * level since we don't do it at all the out
	 * of memory condition spots
	 */
	if(tmpEntry->status == MK_OUT_OF_MEMORY
			&& !tmpEntry->URL_s->error_msg)
    		{

Comment 1

[Gagan]

Jud: there have been other cases of this bug seen too. Has anything changed
related to the TraceMsg behaviour? I suspect NSPR changes may have somthing to
do with it. If you believe the same reassign it to Wan-Teh.

Comment 2

[raman]

I have checked in the bug fix to TRACEMSG. It checks for null address.

thanks much,
raman

Comment 3

[glynn]

qa contact set to [e-mail] for verify against current build of
Seamonkey

Comment 4

[Claudius Gayle]

Raman, can you send me or outline here a test case/scenario so that I can verify this fix?

Comment 5

[Claudius Gayle]

Marking bug as VERIFIED. The bug is old codebase so there isn't much to be done. I will test with Seamonkey when the 'open link
in new window' feature is supported.