This bug was filed from the Socorro interface and is report bp-963050e5-6bb3-45ab-9fef-a12c42151023, bp-1bd3040e-6c88-478b-9340-ae88b2151024, and bp-f4443b46-dde8-47ee-9df2-f7d5f2151020. ============================================================= I saw bug 1198594, but according to the description there, that bug seems to be introduced since Firefox 42, but I met this crash in Firefox 41.0.2, so probably they are not the same. Also that bug is about crash happens directly in our code, but this crash seems to happen in the graphics driver. It is highly possible that this crash is related to Flash. This is the third time it happens after I watched a video in a flash player.

My Flash Player version is 19.0.0.226, and graphics card is NVIDIA GeForce GT 750M on a 15-inch Late-2013 MacBook Pro.

Is there a particular website or video where this occurs frequently? How frequently does it occur? What are you doing on the website prior to the crash occurring? Do you notice any other symptoms (eg. slow downs, visual glitches, playback issues, etc) before the crash occurs?

Also, did you recently update Flash? If so it would be helpful if you could test earlier versions of Flash to see if the bug happens in older versions. If it still happens on older versions that rules this out as a bug in the latest Flash update.

This happens pretty frequently: 4 times in the last 7 days, after doing the same thing, which seems to be pretty reproducible. My steps are: 1. watched a video with proxy 2. close the tab 3. do something 4. watch another video in the same website with proxy 5. close the tab then it crashes. I cannot provide the exact steps, because that website is not accessible outside China (and that's why I use proxy). Sorry about that. It is currently the top 3 crash on OS X, so you can see some compliants in the crash stats. I saw some people met this on Youtube.

Does this happen for any websites without a proxy?

(In reply to Xidorn Quan [:xidorn] (UTC+9) from comment #4) > It is currently the top 3 crash on OS X, so you can see some compliants in > the crash stats. The rank is probably more to do with this signature being generic and likely masking several different crashes. That's not to say that this isn't a serious issue, just that your specific issue is probably not the top-3 issue facing Mac OS X users. > I saw some people met this on Youtube. Unfortunately that's a fairly common occurrence in *most* of our crashes and is not necessarily an indicator of where the failure occurred. That said it's still worth looking in to.

Adding the stack since it's telling of the specific issue described in this bug. Other reports show different stacks so we're probably looking at a confluence of issues under the same generic stack. ============================================================== Ø 0 libsystem_kernel.dylib libsystem_kernel.dylib@0x16286 Ø 1 libsystem_c.dylib libsystem_c.dylib@0x5d9b2 Ø 2 libGPUSupportMercury.dylib libGPUSupportMercury.dylib@0x1b80 Ø 3 GeForceGLDriver GeForceGLDriver@0x227289 Ø 4 libGPUSupportMercury.dylib libGPUSupportMercury.dylib@0x2f1a Ø 5 GeForceGLDriver GeForceGLDriver@0x31a49a Ø 6 GeForceGLDriver GeForceGLDriver@0x2ea5ed Ø 7 GeForceGLDriver GeForceGLDriver@0x514127 Ø 8 GeForceGLDriver GeForceGLDriver@0x514350 Ø 9 GeForceGLDriver GeForceGLDriver@0x514a47 Ø 10 GeForceGLDriver GeForceGLDriver@0x2d0193 Ø 11 GeForceGLDriver GeForceGLDriver@0x2d0bdb Ø 12 GeForceGLDriver GeForceGLDriver@0x33bc41 Ø 13 GLEngine GLEngine@0x1baed Ø 14 libGL.dylib libGL.dylib@0x359d 15 XUL mozilla::gl::TexSubImage2DHelper gfx/gl/GLContext.h 16 XUL mozilla::gl::UploadImageDataToTexture(mozilla::gl::GLContext*, unsigned char*, int, mozilla::gfx::SurfaceFormat, nsIntRegion const&, unsigned int&, bool, bool, unsigned int, unsigned int) gfx/gl/GLUploadHelpers.cpp 17 XUL mozilla::gl::BasicTextureImage::DirectUpdate(mozilla::gfx::DataSourceSurface*, nsIntRegion const&, mozilla::gfx::IntPointTyped<mozilla::gfx::UnknownUnits> const&) gfx/gl/GLUploadHelpers.cpp 18 XUL mozilla::gl::TextureImage::UpdateFromDataSource(mozilla::gfx::DataSourceSurface*, nsIntRegion const*, mozilla::gfx::IntPointTyped<mozilla::gfx::UnknownUnits> const*) gfx/gl/GLTextureImage.cpp 19 XUL mozilla::layers::TextureImageTextureSourceOGL::Update(mozilla::gfx::DataSourceSurface*, nsIntRegion*, mozilla::gfx::IntPointTyped<mozilla::gfx::UnknownUnits>*) gfx/layers/opengl/TextureHostOGL.cpp 20 XUL mozilla::layers::BufferTextureHost::Upload(nsIntRegion*) gfx/layers/composite/TextureHost.cpp 21 XUL mozilla::layers::BufferTextureHost::UpdatedInternal(nsIntRegion const*) gfx/layers/composite/TextureHost.cpp 22 XUL mozilla::layers::UseTileTexture(mozilla::layers::CompositableTextureRef<mozilla::layers::TextureHost>&, mozilla::layers::CompositableTextureRef<mozilla::layers::TextureSource>&, mozilla::gfx::IntRectTyped<mozilla::gfx::UnknownUnits> const&, mozilla::layers::TextureHost*, mozilla::layers::Compositor*) gfx/layers/composite/TextureHost.cpp 23 XUL mozilla::layers::TiledLayerBufferComposite::UseTiles(mozilla::layers::SurfaceDescriptorTiles const&, mozilla::layers::Compositor*, mozilla::layers::ISurfaceAllocator*) gfx/layers/composite/TiledContentHost.cpp 24 XUL _ZThn64_N7mozilla6layers16TiledContentHost19UseTiledLayerBufferEPNS0_17ISurfaceAllocatorERKNS0_22SurfaceDescriptorTilesE gfx/layers/composite/TiledContentHost.cpp 25 XUL mozilla::layers::CompositableParentManager::ReceiveCompositableUpdate(mozilla::layers::CompositableOperation const&, std::vector<mozilla::layers::EditReply, std::allocator<mozilla::layers::EditReply> >&) gfx/layers/ipc/CompositableTransactionParent.cpp 26 XUL mozilla::layers::LayerTransactionParent::RecvUpdate(nsTArray<mozilla::layers::Edit>&&, unsigned long long const&, mozilla::layers::TargetConfig const&, nsTArray<mozilla::layers::PluginWindowData>&&, bool const&, bool const&, unsigned int const&, bool const&, mozilla::TimeStamp const&, nsTArray<mozilla::layers::EditReply>*) gfx/layers/ipc/LayerTransactionParent.cpp 27 XUL mozilla::layers::LayerTransactionParent::RecvUpdateNoSwap(nsTArray<mozilla::layers::Edit>&&, unsigned long long const&, mozilla::layers::TargetConfig const&, nsTArray<mozilla::layers::PluginWindowData>&&, bool const&, bool const&, unsigned int const&, bool const&, mozilla::TimeStamp const&) gfx/layers/ipc/LayerTransactionParent.cpp 28 XUL mozilla::layers::PLayerTransactionParent::OnMessageReceived(IPC::Message const&) obj-firefox/x86_64/ipc/ipdl/PLayerTransactionParent.cpp 29 XUL mozilla::layers::PCompositorParent::OnMessageReceived(IPC::Message const&) obj-firefox/x86_64/ipc/ipdl/PCompositorParent.cpp 30 XUL mozilla::ipc::MessageChannel::DispatchAsyncMessage(IPC::Message const&) ipc/glue/MessageChannel.cpp 31 XUL mozilla::ipc::MessageChannel::DispatchMessage(IPC::Message const&) ipc/glue/MessageChannel.cpp 32 XUL mozilla::ipc::MessageChannel::OnMaybeDequeueOne() ipc/glue/MessageChannel.cpp 33 XUL MessageLoop::DeferOrRunPendingTask(MessageLoop::PendingTask const&) ipc/chromium/src/base/message_loop.cc 34 XUL MessageLoop::DoWork() ipc/chromium/src/base/message_loop.cc 35 XUL base::MessagePumpDefault::Run(base::MessagePump::Delegate*) ipc/chromium/src/base/message_pump_default.cc 36 XUL MessageLoop::Run() ipc/chromium/src/base/message_loop.cc 37 XUL base::Thread::ThreadMain() ipc/chromium/src/base/thread.cc 38 XUL ThreadFunc ipc/chromium/src/base/platform_thread_posix.cc Ø 39 libsystem_pthread.dylib libsystem_pthread.dylib@0x4059 Ø 40 libsystem_pthread.dylib libsystem_pthread.dylib@0x3fd6 Ø 41 libsystem_pthread.dylib libsystem_pthread.dylib@0x13ec 42 XUL XUL@0x2f685f ==============================================================

Markus, I'm not sure if you're the right person but could you have a look at this and direct it as needed?

Xidorn, any chance you can build and run a debug version and see if there is additional information we get from it?

I don't really think a debug version helps with this crash, since this crash seems to happen inside the driver code. But I can try doing it later. FWIW, every time this kind of crashes happen, I can find the following log in system.log: > Oct 26 23:42:57 upsuper-mbp2.local WindowServer[175]: Received display connect changed for display 0x4280642 > Oct 26 23:42:57 upsuper-mbp2.local WindowServer[175]: Found 27 modes for display 0x04280642 [27, 0] > Oct 26 23:42:57 upsuper-mbp2.local WindowServer[175]: CGXMuxAcknowledge: Posting glitchless acknowledge > Oct 26 23:42:57 upsuper-mbp2.local WindowServer[175]: MPAccessSurfaceForDisplayDevice: Set up page flip mode on display 0x04280642 device: 0x7f90e5103c80 isBackBuffered: 1 numComp: 3 numDisp: 3 > Oct 26 23:42:57 upsuper-mbp2.local WindowServer[175]: Received display connect changed for display 0x4280642 > Oct 26 23:42:57 upsuper-mbp2.local WindowServer[175]: Found 1 modes for display 0x04280642 [1, 0] > Oct 26 23:42:57 upsuper-mbp2.local WindowServer[175]: Received display connect changed for display 0x3f003f > Oct 26 23:42:57 upsuper-mbp2.local WindowServer[175]: Found 1 modes for display 0x003f003f [1, 0] > Oct 26 23:42:57 upsuper-mbp2.local WindowServer[175]: Received display connect changed for display 0x3f0040 > Oct 26 23:42:57 upsuper-mbp2.local WindowServer[175]: Found 1 modes for display 0x003f0040 [1, 0] > Oct 26 23:42:57 upsuper-mbp2.local WindowServer[175]: Received display connect changed for display 0x3f0041 > Oct 26 23:42:57 upsuper-mbp2.local WindowServer[175]: Found 1 modes for display 0x003f0041 [1, 0] > Oct 26 23:42:57 upsuper-mbp2 kernel[0]: NVDA: Command data buffer not resident! > Oct 26 23:42:57 upsuper-mbp2 kernel[0]: NVDA: Calling glrKillClient for task 0xffffff8024277450 > Oct 26 23:42:58 upsuper-mbp2.local CoreServicesUIAgent[467]: unexpected message <OS_xpc_error: <error: 0x7fff7db20c60> { count = 1, contents = > "XPCErrorDescription" => <string: 0x7fff7db20f70> { length = 18, contents = "Connection invalid" } > }> It talks about "display connect changed", but I want to state that I do not have any external monitor attached. I suspect it is about the graphics card switch. Also note that, the "WindowServer" messages above appear frequently in the log elsewhere without crash, which seems mostly related to plugin-container.

I guess the summary is wrong. This crash isn't really related to TexSubImage2DHelper. I just met another one with almost same actions which produces this report: bp-f0871d1e-f0b6-40a1-aa51-6bcce2151103

And I failed to reproduce this issue in my local nightly build...

I tried several times, but can never reproduce this issue with my local nightly build :(

Did not get fixed by a patch from bug 1219230

I observe a similiar crash when nothing special happens in Firefox. These crashes happens when I start playing Flash video in another Firefox instance: bp-d100f350-0401-487e-8855-ee0432160105, bp-fdcf14b8-f246-4304-85b9-68fc52160105 I remember there was a crash happens when I opened a Steam game, but I'm not sure which crash report that is. (I've met this crash over and over again, and accumulate a long crash report list...) So I guess it could either be 1) an operating system bug, or 2) Firefox doesn't check failure returned from system somewhere which eventually leads to crash.

Not claiming connection, but it may be worth looking at bug 1245552, in case this ends up being an OOM like thing.

Nightly is still crashing every other day for me with Crash Report [@ libsystem_kernel.dylib@0x17002 ] Usually when I go back to a youtube tab and hit the 'back one page' button.

I crashed in a row when scrolling quickly on this page: http://www.theverge.com/a/apple-watch-review

Just got this crash on my late-2013 15" rMBP, while looking at bug 1230641: 1. Plug external screen (I believe this forces the Mac to use the discrete Nvidia graphics card) 2. Start playing https://cdn.streamable.com/video/mp4/g5dv.mp4 on the laptop screen 3. During playback, unplug the external monitor (which would revert the Mac back to using the integrated Intel graphics) *boom*

(In reply to Gerald Squelart [:gerald] from comment #22) > Just got this crash on my late-2013 15" rMBP, while looking at bug 1230641: > 1. Plug external screen (I believe this forces the Mac to use the discrete > Nvidia graphics card) > 2. Start playing https://cdn.streamable.com/video/mp4/g5dv.mp4 on the laptop > screen > 3. During playback, unplug the external monitor (which would revert the Mac > back to using the integrated Intel graphics) > *boom* Switching graphics card sounds like a possible reason. For me, the crash sometimes happens when I'm using other programs (game or play video in another Firefox process), which could cause graphics card switch.

I originally ran into this crash on a new installation of m-c but managed to reproduce this on m-b as well. I'll try reproducing it using ./mach run --debug on the weekend and attach a stack trace or at least the piece of code that's crashing. Crashes: * bp-c3bdffd6-b346-4711-8ee8-84b872160318 (fx48.0a1, changeset: 3e04659fdf6a) * bp-1ade6438-213c-4358-b4b3-6d2822160318 (fx47.0a2, changeset: 5904e3eb711d) STR: * install a brand new instance of fx (reproduced with m-c and m-b) * in the tab that's already opened, paste http://www.newsbeast.gr/ in the URL and press "enter" to start loading the page * right after you start loading the above page, quickly click on the second tab that's already opened and type in about:support and press "enter" * if you do this fast enough, you'll manage to crash fx

Mason and I can reproduce this just by going to about:support, sometimes. It does seem to involve a graphics card switch, to, perhaps from discrete - it never happens when I'm always on discrete all the time (e.g., plugged into external monitor.)

My steps to reproduce: 1.) Make sure automatic graphics card switching is enabled. 2.) Go to http://www.motonet.fi/fi/haku?q=aurinkokenno 3.) Click one product 4.) Go back 5.) Repeat from step 3 until Firefox crashes Sometimes I can also see parts of another tab leak through to the product page.

Slightly different signature on our side: https://crash-stats.mozilla.com/report/index/b76e59bf-def0-42e1-8fd0-e456f2160503

This signature is specific to OS X 10.10. Once you move to OS X 10.11, you'll probably be getting @0x16f06, tracked in bug 1267288

Jeff & Jeff - anything you can think of that we can do to instrument things to get more data in the crash reports, or perhaps a special build we could send to the users that seem to be able to reproduce the problems?

Following the steps outlined in https://bugzilla.mozilla.org/show_bug.cgi?id=1261483#c15 are probably a good place to start on this.

This is a similar (same?) crash on Linux - Andrew is digging up the symbols.

Attached is a symbolicated stackwalk of possibly related Linux crash c25ebd80-846c-4e4d-9268-ec6e92160625- it might be of some use here.

(In reply to Jeff Muizelaar [:jrmuizel] from comment #30) > Following the steps outlined in > https://bugzilla.mozilla.org/show_bug.cgi?id=1261483#c15 are probably a good > place to start on this. that bug is restricted access.

It looks as if we have a series of 10.12 reports that have a similar stack: http://bit.ly/29tvn3y

This needs the rest of the steps from https://bugzilla.mozilla.org/show_bug.cgi?id=1261483#c15

Crash volume for signature 'libsystem_kernel.dylib@0x16286': - nightly (version 50): 2 crashes from 2016-06-06. - aurora (version 49): 8 crashes from 2016-06-07. - beta (version 48): 357 crashes from 2016-06-06. - release (version 47): 5610 crashes from 2016-05-31. - esr (version 45): 1248 crashes from 2016-04-07. Crash volume on the last weeks: Week N-1 Week N-2 Week N-3 Week N-4 Week N-5 Week N-6 Week N-7 - nightly 0 0 0 0 0 0 2 - aurora 1 0 2 2 0 2 0 - beta 44 76 68 51 41 43 12 - release 851 823 843 854 855 793 254 - esr 143 127 111 122 113 130 86 Affected platform: Mac OS X

Crash volume for signature 'libsystem_kernel.dylib@0x17002': - nightly (version 51): 0 crashes from 2016-08-01. - aurora (version 50): 1 crash from 2016-08-01. - beta (version 49): 0 crashes from 2016-08-02. - release (version 48): 118 crashes from 2016-07-25. - esr (version 45): 474 crashes from 2016-05-02. Crash volume on the last weeks (Week N is from 08-22 to 08-28): W. N-1 W. N-2 W. N-3 - nightly 0 0 0 - aurora 0 0 0 - beta 0 0 0 - release 21 35 23 - esr 32 29 45 Affected platform: Mac OS X Crash rank on the last 7 days: Browser Content Plugin - nightly - aurora #1407 - beta - release #542 - esr #309

Crash volume for signature 'libsystem_kernel.dylib@0x16286': - nightly (version 51): 0 crashes from 2016-08-01. - aurora (version 50): 1 crash from 2016-08-01. - beta (version 49): 11 crashes from 2016-08-02. - release (version 48): 690 crashes from 2016-07-25. - esr (version 45): 1616 crashes from 2016-05-02. Crash volume on the last weeks (Week N is from 08-22 to 08-28): W. N-1 W. N-2 W. N-3 - nightly 0 0 0 - aurora 0 1 0 - beta 0 2 2 - release 215 187 69 - esr 119 136 128 Affected platform: Mac OS X Crash rank on the last 7 days: Browser Content Plugin - nightly - aurora - beta #2028 - release #69 - esr #83

Crash volume for signature 'libsystem_kernel.dylib@0x16f06': - nightly (version 51): 5 crashes from 2016-08-01. - aurora (version 50): 2 crashes from 2016-08-01. - beta (version 49): 85 crashes from 2016-08-02. - release (version 48): 2374 crashes from 2016-07-25. - esr (version 45): 6081 crashes from 2016-05-02. Crash volume on the last weeks (Week N is from 08-22 to 08-28): W. N-1 W. N-2 W. N-3 - nightly 4 0 1 - aurora 0 1 0 - beta 26 21 4 - release 733 628 296 - esr 554 502 552 Affected platform: Mac OS X Crash rank on the last 7 days: Browser Content Plugin - nightly #753 - aurora #1406 - beta #358 - release #18 - esr #12

Crash volume for signature 'libsystem_kernel.dylib@0x17002': - nightly (version 52): 1 crash from 2016-09-19. - aurora (version 51): 0 crashes from 2016-09-19. - beta (version 50): 0 crashes from 2016-09-20. - release (version 49): 16 crashes from 2016-09-05. - esr (version 45): 480 crashes from 2016-06-01. Crash volume on the last weeks (Week N is from 10-03 to 10-09): W. N-1 W. N-2 - nightly 0 1 - aurora 0 0 - beta 0 0 - release 13 3 - esr 20 30 Affected platform: Mac OS X Crash rank on the last 7 days: Browser Content Plugin - nightly - aurora - beta - release #2335 - esr #431

This is no longer a topcrash as overall volume is down 80% from peak in September. > 53.*: 5 reports in the last week > 52.*: 6 reports in the last week > 51.*: 34 reports in the last week > 50.*: 296 reports in the last week

Too late for firefox 52, mass-wontfix.

Seems to be OS X 10.13 specific. Milan, any hope we could do something about that?

It's 10.13 because of the signatures we're collecting; it really is all versions of OS X and some Linux, if you look for the mozilla::gl::TexSubImage2DHelper crashes. For example: https://crash-stats.mozilla.com/report/index/a31ffdb8-b896-4b33-84b3-0cd150171017 (Linux) https://crash-stats.mozilla.com/report/index/65680160-a8e9-47a0-b250-a851e0171017 (OS X 10.10) https://crash-stats.mozilla.com/report/index/265374c9-ec39-45b3-b078-aefa40171016 (OS X 10.8) https://crash-stats.mozilla.com/report/index/fc552463-ea5f-4475-a6e5-baac80171018 (OS X 10.13) so I imagine this is just somewhere in our texture upload code. Jamie, can you dig a bit into this?