Closed Bug 242334 Opened 20 years ago Closed 20 years ago

Crash navigating to site http://mall.liberamente.net

Categories

(SeaMonkey :: General, defect)

x86
Windows XP
defect
Not set
critical

Tracking

(Not tracked)

VERIFIED DUPLICATE of bug 236313

People

(Reporter: jaymasta, Unassigned)

References

()

Details

(Keywords: crash, testcase)

Attachments

(1 file, 1 obsolete file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; it-IT; rv:1.6) Gecko/20040206 Firefox/0.8
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; it-IT; rv:1.6) Gecko/20040206 Firefox/0.8

Crash navigating to site http://mall.liberamente.net getting "Runtime Error
R6025 - Pure virtual function call" with both Mozilla and Firefox

Reproducible: Always
Steps to Reproduce:
1. go to http://mall.liberamente.net
2. click on one of the categories
3. wait to load the entire page, you get soon the error without doing anything.

Actual Results:  
The browser crash and you need to start it again.

Expected Results:  
the browser ;-)


Visual C++ Runtim Library
can you reproduce crash with Mozilla 1.7RC ? If so, please post Talkback ID for
this crash.
Severity: normal → critical
Keywords: crash, stackwanted
I can reproduce on Windows 2003 with
Mozilla 1.7rc1
Firefox 20040501 trunk

This crashes 100% on reloading the page

Unfortunately, when you have "runtime error ..." talkback doesn't appear
I've tried several times and once I had an access violation instead of a
"runtime error":

(no talkback because I was using homebuild firefox)

Crash in function:

nsCOMPtr<nsIDOMCSSPrimitiveValue>::nsCOMPtr<nsIDOMCSSPrimitiveValue>

Code around the crash:

      nsCOMPtr( T* aRawPtr )
            : NSCAP_CTOR_BASE(aRawPtr)
          // construct from a raw pointer (of the right type)
        {
0067C3C0  mov         eax,dword ptr [esp+4] 
          if ( mRawPtr )
0067C3C4  test        eax,eax 
0067C3C6  push        esi  
0067C3C7  mov         esi,ecx 
0067C3C9  mov         dword ptr [esi],eax 
0067C3CB  je         
nsCOMPtr<nsIDOMCSSPrimitiveValue>::nsCOMPtr<nsIDOMCSSPrimitiveValue>+13h (67C3D3h) 
            NSCAP_ADDREF(this, mRawPtr);
0067C3CD  mov         ecx,dword ptr [eax] 
0067C3CF  push        eax  
0067C3D0  call        dword ptr [ecx+4]         <===== CRASH HERE
          NSCAP_LOG_ASSIGNMENT(this, aRawPtr);
          NSCAP_ASSERT_NO_QUERY_NEEDED();
        }
0067C3D3  mov         eax,esi 
0067C3D5  pop         esi  
0067C3D6  ret         4 

Registers:

EAX = 023B1ABC EBX = 00000002 ECX = 0000021A 
EDX = 00000000 ESI = 0012FCA4 EDI = 00000000 
EIP = 0067C3D0 ESP = 0012FC90 EBP = 0012FCA8 
EFL = 00210202 

0000021E = ???????? 
Status: UNCONFIRMED → NEW
Ever confirmed: true
"this" seems to be NULL:

+	this	0x00000000	nsCOMPtr<nsIDOMCSSPrimitiveValue> * const
+	aRawPtr	0x023b1abc	nsIDOMCSSPrimitiveValue *
I produced this crashing testcase by reducing the file header.htm, not sure if
it's related to stack in comment 2, however, Firefox kept on crashing with the
same Virtual Call error dialog for me (FF 20040430 on Win2k).
I can confirm that I've got the same stack (see comment 2) with the testcase
Asking blocking 1.7 because it occurs on 1.7rc1 too
Flags: blocking1.7?
Keywords: testcase
Attached file testcase more reduced
changing image source doesn't to work (can't see the animated gif)
changing the gif source to 'http://mozilla.org/images/mlogo.gif' doesn't crash
so this is because of the animated gif
Attachment #147492 - Attachment is obsolete: true
finally got a talkback id with 1.7rc1: 
TB36158M
Keywords: stackwanted
Stacktrace:

nsCOMPtr<imgIDecoderObserver>::nsCOMPtr<imgIDecoderObserver>(imgIDecoderObserver
* 0x030b79e8) line 553 + 13 bytes
imgRequestProxy::FrameChanged(imgIContainer * 0x030b4718, gfxIImageFrame *
0x02cdf5b0, nsRect * 0x0012fcec) line 361
imgRequest::FrameChanged(imgRequest * const 0x030bce94, imgIContainer *
0x030b4718, gfxIImageFrame * 0x02cdf5b0, nsRect * 0x0012fcec) line 360
imgContainerGIF::Notify(imgContainerGIF * const 0x030b471c, nsITimer *
0x02c474a8) line 456
nsTimerImpl::Fire() line 391
handleTimerEvent(TimerEventType * 0x02afd500) line 454
PL_HandleEvent(PLEvent * 0x02afd500) line 692 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x00f882a0) line 627 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x0007032a, unsigned int 49496, unsigned int 0,
long 16286368) line 1433 + 9 bytes
USER32! 77d13a50()
USER32! 77d13b1f()
USER32! 77d13d79()
USER32! 77d14374()
CWinThread::Run() line 487 + 11 bytes
CWinApp::Run() line 400
AfxWinMain(HINSTANCE__ * 0x00400000, HINSTANCE__ * 0x00000000, char *
0x00142388, int 10) line 49 + 11 bytes
WinMain(HINSTANCE__ * 0x00400000, HINSTANCE__ * 0x00000000, char * 0x00142388,
int 10) line 30
WinMainCRTStartup() line 330 + 54 bytes
KERNEL32! 77e614c7()
the stack looks like bug 236313
yes this is a dupe. testcases are the same in both bugs.

*** This bug has been marked as a duplicate of 236313 ***
Status: NEW → RESOLVED
Closed: 20 years ago
Flags: blocking1.7?
Resolution: --- → DUPLICATE
verified firefox trunk 20040512
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: