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)
Tracking
()
VERIFIED
WORKSFORME
M13
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
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.
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.
Updated•25 years ago
|
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
Updated•25 years ago
|
Target Milestone: M12 → M13
Comment 4•25 years ago
|
||
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?
You need to log in
before you can comment on or make changes to this bug.
Description
•