Closed Bug 12089 Opened 25 years ago Closed 25 years ago

[MLK]Application exception occurred after a long (stress) use.

Categories

(Core :: DOM: Editor, defect, P3)

x86
Windows NT
defect

Tracking

()

VERIFIED WORKSFORME

People

(Reporter: peters, Assigned: buster)

References

()

Details

This is what happens after a constant "Editor"typing.  I'd say this qualifies
for a stress test because the app was forced to type for a while really fast and
constantly through a certain test automation test case.

Application exception occurred:
        App: apprunner.dbg (pid=272)
        When: 8/18/1999 @ 11:28:20.775
        Exception number: c0000005 (access violation)

function: nsIFrame::GetLogModuleInfo
        604c177f 59               pop     ecx
        604c1780 8b4638           mov     eax,[esi+0x38]
ds:040572e6=007701b3
        604c1783 8b4de4           mov     ecx,[ebp-0x1c]
ss:0113e496=????????
        604c1786 03c1             add     eax,ecx
        604c1788 8b4d18           mov     ecx,[ebp+0x18]
ss:0113e496=????????
        604c178b 33ff             xor     edi,edi
        604c178d 8901             mov     [ecx],eax
ds:0012fac4=00001cfe
        604c178f 8b563c           mov     edx,[esi+0x3c]
ds:040572e6=007701b3
        604c1792 85d2             test    edx,edx
        604c1794 7c15             jl     nsIFrame::GetLogModuleInfo+0x59ab
(604c17ab)
FAULT ->604c1796 3903             cmp     [ebx],eax
ds:03843000=????????
        604c1798 740a             jz     nsIFrame::GetLogModuleInfo+0x59a4
(604c17a4)
        604c179a 47               inc     edi
        604c179b 83c304           add     ebx,0x4
        604c179e 3bfa             cmp     edi,edx
        604c17a0 7ef4             jle    nsIFrame::GetLogModuleInfo+0x5996
(604c1796)
        604c17a2 eb07             jmp    nsIFrame::GetLogModuleInfo+0x59ab
(604c17ab)
        604c17a4 8b4638           mov     eax,[esi+0x38]
ds:040572e6=007701b3
        604c17a7 03c7             add     eax,edi
        604c17a9 8901             mov     [ecx],eax
ds:0012fac4=00001cfe
        604c17ab 8b01             mov     eax,[ecx]
ds:0012fac4=00001cfe
        604c17ad 8b4d1c           mov     ecx,[ebp+0x1c]
ss:0113e496=????????
FramePtr ReturnAd Param#1  Param#2  Param#3  Param#4  Function Name
0012fa90 604bc97a 0386e7f0 048bea20 00000159 0012facc
raptorhtml!nsIFrame::GetLogModuleInfo
0012fad0 604bc8d3 030488e0 02fbf560 0012fd08 0012fcc8
raptorhtml!nsIFrame::GetLogModuleInfo
0012fafc 604c4ea7 030488e0 02fc1200 0012fd08 0012fcc8
raptorhtml!nsIFrame::GetLogModuleInfo
0012fb38 60a21d16 00000000 0247d640 0012fd08 0012fcc8 raptorhtml!NS_NewPresShell
0012fb7c 60a21cdb 00000000 0012fd08 00000008 0012fcc8 raptorview!<nosymbols>
0012fbc4 60a21cdb 00000000 0247d640 00000008 0012fcc8 raptorview!<nosymbols>
0012fc0c 60a21cdb 00000003 0244e360 00000008 0012fcc8 raptorview!<nosymbols>
0012fc54 60a26391 00000000 0244e3d0 0000001c 0012fcc8 raptorview!<nosymbols>
0012fcb0 60a223ec 00002751 00000048 0012fcc8 0012fcf8 raptorview!<nosymbols>
0012fccc 60a44985 02f8f3a0 00000000 02418870 60a449cb raptorview!<nosymbols>
0012fcdc 60a449cb 02418874 0012fd08 0012fcf8 0012fd60 raptorwidget!<nosymbols>
(FPO: [3,0,2])
0012fcf0 60a4701e 00000000 00000000 02418870 00000000 raptorwidget!<nosymbols>
0012fd60 60a47320 0000012e 00000000 02418870 60a468c1 raptorwidget!<nosymbols>
0012fd70 60a468c1 0000012e 00000000 77e71bf1 02418870 raptorwidget!<nosymbols>
(FPO: [2,0,1])
0012fdfc 60a44a7b 00000201 00000001 0048029f 0012fe38 raptorwidget!<nosymbols>
0012fe24 77e71820 004a044a 00000201 00000001 00000000 raptorwidget!<nosymbols>
0012fe74 0048029f 27a6fee9 000002ed 000000fd 0012ff38 user32!TranslateMessageEx
Status: NEW → ASSIGNED
Well, we know we have some fairly substantial memory leaks in certain parts of
the system, so depending on what exactly your tests did, it's possible that it's
a low-memory error, something isn't properly handling a failed allocation
perhaps.

Is there any chance you could send us your test procedure, or better yet your
test harness?  Without a reproducable case, it'll be hard to ever declare that
we've fixed this bug, since I expect it to be fixed indirectly as a result of
fixing memory leaks and allocation bugs.

The crash actually occurs in layout, not in the editor itself, so I'm cc'ing
rickg.
Target Milestone: M12
until system memory leaks are cleaned up, I doubt we can make much progress on
this bug without a reproducable test case or a stack trace of the crash.  So,
deferring to M12, during which memory cleanup should be complete.
Summary: Application exception occurred after a long (stress) use. → [MLK]Application exception occurred after a long (stress) use.
Peter S:  since this bug has been submitted, our memory leak situation has
gotten much better.  Can you retest, and verify that you no longer get the
crash?  Or, better yet, could you provide us with your test script (actual
script files, or just a description of the precise steps to reproduce)?

If we don't hear back from you in a while, I'll just have to mark this bug
"worksforme" until we get more data.
Whiteboard: possibly worksforme, waiting for data from submitter
Target Milestone: M12 → M13
moving to m13, I sent a note to the reporter asking for input.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → WORKSFORME
Whiteboard: possibly worksforme, waiting for data from submitter
haven't heard anything back from the reporter, so I'm marking this WORKSFORME.
Please reopen this bug or file a new bug if any crashes are encountered.  To
verify, QA will just have to use the browser for an extended period and see if
any crashes are encountered.  Do we have any automation tools to make this
reproducable?
Status: RESOLVED → VERIFIED
verified in 12/15 build.
You need to log in before you can comment on or make changes to this bug.