951 - ASSERT while freeing memory in HT_DeleteCursor

Status: VERIFIED WONTFIX

(SeaMonkey :: General, defect, P3)

Description

[Bryce Harrington]

My system was swapping pretty heavily because I was cutting and pasting
large images between applications (a 23MB image in a word document).
Had a bunch of software loaded, too.  While waiting for swapping to
finish, I switched over to Mozilla to read slashdot.  Mozilla started
having trouble.

Debug messages:
---------------
Created rdf:ht5
Remembering document position at element id 72
www.netlib.org error=0 h_name=1 task=18
Remembering document position at element id 35
Updating location bar for named anchor
banner.surfree.com error=0 h_name=1 task=19
memory check error at 0x00D30D44 = 0x70, should be 0xFD.
memory check error at 0x00D30D45 = 0x0D, should be 0xFD.
memory check error at 0x00D30D46 = 0xD3, should be 0xFD.
memory check error at 0x00D30D47 = 0x00, should be 0xFD.


Call stack:
-----------
1.  _free_dbg_lk(void * 0x00d30d90, int 0x00000001) line 1033 + 63 bytes
2.  _free_dbg(void * 0x00d30d90, int 0x00000001) line 970 + 13 bytes
3.  free(void * 0x00d30d90) line 926 + 11 bytes
4.  PR_Free(void * 0x00d30d90) line 66 + 10 bytes
5.  HT_DeleteCursor(_HT_CursorStruct * 0x00d30d90) line 3251 + 9 bytes
6.  CRDFToolbar::WidthChanged(int 0x00000024) line 2130 + 9 bytes
7.  CDragToolbar::ArrangeToolbar(int 0xffffffdc, int 0x0000002e) line 725
8.  CDragToolbar::OnSize(unsigned int 0x00000000, int 0x00000000, int
0x0000002e) line 432
9.  CWnd::OnWndMsg(unsigned int 0x00000005, unsigned int 0x00000000, long
0x002e0000, long * 0x0012e160) line 1763


Cause:
------
This appears to be a bug in Microsoft code, since the last four function
calls were inside Windows/MFC.  The place in the Mozilla code where this
bug would need to be isolated is in ht.c, line 3244:

PR_PUBLIC_API(HT_Error)
HT_DeleteCursor (HT_Cursor cursor)
{
	XP_ASSERT(cursor != NULL);

	if (cursor != NULL)
	{
/* >> */	freeMem(cursor);
	}
	return(HT_NoErr);
}

Here is the code at the tail end, where the stoppage occurred:

Line 1035 of msdev/crt/src/dbgheap.c...

        /* if we didn't already check entire heap, at least check this object */
        if (!(_crtDbgFlag & _CRTDBG_CHECK_ALWAYS_DF))
        {
            /* check no-mans-land gaps */
            if (!CheckBytes(pHead->gap, _bNoMansLandFill, nNoMansLandSize))
                _RPT3(_CRT_ERROR, "DAMAGE: before %hs block (#%d) at 0x%08X.\n",
                    szBlockUseName[_BLOCK_TYPE(pHead->nBlockUse)],
                    pHead->lRequest,
                    (BYTE *) pbData(pHead));

/* >> */    if (!CheckBytes(pbData(pHead) + pHead->nDataSize, _bNoMansLandFill,
nNoMansLandSize))
                _RPT3(_CRT_ERROR, "DAMAGE: after %hs block (#%d) at 0x%08X.\n",
                    szBlockUseName[_BLOCK_TYPE(pHead->nBlockUse)],
                    pHead->lRequest,
                    (BYTE *) pbData(pHead));
        }


I don't know what CheckBytes does, but apparently it didn't pass the second
call.
Here's the values of the variables for this call:

pHead = 0x00d30d70
pHead->nDataSize = 0xffffffb4
_bNoMansLandFill = 0xfd
nNoMansLandFill = ??  Couldn't tell.


Is it possible that another application (Word, perhaps) tinkered with Mozilla's
memory?


System:
-------
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.

Comment 1

[Garrett Arch Blythe]

Handing over to HT people.

Comment 2

[leger]

Setting all current Open/Normal to M4.

Comment 3

[Robert John Churchill]

Old code base, not applicable in new code base. Marking as WONTFIX.

Comment 4

[leger]

Old bug...go get the latest mozilla source code!  www.mozilla.org

Marking Verified/Won't Fix