On 2016-12-03 10:19:56 [+0100], Yves-Alexis Perez wrote: > I'm not sure if it's the same issue than in 845785 so I'm not reopening that > bug, but rather raising the severity of this one. I can confirm chromium still > crashes here and there, sometime randomly, sometimes consistently.
It looks like the same thing. Thread 34 "Chrome_InProcRe" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fffc78b7700 (LWP 5208)] 0x000055555ae4cdaf in SkPictureGpuAnalyzer::analyzePicture(SkPicture const*) () (gdb) bt #0 0x000055555ae4cdaf in SkPictureGpuAnalyzer::analyzePicture(SkPicture const*) () #1 0x000055555934e644 in blink::PaintController::commitNewDisplayItems(blink::LayoutSize const&) () … #26 0x00007fffecfed9df in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105 (gdb) disassemble Dump of assembler code for function _ZN20SkPictureGpuAnalyzer14analyzePictureEPK9SkPicture: 0x000055555ae4cda0 <+0>: test %rsi,%rsi 0x000055555ae4cda3 <+3>: je 0x55555ae4cdb5 <_ZN20SkPictureGpuAnalyzer14analyzePictureEPK9SkPi 0x000055555ae4cda5 <+5>: mov (%rsi),%rax 0x000055555ae4cda8 <+8>: push %rbx 0x000055555ae4cda9 <+9>: mov %rdi,%rbx 0x000055555ae4cdac <+12>: mov %rsi,%rdi => 0x000055555ae4cdaf <+15>: callq *0x48(%rax) 0x000055555ae4cdb2 <+18>: add %eax,(%rbx) 0x000055555ae4cdb4 <+20>: pop %rbx 0x000055555ae4cdb5 <+21>: repz retq End of assembler dump. (gdb) info registers rax 0x0 0 rbx 0x7fffc78b59d0 140736541186512 rcx 0x67c00000000 7129645711360 rdx 0x67c000001f5 7129645711861 rsi 0x29f0ddfa8870 46114493073520 rdi 0x29f0ddfa8870 46114493073520 rbp 0x7fffc78b59d0 0x7fffc78b59d0 rsp 0x7fffc78b5950 0x7fffc78b5950 r8 0x95 149 r9 0x950000002f 639950127151 r10 0x67c000001f5 7129645711861 r11 0x1c0877f48c70 30822697831536 r12 0x1c0877e36b98 30822696709016 r13 0x7fffc78b5cb0 140736541187248 r14 0x1d1034b88680 31955441190528 r15 0x1c0878192ba0 30822700231584 rip 0x55555ae4cdaf 0x55555ae4cdaf <SkPictureGpuAnalyzer::analyzePicture(SkPicture const*)+15> eflags 0x10202 [ IF RF ] cs 0x33 51 ss 0x2b 43 ds 0x0 0 es 0x0 0 fs 0x0 0 gs 0x0 0 and the function: | void SkPictureGpuAnalyzer::analyzePicture(const SkPicture* picture) { | if (!picture) { | return; | } | | fNumSlowPaths += picture->numSlowPaths(); | } So we do have the NULL pointer check but somehow the ->numSlowPaths function is NULL. Trying it again and again it explodes at a different spot. Sometimes even in the TC malloc allocater. I rebuilt it even with "gcc version 6.2.0 20160901 (Debian 6.2.0-3)" including all its deps from 20160905T103837Z and it still explodes. Same for current gcc-5. > Regards, Sebastian