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

[Peter Wu]

On Wednesday 17 December 2014 14:26:15 Milian Wolff wrote:
> 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?

I have built heaptrack with RelWithDebInfo, but I still get a valid
backtrace. Can you reproduce the issue on the other machine with the
same libraries and binary?

Are the list of installed packages identical? You can compare the
`pacman -Q` output on both machines to find out.
-- 
Kind regards,
Peter
https://lekensteyn.nl