Closed Bug 465623 Opened 16 years ago Closed 15 years ago

After popups were displayed shifted Firefox crashed while clicking on several main menu items [@ libobjc.A.dylib@0x15688][@ imgRequestProxy::OnStopFrame]

Categories

(Core :: Graphics: ImageLib, defect)

Product:
Core
Component:
Graphics: ImageLib
Version:
1.9.0 Branch
Platform:
All
macOS
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED FIXED
Milestone:
Future

People

(Reporter: whimboo, Unassigned)

References

Details

(Keywords: crash, Whiteboard: [fixed by bug 499600])

Crash Data

Attachments

(3 files)

Popups are opened at a shifted position
(deleted), image/png
Details
stack
(deleted), text/plain
Details
UI inspector application
(deleted), application/force-download
Details 
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.5pre) Gecko/2008111104 GranParadiso/3.0.5pre ID:2008111104

After some browsing Firefox surprisingly opened pop-ups at a totally different position as where I clicked. In the attachment you can see that for a dropdown box. But it also happens for context menus, autocomplete boxes and all other types of pop-ups. After randomly clicking inside the main menu bar Firefox crashed with the following stack. I don't have STR right now. It was a one time crash.

bp-561df68b-2e0f-4c75-910d-05f220081118

0  	libobjc.A.dylib  	libobjc.A.dylib@0x15688  	
1 	XUL 	imgRequestProxy::OnStopFrame 	mozilla/modules/libpr0n/src/imgRequestProxy.cpp:452
2 	XUL 	imgRequest::OnStopFrame 	mozilla/modules/libpr0n/src/imgRequest.cpp:527
3 	XUL 	nsPNGDecoder::EndImageFrame 	mozilla/modules/libpr0n/decoders/png/nsPNGDecoder.cpp:198
4 	XUL 	end_callback 	mozilla/modules/libpr0n/decoders/png/nsPNGDecoder.cpp:852
5 	XUL 	MOZ_PNG_push_read_chunk 	mozilla/modules/libimg/png/pngpread.c:344
6 	XUL 	MOZ_PNG_process_data 	mozilla/modules/libimg/png/pngpread.c:36
7 	XUL 	ReadDataOut 	mozilla/modules/libpr0n/decoders/png/nsPNGDecoder.cpp:335
8 	XUL 	nsInputStreamTee::WriteSegmentFun 	mozilla/xpcom/io/nsInputStreamTee.cpp:102
9 	XUL 	nsPipeInputStream::ReadSegments 	mozilla/xpcom/io/nsPipe3.cpp:799
10 	XUL 	nsPNGDecoder::WriteFrom 	mozilla/modules/libpr0n/decoders/png/nsPNGDecoder.cpp:365
11 	XUL 	imgRequest::OnDataAvailable 	mozilla/modules/libpr0n/src/imgRequest.cpp:876
12 	XUL 	nsStreamListenerTee::OnDataAvailable 	mozilla/netwerk/base/src/nsStreamListenerTee.cpp:97
13 	XUL 	nsHttpChannel::OnDataAvailable 	mozilla/netwerk/protocol/http/src/nsHttpChannel.cpp:4528
14 	XUL 	nsInputStreamPump::OnStateTransfer 	mozilla/netwerk/base/src/nsInputStreamPump.cpp:508
15 	XUL 	nsInputStreamPump::OnInputStreamReady 	mozilla/netwerk/base/src/nsInputStreamPump.cpp:398
16 	XUL 	nsInputStreamReadyEvent::Run 	mozilla/gfx/cairo/libpixman/src/pixman-access-accessors.c:107
17 	XUL 	nsThread::ProcessNextEvent 	mozilla/xpcom/threads/nsThread.cpp:510
18 	XUL 	NS_ProcessPendingEvents_P 	nsThreadUtils.cpp:180
19 	XUL 	nsBaseAppShell::NativeEventCallback 	mozilla/widget/src/xpwidgets/nsBaseAppShell.cpp:121
20 	XUL 	nsAppShell::ProcessGeckoEvents 	mozilla/widget/src/cocoa/nsAppShell.mm:302
There are a 161 crash reports listed on Soccorro for Firefox 3.0.4 within the last week. Two of them have a comment: 

"tried to close a tab using cmd-w keystroke (3rd crash today)"

"I was opening a recently closed from history"

List for fx3.0.4: http://tinyurl.com/6lqzaq
List for 1.9.1:   http://tinyurl.com/5oxby2
This crash probably happened in nsMenuItemIconX::OnStopFrame(), in
widget/src/cocoa/nsMenuItemIconX.mm.

Wild guess -- related to bug 465522?
Steven, I wasn't able to reproduce this issue and I'm even not sure if the crash is related to the shifted pop-ups.
Ok, I'm seeing the same issue again. Popups are shifted after working in Gmail. I didn't do anything special. Just deleted and tagged some messages. Still no idea, why that happens. I tried to get Firefox to crash, but I'm not able to. So probably we have two different kinds of bugs here. Should I separate the shifted display issue as a new bug?
> Should I separate the shifted display issue as a new bug?

Not until you can reproduce it :-)
Ok, I can see the problem again. All pop-ups are shifted approximately 200/100 px to the right/bottom. It starts happening while starting VmWare and trying to scroll within a tab where gmail was open. Restoring the state of Windows XP completely locks my MacBook for around 1 minute. During this time no events are processed. Means, using the mouse wheel doesn't result in any scrolling. Even the scrollbars don't react. After the state of Windows XP was restored, I switched back to Shiretoko and tried to copy an url from an open thread. Now while doing a right click the context menu and all other pop-ups too were shifted by the amount of pixels. This wired behavior stopped after creating a new tab. I'll try to reproduce.
Needless to say, make sure you're using the most recent version of VMWare Fusion :-)

Bug 439700 was (apparently) "fixed" by upgrading VMWare Fusion.
Ok, that's definitely happen due to VmWare. I'm running Version 1.1.3 (94249). I don't wanna upgrade to 2.0.x due to performance reasons I have on this MacBook. I tried once and it was extremely slow by accessing the file system.

But why we forget about the mouse position when the event queue is stopped for a while? This bug is in the OS X version of Firefox and not the one running within VmWare.
Henrik, bug 477475 may provide a way to reliably reproduce this crash (by installing something called KeyCue).
I've installed this software but sadly I'm not able to reproduce it. Will have to wait for a response from the reporter. Shall we dupe bug 477475 immediately?
> Shall we dupe bug 477475 immediately?

Let's hold off until one of us can reproduce bug 477475 reliably.
Same happens to me today while testing FF3.0.7. I was hitting the homepage button in the toolbar when Firefox crashed. No chance so far to reproduce.

crash report: bp-557ddd72-c289-47d8-b183-8ade52090220
I hit this same crash while trying to click in the menu running the latest 1.9.1 nightly on 10.6. http://crash-stats.mozilla.com/report/index/cb6ceca6-0397-4fe2-97e3-cb1a32090310
Marcia, is your crash reproducible?

And if so, does either of the tryserver builds at bug 477475 fix it?
(Bug 477475 comment #21 and bug 477475 comment #30)
Steven: I will try again. It was interesting that it happened after I woke the machine from sleep and then went to do an operation in the file menu. Will report back.

(In reply to comment #14)
> Marcia, is your crash reproducible?
> 
> And if so, does either of the tryserver builds at bug 477475 fix it?
> (Bug 477475 comment #21 and bug 477475 comment #30)
I was able to crash twice in a row this morning running the Firefox 3.1 Beta 3 candidate.  In both instances I was clicking rapidly in the menu area (First on the Help menu item) then rapidly switching focus to another menu item. I could not repro a third time.  Next I can try the tryserver builds, but it doesn't seem that is bug is 100% reproducible yet.  I am wondering if something happens when I trigger the opening of the Help Menu and then before it is closed make a rapid switch to another item...
I finally seem to have a reproducible set of steps for this book. This happens every time for me following these STR:

1. With Firefox still running (Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1b3) Gecko/20090305 Firefox/3.1b3), go the Apple menu and choose "Sleep." Leave the machine running overnight (not sure if this is necessary, this is just the scenario I see every day)
2. Wake the machine from sleep using the space bar.
3. Immediately go to the Help menu to check for updates using the mouse.
4. As soon as I touch the Help menu with the mouse Firefox crashes.
This info was in the console:

3/16/09 10:29:41 AM	firefox-bin[13840]	-[_NSViewAuxiliary setImage:]: unrecognized selector sent to instance 0x17baa910
3/16/09 10:29:41 AM	firefox-bin[13840]	Mozilla has caught an Obj-C exception [NSInvalidArgumentException: -[_NSViewAuxiliary setImage:]: unrecognized selector sent to instance 0x17baa910]
3/16/09 10:29:41 AM	[0x0-0x2a02a].org.mozilla.firefox	2009-03-16 10:29:41.567 firefox-bin[13840:903] -[_NSViewAuxiliary setImage:]: unrecognized selector sent to instance 0x17baa910
3/16/09 10:29:41 AM	[0x0-0x2a02a].org.mozilla.firefox	2009-03-16 10:29:41.569 firefox-bin[13840:903] Mozilla has caught an Obj-C exception [NSInvalidArgumentException: -[_NSViewAuxiliary setImage:]: unrecognized selector sent to instance 0x17baa910]
Marcia, from your console info I see that my patch from bug 477475
comment #21 will fix your crash.

Josh's patch from bug 477475 comment #30 might also.  But I suspect
that bug (and this one) will only be truly fixed by combining my patch
with Josh's.

Please test, if you can.

It'd be *really* helpful to find a lower amount of time to make one's
laptop sleep than "overnight" :-)
I tried putting the machine to sleep and waking it immediately, but I was not able to generate the crash this way yet following the same STR from Comment 17. Will test both tryserver builds and report back.
I haven't had any luck reproducing this bug with Steven's tryserver build, but after switching to a new mouse I can easily reproduce it on this machine rather easily without having to put the machine to sleep. During a browsing session, I crashed, and right after I crashed I selected "Restore Session" and then while the tabs are reloading I clicked like mad on the help menu and I crashed. I was able to do it 4 times in row rather easily.
> but after switching to a new mouse I can easily reproduce it on this
> machine rather easily without having to put the machine to sleep.

Is this using my tryserver build, or just a regular build?
This was using a regular build. I just hit this crash a few moments ago using Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1b4pre) Gecko/20090420 Shiretoko/3.5b4pre.

(In reply to comment #22)
> > but after switching to a new mouse I can easily reproduce it on this
> > machine rather easily without having to put the machine to sleep.
> 
> Is this using my tryserver build, or just a regular build?
Using the new seed of 10.6 just installed in the lab, I am still hitting this crash just about every day when using the latest trunk and 1.9.1 nightlies. In most cases I crash when I wake the machine and update both trunk and branch, but I noticed sometimes if I select a menu item and hold the mouse down I crash as well.
Steven, in bug 499600 we have the best STR to reproduce the crash constantly. Thanks Brian!

Due to we have a KERN_INVALID_ADDRESS memory access lets put this bug into the security group until we know what's going on. I'll attach a gdb stack.
Group: core-security
Hardware: x86 → All
Attached file stack (deleted) — 

    
    

    
  

      
      
      
      

        Attached file
          
        UI inspector application (deleted)
        — 
      

    


  
Just to summarize the steps:

1. Run the attached UI elements inspector
2. Start Firefox
3. Hover over the history menu (don't click)
4. Switch back to the UI inspector and press Cmd+F7 to lock the inspected element
5. Click on History

The crash will occur in step 5 or already in step 4.

    
    

    
  
Wonderful!!

With the STR from comment #28 (and from bug 499600), I can now
reproduce this crash 100% of the time on trunk (mozilla-central), the
1.9.1 branch and the 1.9.0 branch.

My patch for bug 477475 fixes the crash ... which doesn't surprise me
in the least.

But Josh doesn't like my patch.  So, since we have the source code for
the app that triggers the crash (UIElementInspector), I'm going to try
to figure out exactly how it does the triggering, and see what I learn
along the way.

    
    

    
  
I've got a patch (and tryserver build) at bug 499600 comment #9 that should fix this bug.

    
    

    
  
More info from the Apple console right before I crash in this stack - the Get Event Parameter wasn't noted in the last time I viewed the Console (Comment 18). I can try the Tryserver Build but without I do crash rather consistently on 10.6 whenver I touch the Help menu item.

7/2/09 11:37:26 AM	firefox-bin[356]	GetEventParameter(kEventParamWindowRef) failed: -9870
7/2/09 11:39:19 AM	firefox-bin[315]	-[__NSCFType setImage:]: unrecognized selector sent to instance 0x2ccfb320
7/2/09 11:39:19 AM	[0x0-0x2d02d].org.mozilla.firefox	2009-07-02 11:39:19.359 firefox-bin[315:903] -[__NSCFType setImage:]: unrecognized selector sent to instance 0x2ccfb320
7/2/09 11:39:19 AM	firefox-bin[315]	Mozilla has caught an Obj-C exception [NSInvalidArgumentException: -[__NSCFType setImage:]: unrecognized selector sent to instance 0x2ccfb320]
7/2/09 11:39:19 AM	[0x0-0x2d02d].org.mozilla.firefox	2009-07-02 11:39:19.376 firefox-bin[315:903] Mozilla has caught an Obj-C exception [NSInvalidArgumentException: -[__NSCFType setImage:]: unrecognized selector sent to instance 0x2ccfb320]
7/2/09 11:39:19 AM	firefox-bin[315]	Invalid memory access of location 77696e84 eip=91028987
7/2/09 11:39:19 AM	[0x0-0x2d02d].org.mozilla.firefox	2009-07-02 11:39:19.394 firefox-bin[315:9a03] Invalid memory access of location 77696e84 eip=91028987

    
    

    
  
The crash should have been fixed by bug 499600. The popup issue I haven't seen for a longer time. So lets forget about it. Marking as fixed.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Whiteboard: [fixed by bug 499600]
Target Milestone: --- → Future
Crash Signature: [@ libobjc.A.dylib@0x15688]
[@ imgRequestProxy::OnStopFrame]

    
  
Group: core-security → core-security-release
Group: core-security-release

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: