Re: [Libunwind-devel] [PATCH] Check that the CIE is within the segment

[Milian Wolff]

On Monday 15 December 2014 23:12:29 Milian Wolff wrote:
> Hey Peter,

Hey again, more details below, and this time also sent to the libunwind ML.

> Peter Wu schrieb am 15.12.2014 22:04:
> > On Monday 15 December 2014 19:34:36 Milian Wolff wrote:
> >> On Tuesday 25 November 2014 22:10:33 Peter Wu wrote:
> >> > Due to a bug in the gold linker[1], the .eh_frame and .eh_frame_hdr
> >> > sections contains garbage. When dwarf_extract_proc_info_from_fde tried
> >> > to look up the begin of the CIE subsection, it would underflow the
> >> > .eh_frame segment, resulting in a crash[2].
> >> > 
> >> > This patch avoids that crash by checking whether the CIE pointer is
> >> > located after the begin of the .eh_frame section. The variable "base"
> >> > was misused in various places as a boolean (decode as .debug_frame or
> >> > decode as .eh_frame). These instances have been renamed to
> >> > is_debug_frame where applicable.
> >> > 
> >> > Tested on Linux x86_64.
> >> > 
> >> >  [1]: https://sourceware.org/bugzilla/show_bug.cgi?id=17639
> >> > 
> >> >  [2]:
> >> > http://lists.nongnu.org/archive/html/libunwind-devel/2014-11/msg00009.h
> >> > tml
> >> 
> >> Hello Peter,
> >> 
> >> I have an issue with your patch on my machine. With it applied, my tool
> >> fails to find backtraces. Attached, you find the libunwind debug output
> >> of current master with and without your patch applied. I've also
> >> modified libunwind to output a debug message when your patch hits, i.e.
> >> the cie_offset_addr < base conditional is met.
> >> 
> >> This apparently completely breaks libunwind on my machine...
> >> 
> >> 3.17.6-1-ARCH
> >> Intel(R) Core(TM)2 Quad CPU    Q9550  @ 2.83GHz
> >> GNU gold (GNU Binutils 2.24) 1.11
> >> gcc (GCC) 4.9.2
> >> 
> >> Do you need any other information?
> > 
> > Hi Milian,
> > 
> > Could you describe how to setup an environment where this problem
> > occurs? What would help:
> > 
> > - The program that triggers this crash (preferably source code or some
> > 
> >   official package in the repos). If this is not possible, maybe you
> >   could dump the .eh_frame and .eh_frame_hdr sections?
> > 
> > - Compiler flags for this program (if customized).
> > 
> > I checked out git://anongit.kde.org/heaptrack and executed:
> >    DUMP_HEAPTRACK_OUTPUT=some.txt LD_PRELOAD=./libheaptrack_preload.so
> >    LD_LIBRARY_PATH=/path/to/libunwind/build/src/.libs $PROGRAM
> > 
> > where $PROGRAM is ls, 'upower --version', 'udevadm monitor', but none of
> > them trigger a crash.
> 
> Try this:
> 
> cd heaptrack
> mkdir build
> cd build
> cmake .. -DCMAKE_BUILD_TYPE=RelWithDebInfo
> make
> make install
> heaptrack ./tests/test_cpp
> 
> The result will be broken, i.e. heaptrack_print on the
> heaptrack.test_cpp.$$.gz file will not show any backtraces. When you also
> set UNW_DEBUG_LEVEL=15 you should see a similar output to mine.
> 
> NOTE: It does not crash, it simply fails to get useful backtraces
> (unw_backtrace returns nothing). And it also did not crash before, without
> your patch - quite the contrary ;-) It works like a charm there and
> successfully unwinds the backtraces.
> > I also run Arch Linux (with testing repo) and can easily bootstrap a new
> > Arch VM if necessary.
> 
> Same for me. I'll try to test this also on another machine of mine to see
> whether it makes a difference. You'll hear back from me on friday.
> 
> Thanks for looking into this! Take care

So, now I also tested this on an Intel(R) Core(TM) i3-2310M CPU @ 2.10GHz and 
there the issue does not manifest... Both machines are, software-wise, 
identical. I tried to use clang to see whether it makes a difference, but 
still no change. 

On the "broken" machine:
               >_ULx86_64_dwarf_extract_proc_info_from_fde: looking for CIE at 
address 7fe052c8c890
               >parse_cie: CIE parsed OK, augmentation = "zR", handler=0x0
             >_ULx86_64_dwarf_extract_proc_info_from_fde: CIE not within 
segment: 0x7fe0540879c4 base: 0x7fe054087b2c
             >_ULx86_64_dwarf_extract_proc_info_from_fde: CIE not within 
segment: 0x7fe05408795c base: 0x7fe054087b2c

Note: no further UNW_DEBUG_LEVEL output contains "cie".

On the other, non-broken machine:
               >_ULx86_64_dwarf_extract_proc_info_from_fde: looking for CIE at 
address 7fd12f73de88
               >parse_cie: CIE parsed OK, augmentation = "zR", handler=0x0
               >_ULx86_64_dwarf_extract_proc_info_from_fde: looking for CIE at 
address 7fd13092f158
               >parse_cie: CIE parsed OK, augmentation = "zPLR", 
handler=0x400cd0
               >_ULx86_64_dwarf_extract_proc_info_from_fde: looking for CIE at 
address 7fd13092f158
               >parse_cie: CIE parsed OK, augmentation = "zPLR", 
handler=0x400cd0
               >_ULx86_64_dwarf_extract_proc_info_from_fde: looking for CIE at 
address 7fd1306eb8c8
               >parse_cie: CIE parsed OK, augmentation = "zR", handler=0x0
               >_ULx86_64_dwarf_extract_proc_info_from_fde: looking for CIE at 
address 4013a8
...

This goes on and one with similar output and the backtraces are produced 
correctly.

Any more information I could dig up for you?

Bye
-- 
Milian Wolff
address@hidden
http://milianw.de