chrome, content_shell and DumpRenderTree fail to start on arm linux because stack unwinding during malloc recording crashes

[GoogleCodeExporter]

os: Linux winaro 3.0.51 #1 SMP PREEMPT Fri Jan 4 18:02:22 KST 2013 armv7l 
armv7l armv7l GNU/Linux
llvm rev: 171861
triplet: arm-linux-gnueabihf
linker: GNU gold (GNU Binutils 2.23.51.20130109) 1.11 (ToT)

what works: base_unittests, other unit tests
what doesn't work: DumpRenderTree, content_shell, chrome
workaround: ASAN_OPTIONS="malloc_context_size=0" 

[linaro] ~/out/Release % gdb ./DumpRenderTree                                   

GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2.1) 7.4-2012.04
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "arm-linux-gnueabihf".
For bug reporting instructions, please see:
<http://bugs.launchpad.net/gdb-linaro/>...
Reading symbols from /home/linaro/out/Release/DumpRenderTree...done.
(gdb) r
Starting program: /home/linaro/out/Release/DumpRenderTree 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
[New Thread 0x419ae2e0 (LWP 31304)]
[New Thread 0x41bb32e0 (LWP 31305)]

Program received signal SIGSEGV, Segmentation fault.
0x409788d4 in _Unwind_VRS_Pop () from /lib/arm-linux-gnueabihf/libgcc_s.so.1
(gdb) bt
#0  0x409788d4 in _Unwind_VRS_Pop () from /lib/arm-linux-gnueabihf/libgcc_s.so.1
#1  0x40978f0a in ?? () from /lib/arm-linux-gnueabihf/libgcc_s.so.1
#2  0x4097859c in ?? () from /lib/arm-linux-gnueabihf/libgcc_s.so.1
#3  0x40978c20 in ?? () from /lib/arm-linux-gnueabihf/libgcc_s.so.1
#4  0x40978de2 in _Unwind_Backtrace () from 
/lib/arm-linux-gnueabihf/libgcc_s.so.1
#5  0x00080e32 in __sanitizer::StackTrace::SlowUnwindStack (this=0xbeffd070, 
pc=501117, max_depth=<optimized out>) at 
/home/linaro/llvm/projects/compiler-rt/lib/sanitizer_common/sanitizer_linux.cc:4
23
#6  0x0007a594 in __interceptor_malloc (size=47) at 
/home/linaro/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:74
#7  0x409a642a in ?? () from /lib/arm-linux-gnueabihf/libc.so.6
#8  0x40007340 in ?? () from /lib/ld-linux-armhf.so.3
#9  0x4000754a in ?? () from /lib/ld-linux-armhf.so.3
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb) 

[linaro] ~/out/Release % ./DumpRenderTree                                       

ASAN:SIGSEGV
=================================================================
==31327== ERROR: AddressSanitizer: SEGV on unknown address 0x0000006c (pc 
0x409d68d4 sp 0xbee0fb68 bp 0x00000000 T0)
AddressSanitizer can not provide additional info.
    #0 0x409d68d3 (/lib/arm-linux-gnueabihf/libgcc_s.so.1+0x68d3)
    #1 0x7b1df (/home/linaro/out/Release/DumpRenderTree+0x7b1df)
    #2 0x40a06acf (/lib/arm-linux-gnueabihf/libc-2.15.so+0x25acf)
    #3 0x409d68d3 (/lib/arm-linux-gnueabihf/libgcc_s.so.1+0x68d3)
    #4 0x409d6f09 (/lib/arm-linux-gnueabihf/libgcc_s.so.1+0x6f09)
    #5 0x409d659b (/lib/arm-linux-gnueabihf/libgcc_s.so.1+0x659b)
    #6 0x409d6c1f (/lib/arm-linux-gnueabihf/libgcc_s.so.1+0x6c1f)
Stats: 0M malloced (0M for red zones) by 1264 calls
Stats: 0M realloced by 1 calls
Stats: 0M freed by 642 calls
Stats: 0M really freed by 0 calls
Stats: 4M (4M-0M) mmaped; 9 maps, 0 unmaps
  mmaps   by size class: 7:4095; 8:2047; 9:1023; 10:511; 11:255; 12:128; 13:64; 14:32; 15:16; 
  mallocs by size class: 7:1043; 8:79; 9:22; 10:78; 11:13; 12:13; 13:8; 14:1; 15:7; 
  frees   by size class: 7:531; 8:40; 9:11; 10:44; 11:7; 12:4; 13:4; 15:1; 
  rfrees  by size class: 
Stats: malloc large: 7 small slow: 20
Stats: StackDepot: 0 ids; 0M mapped
==31327== ABORTING

Original issue reported on code.google.com by miaubiz@gmail.com on 14 Jan 2013 at 8:36

[GoogleCodeExporter]

Original comment by konstant...@gmail.com on 14 Jan 2013 at 8:42

[GoogleCodeExporter]

Looks like broken unwind tables in one of the system libraries. Gdb is not very 
happy with them, too (the "corrupt stack" line).

We had a similar, but android-specific, issue: 
https://android.googlesource.com/platform/bionic/+/cd15bacf334ab254a5f61c3bba100
adde1b6b80a

It would help to investigate what these unnamed frames in libc and ld-linux 
are, whether they have unwind instructions, and whether those instructions make 
sense. You can use "readelf -a" for that.

It would also be useful to compare stacks as printed by gdb, and as observed 
from asan's Unwind_Trace, and if the latter is shorter, then the next frame is 
the culprit.

Original comment by euge...@google.com on 14 Jan 2013 at 9:21

[GoogleCodeExporter]

is this actionable on our side? 

Original comment by konstant...@gmail.com on 18 Feb 2013 at 4:19

[GoogleCodeExporter]

Original comment by ramosian.glider@gmail.com on 30 Jul 2015 at 9:05

• Added labels: ProjectAddressSanitizer

[GoogleCodeExporter]

Adding Project:AddressSanitizer as part of GitHub migration.

Original comment by ramosian.glider@gmail.com on 30 Jul 2015 at 9:06