With SPS enabled I get crashes at semi-random times on my Linux x86-64 system (Fedora 18). Example stack trace: #0 x86_64_fallback_frame_state (context=0x7fffffff5900, context=0x7fffffff5900, fs=0x7fffffff59f0) at ./md-unwind-support.h:53 #1 uw_frame_state_for (context=context@entry=0x7fffffff5900, fs=fs@entry=0x7fffffff59f0) at ../../../libgcc/unwind-dw2.c:1187 #2 0x000000366b20ff6c in _Unwind_Backtrace (trace=0x3669306aa0 <backtrace_helper>, trace_argument=0x7fffffff5bb0) at ../../../libgcc/unwind.inc:290 #3 0x0000003669306c36 in __GI___backtrace (array=<optimized out>, size=100) at ../sysdeps/x86_64/backtrace.c:109 #4 0x00007ffff4dc43fb in TableTicker::doNativeBacktrace (this=this@entry=0x7fffdd391380, aProfile=..., aSample=aSample@entry=0x7fffffff5fb0) at /home/roc/mozilla-central/tools/profiler/TableTicker.cpp:354 #5 0x00007ffff4dc455c in TableTicker::InplaceTick (this=0x7fffdd391380, sample=0x7fffffff5fb0) at /home/roc/mozilla-central/tools/profiler/TableTicker.cpp:527 #6 0x00007ffff4dc1990 in ProfilerSignalHandler (signal=<optimized out>, info=<optimized out>, context=<optimized out>) at /home/roc/mozilla-central/tools/profiler/platform-linux.cc:207 #7 ProfilerSignalHandler (signal=<optimized out>, info=<optimized out>, context=<optimized out>) at /home/roc/mozilla-central/tools/profiler/platform-linux.cc:159 #8 <signal handler called> #9 0x00000035dc93e2a8 in ?? () from /usr/lib64/nvidia-304xx/libnvidia-glcore.so.304.88 #10 0x0000000000000139 in ?? () #11 0x00000035dc9818f2 in ?? () from /usr/lib64/nvidia-304xx/libnvidia-glcore.so.304.88 #12 0x00000035dc980d52 in ?? () from /usr/lib64/nvidia-304xx/libnvidia-glcore.so.304.88 #13 0x00000035dc974466 in ?? () from /usr/lib64/nvidia-304xx/libnvidia-glcore.so.304.88 #14 0x00000035dc8eba85 in ?? () from /usr/lib64/nvidia-304xx/libnvidia-glcore.so.304.88 #15 0x00000035dc8ed5f6 in ?? () from /usr/lib64/nvidia-304xx/libnvidia-glcore.so.304.88 #16 0x00000035dd0375b5 in ?? () from /usr/lib64/nvidia-304xx/libnvidia-glcore.so.304.88 #17 0x00000035dd037da2 in ?? () from /usr/lib64/nvidia-304xx/libnvidia-glcore.so.304.88 #18 0x00007ffff503290c in (anonymous namespace)::compile_shader (gl=..., type=type@entry=35632, strings=strings@entry=0x7fffffffa248, stringLengths=stringLengths@entry=0x7fffffffa23c, stringCnt=1) at /home/roc/mozilla-central/gfx/skia/src/gpu/gl/GrGLProgram.cpp:345 #19 0x00007ffff5032e29 in compile_shader (shader=..., type=35632, gl=...) at /home/roc/mozilla-central/gfx/skia/src/gpu/gl/GrGLProgram.cpp:372 #20 GrGLProgram::compileShaders (this=this@entry=0x7fffb29e5800, builder=...) at /home/roc/mozilla-central/gfx/skia/src/gpu/gl/GrGLProgram.cpp:411 #21 0x00007ffff503447a in GrGLProgram::genProgram (this=0x7fffb29e5800, stages=<optimized out>) at /home/roc/mozilla-central/gfx/skia/src/gpu/gl/GrGLProgram.cpp:662 #22 0x00007ffff503485b in GrGLProgram::Create (gl=..., desc=..., stages=0x7fffffffa9e0) at /home/roc/mozilla-central/gfx/skia/src/gpu/gl/GrGLProgram.cpp:41 #23 0x00007ffff503cb92 in GrGpuGL::ProgramCache::getProgram (this=0x7fff78ea4000, desc=..., stages=stages@entry=0x7fffffffa9e0) at /home/roc/mozilla-central/gfx/skia/src/gpu/gl/GrGpuGL_program.cpp:64 #24 0x00007ffff503ce54 in GrGpuGL::flushGraphicsState (this=0x7fff768fe000, type=GrGpu::kDrawTriangles_DrawType, dstCopy=0x0) at /home/roc/mozilla-central/gfx/skia/src/gpu/gl/GrGpuGL_program.cpp:193 #25 0x00007ffff501d888 in GrGpu::onDraw (this=0x7fff768fe000, info=...) at /home/roc/mozilla-central/gfx/skia/src/gpu/GrGpu.cpp:378 #26 0x00007ffff50208a3 in executeDraw (info=..., this=<optimized out>) at /home/roc/mozilla-central/gfx/skia/src/gpu/GrDrawTarget.h:424 #27 GrInOrderDrawBuffer::flush (this=0x7fff76a68000) at /home/roc/mozilla-central/gfx/skia/src/gpu/GrInOrderDrawBuffer.cpp:468 #28 0x00007ffff50167c5 in GrContext::flush (this=0x7fff7826c550, flagsBitfield=0) at /home/roc/mozilla-central/gfx/skia/src/gpu/GrContext.cpp:1080 #29 0x00007ffff5016960 in GrContext::resolveRenderTarget (this=0x7fff7826c550, target=0x7fff76a2b9c0) at /home/roc/mozilla-central/gfx/skia/src/gpu/GrContext.cpp:1338 #30 0x00007ffff46ec05b in mozilla::dom::CanvasRenderingContext2D::GetCanvasLayer (this=0x7fff6d254c00, aBuilder=<optimized out>, aOldLayer= 0x7fffb20f4400, aManager=0x7fffe32744b0) at /home/roc/mozilla-central/content/canvas/src/CanvasRenderingContext2D.cpp:3883 #31 0x00007ffff474e971 in mozilla::dom::HTMLCanvasElement::GetCanvasLayer (this=<optimized out>, aBuilder=<optimized out>, aOldLayer=<optimized out>, aManager=<optimized out>) at /home/roc/mozilla-central/content/html/content/src/HTMLCanvasElement.cpp:996 'pc' is generally some small but non-null value, in this case 0x139. Not a good thing to be dereferencing. I don't have good steps to reproduce yet but these crashes are reasonably easy to reproduce if you want me to try debugging.

BTW this is mozilla-central changeset a4c1961bf723 plus a few patches of my own.

Also: [roc@eternity mozilla-central]$ rpm -qf /usr/src/debug/gcc-4.7.2-20121109/libgcc/unwind-dw2.c gcc-base-debuginfo-4.7.2-8.fc18.x86_64

roc - you could try setting MOZ_PROFILER_NEW=1 and MOZ_PROFILER_MODE=native. That should switch to the new Breakpad-based unwinder. I guess it's not the default yet?

This is because the Linux nvidia driver doesn't have proper frame pointers so the unwind de-references bad memory. (In reply to Steve Fink [:sfink] from comment #3) > roc - you could try setting MOZ_PROFILER_NEW=1 and MOZ_PROFILER_MODE=native. > That should switch to the new Breakpad-based unwinder. I guess it's not the > default yet? If you select the 'Breakpad' check mark you will get MOZ_PROFILER_NEW=1 and the mixed profiler mode which is what I recommend running on Linux. We could certainly use more feedback on how well that mode works as we will be switching it to the default soon.

(In reply to Benoit Girard (:BenWa) from comment #4) > This is because the Linux nvidia driver doesn't have proper frame pointers > so the unwind de-references bad memory. That makes sense, but it's kind of sad that such a failure manifests as as a crash :-(. Selecting the Breakpad mode doesn't seem to work very well. Here's a link to the profile I got: http://people.mozilla.com/~bgirard/cleopatra/#report=8323f45d5cf575d35962869995c77f26df55cc75

We can prevent the code from crashing if we told it the stack bounds which we now always collect. But we haven't done so because we're going to be replacing it by Breakpad. The Breakpad mode works much better under Linux 32-bits for now. Linux 64-bit with Breakpad needs some improvements. If we really need to decent amount of profiling on Linux in the short term it would be a good idea to revisit this decision and implement a proper stack boundary while we wait for Breakpad to improve on desktop.

(In reply to Benoit Girard (:BenWa) from comment #6) > We can prevent the code from crashing if we told it the stack bounds which > we now always collect. But we haven't done so because we're going to be > replacing it by Breakpad. The Breakpad mode works much better under Linux > 32-bits for now. Linux 64-bit with Breakpad needs some improvements. sounds like this means bug 855466