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

[ramosian-glider]

Originally reported on Google Code with ID 141

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:423
#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

Reported by miaubiz on 2013-01-14 08:36:30

[ramosian-glider]

Reported by konstantin.s.serebryany on 2013-01-14 08:42:54

[ramosian-glider]

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/+/cd15bacf334ab254a5f61c3bba100adde1b6b80a

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.

Reported by eugenis@google.com on 2013-01-14 09:21:01

[ramosian-glider]

is this actionable on our side? 

Reported by konstantin.s.serebryany on 2013-02-18 04:19:21

[ramosian-glider]

Reported by ramosian.glider on 2015-07-30 09:05:31

• Labels added: ProjectAddressSanitizer

[ramosian-glider]

Adding Project:AddressSanitizer as part of GitHub migration.

Reported by ramosian.glider on 2015-07-30 09:06:55