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 [email protected] http://milianw.de _______________________________________________ Libunwind-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/libunwind-devel
