Valgrind doesn't seem able to read the debug information from the compiled CUPS binaries. Details below. Reproducible: Always Steps to Reproduce: 1. Grab CUPS sources from cups.org 2. ./configure 3. make test 4. Answer "Y" when asked to run CUPS in valgrind Actual Results: Valgrind logs in /tmp/cups-$USER/log show lots of errors reading the debug info. Expected Results: No errors about reading debug info. (output from the run of cupsd in the automated test suite; other programs run in the test suite report similar debug info errors) ==93496== Memcheck, a memory error detector ==93496== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. ==93496== Using Valgrind-3.10.0.BETA1 and LibVEX; rerun with -h for copyright info ==93496== Command: ../scheduler/cupsd -c /private/tmp/cups-msweet/cupsd.conf -f ==93496== Parent PID: 93362 ==93496== --93496-- run: /usr/bin/dsymutil "../scheduler/cupsd" --93496-- WARNING: Serious error when reading debug info --93496-- When reading debug info from ../scheduler/cupsd: --93496-- Ignoring non-Dwarf2/3/4 block in .debug_info --93496-- WARNING: Serious error when reading debug info --93496-- When reading debug info from ../scheduler/cupsd: --93496-- Last block truncated in .debug_info; ignoring --93496-- WARNING: Serious error when reading debug info --93496-- When reading debug info from ../scheduler/cupsd: --93496-- parse_CU_Header: is neither DWARF2 nor DWARF3 nor DWARF4 parse DIE(readdwarf3.c:2139): confused by: <0><b>: Abbrev Number: 1 (DW_TAG_compile_unit) DW_AT_producer : (indirect string, offset: 0x1): Apple LLVM version 5.0 (clang-500.0.68) (based on LLVM 3.3svn) DW_AT_language : 12 DW_AT_name : (indirect string, offset: 0x40): vg_preloaded.c DW_AT_low_pc : 0x860 DW_AT_stmt_list : 0 DW_AT_comp_dir : (indirect string, offset: 0x4f): /Users/msweet/c/valgrind-3.10.0.BETA1/coregrind DW_AT_??? : 1 parse_var_DIE: --93496-- WARNING: Serious error when reading debug info --93496-- When reading debug info from /usr/local/lib/valgrind/vgpreload_core-amd64-darwin.so: --93496-- confused by the above DIE parse DIE(readdwarf3.c:2139): confused by: <0><b>: Abbrev Number: 1 (DW_TAG_compile_unit) DW_AT_producer : (indirect string, offset: 0x1): Apple LLVM version 5.0 (clang-500.0.68) (based on LLVM 3.3svn) DW_AT_language : 12 DW_AT_name : (indirect string, offset: 0x40): m_replacemalloc/vg_replace_malloc.c DW_AT_low_pc : 0xeb0 DW_AT_stmt_list : 0 DW_AT_comp_dir : (indirect string, offset: 0x64): /Users/msweet/c/valgrind-3.10.0.BETA1/coregrind DW_AT_??? : 1 parse_var_DIE: --93496-- WARNING: Serious error when reading debug info --93496-- When reading debug info from /usr/local/lib/valgrind/vgpreload_memcheck-amd64-darwin.so: --93496-- confused by the above DIE --93496-- run: /usr/bin/dsymutil "/Users/msweet/c/cups-trunk/scheduler/libcupsmime.1.dylib" --93496-- WARNING: Serious error when reading debug info --93496-- When reading debug info from /Users/msweet/c/cups-trunk/scheduler/libcupsmime.1.dylib: --93496-- Last block truncated in .debug_info; ignoring --93496-- WARNING: Serious error when reading debug info --93496-- When reading debug info from /Users/msweet/c/cups-trunk/scheduler/libcupsmime.1.dylib: --93496-- parse_CU_Header: is neither DWARF2 nor DWARF3 nor DWARF4 --93496-- run: /usr/bin/dsymutil "/Users/msweet/c/cups-trunk/cups/libcups.2.dylib" --93496-- WARNING: Serious error when reading debug info --93496-- When reading debug info from /Users/msweet/c/cups-trunk/cups/libcups.2.dylib: --93496-- Ignoring non-Dwarf2/3/4 block in .debug_info --93496-- WARNING: Serious error when reading debug info --93496-- When reading debug info from /Users/msweet/c/cups-trunk/cups/libcups.2.dylib: --93496-- Ignoring non-Dwarf2/3/4 block in .debug_info --93496-- WARNING: Serious error when reading debug info --93496-- When reading debug info from /Users/msweet/c/cups-trunk/cups/libcups.2.dylib: --93496-- Last block truncated in .debug_info; ignoring --93496-- WARNING: Serious error when reading debug info --93496-- When reading debug info from /Users/msweet/c/cups-trunk/cups/libcups.2.dylib: --93496-- parse_CU_Header: is neither DWARF2 nor DWARF3 nor DWARF4 UNKNOWN __pthread_sigmask is unsupported. This warning will not be repeated. ...
Created attachment 88544 [details] Full valgrind output from cupsd
Michael, thanks for testing. Dang! How long has that been going on? Have you also been running against older versions of the V trunk?
Can you try with --read-inline-info=no ?
Could you try rebuilding using gcc? There is something llvm produces that isn't being recognized as DWARF. Could you attach one of the failing binaries? On of the vgpreload sos would be helpful for inspection.
(In reply to Mark Wielaard from comment #4) > Could you try rebuilding using gcc? There is something llvm produces that > isn't being recognized as DWARF. Could you attach one of the failing > binaries? On of the vgpreload sos would be helpful for inspection. Or, maybe better, since the binaries might not be ELF but machos which is somewhat difficult to interpret on none-macos systems. Could you attach a readelf --debug-dump=info output of that binary?
(In reply to Julian Seward from comment #2) > Michael, thanks for testing. Dang! How long has that been going on? > Have you also been running against older versions of the V trunk? I haven't been keeping up with trunk lately, but I did see it a while back (r14205 according to svn info) and got pulled to other things before I could write up a bug. I saw the beta announcement this morning so I decided to give it a quick whirl and got the same behavior... (so apologies I didn't report this sooner, been pulled in too many different directions lately...)
(In reply to Mark Wielaard from comment #4) > Could you try rebuilding using gcc? There is something llvm produces that > isn't being recognized as DWARF. Could you attach one of the failing > binaries? On of the vgpreload sos would be helpful for inspection. GCC no longer exists as of Xcode 5/OS X 10.8+9, so I can't help you there on the OS X side. I don't get the same failures on my Linux VMs (and they *are* still using GCC since Clang is not well supported with 64-bit Linux right now...) I'll attach everything I can...
Created attachment 88546 [details] cupsd executable
Created attachment 88547 [details] vgpreload_core-amd64-darwin.so
(In reply to Mark Wielaard from comment #5) > (In reply to Mark Wielaard from comment #4) > > Could you try rebuilding using gcc? There is something llvm produces that > > isn't being recognized as DWARF. Could you attach one of the failing > > binaries? On of the vgpreload sos would be helpful for inspection. > > Or, maybe better, since the binaries might not be ELF but machos which is > somewhat difficult to interpret on none-macos systems. Could you attach a > readelf --debug-dump=info output of that binary? No "readelf" command on OS X... dwarfdump points me to the cupsd.dSYM/Contents/Resources/DWARF directory, which contains a cupsd file (will attach).
Created attachment 88548 [details] cupsd.dSYM/Contents/Resources/DWARF/cupsd file
(In reply to Julian Seward from comment #3) > Can you try with --read-inline-info=no ? Doesn't help, still getting the same errors.
(In reply to Michael Sweet from comment #12) > (In reply to Julian Seward from comment #3) > > Can you try with --read-inline-info=no ? > > Doesn't help, still getting the same errors. Would be nice to try the following 4 combinations of --read-var-info=yes/no --read-inline-info=yes/no If you have an error with no/no, then that is really a critical problem as that means that even reading the line number info and so on has a problem. Thanks
It's the --read-var-info=yes that is spooking Valgrind. For CUPS you can work around it by removing that from the VALGRIND definition in tests/run-stp-tests.sh.
Is --read-var-info=no --read-inline-info=yes working ok ? Seems strange, as the CU header parsing should give the same errors/problems ? Or maybe the inline info parser does not need to know the CU low/high pc boundaries and so does not barf on the CU die only have low pc ?
The problem (or, one problem) is that parse_DIE cannot determine the PC range of the DIE; and indeed it doesn't specify what it is. Here's what V says: I got hlo 1 hhi1 0 hrange 0 // this is from readdwarf3.c:2141 parse DIE(readdwarf3.c:2143): confused by: <0><b>: Abbrev Number: 1 (DW_TAG_compile_unit) DW_AT_producer : (indirect string, offset: 0x1): Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn) DW_AT_language : 12 DW_AT_name : (indirect string, offset: 0x40): ipptool.c DW_AT_low_pc : 0x100001300 DW_AT_stmt_list : 0 DW_AT_comp_dir : (indirect string, offset: 0x4a): /Users/sewardj/VgTRUNK/trunk/RMME/cups-2.0rc1/test DW_AT_??? : 1 parse_var_DIE: --28880-- WARNING: Serious error when reading debug info --28880-- When reading debug info from ./test/ipptool: --28880-- confused by the above DIE dwarfdump says this: 0x0000000b: TAG_compile_unit [1] * AT_producer( "Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn)" ) AT_language( DW_LANG_C99 ) AT_name( "ipptool.c" ) AT_low_pc( 0x0000000100001300 ) AT_stmt_list( 0x00000000 ) AT_comp_dir( "/Users/sewardj/VgTRUNK/trunk/RMME/cups-2.0rc1/test" ) AT_APPLE_optimized( 0x01 ) So .. that corresponds with what V read. It also doesn't appear to give a way to determine the PC range. However, dwarfdump also first prints this 0x00000000: Compile Unit: length = 0x000067ee version = 0x0002 abbr_offset = 0x00000000 addr_size = 0x08 (next CU at 0x000067f2) and I don't know if that is useful or not.
As far as I can see, there's no way to get a PC range value from that DIE. Bizarre.
(In reply to Philippe Waroquiers from comment #15) > Is > --read-var-info=no --read-inline-info=yes > working ok ? --read-inline-info=no --read-var-info=no no problem --read-inline-info=yes --read-var-info=no no problem --read-inline-info=no --read-var-info=yes problem --read-inline-info=yes --read-var-info=yes problem
(In reply to Julian Seward from comment #16) > The problem (or, one problem) is that parse_DIE cannot determine the > PC range of the DIE; and indeed it doesn't specify what it is. > [...] > 0x00000000: Compile Unit: length = 0x000067ee version = 0x0002 abbr_offset > = 0x00000000 addr_size = 0x08 (next CU at 0x000067f2) > > and I don't know if that is useful or not. That is just the meta information to find the next CU, it doesn't tell you anything about the address ranges this CU covers. This looks like a duplicate of bug #306340 which is upstream clang/llvm bug http://llvm.org/bugs/show_bug.cgi?id=13351 The only way around it would be to read all the DIEs in the CU and take the union of their address ranges to be the addresses covered by this CU. Maybe easiest for now would be to detect in configure that clang/llvm is used to build valgrind and assume it is the system compiler (so all binaries will have bogus DWARF) and disable read-inline-info and read-var-info by default.
(In reply to Mark Wielaard from comment #19) > This looks like a duplicate of bug #306340 which is upstream clang/llvm bug > http://llvm.org/bugs/show_bug.cgi?id=13351 > > The only way around it would be to read all the DIEs in the CU and take the > union of their address ranges to be the addresses covered by this CU. Meh. But yes, doable I guess. Ugly. > Maybe easiest for now would be to detect in configure that clang/llvm is > used to build valgrind and assume it is the system compiler (so all binaries > will have bogus DWARF) and disable read-inline-info and read-var-info by > default. At least with the testing I did, it does not appear to impact read-inline-info, only read-var-info, so the problem is not _so_ critical.
This issue is also reproducible within Valgrind's own regression tests on OS X as follows: $ perl tests/vg_regtest memcheck/tests/dw4