Created attachment 1328364 [details] strace dwz Description of problem: While building ocaml-ocamlbuild, dwz prints: dwz: Error mmapping multi-file temporary files and debuginfo generation consequently fails. See for example this build log: https://kojipkgs.fedoraproject.org//packages/ocaml-ocamlbuild/0.11.0/9.fc27/data/logs/x86_64/build.log (from https://koji.fedoraproject.org/koji/buildinfo?buildID=952978) Version-Release number of selected component (if applicable): dwz-0.12-3.fc26.x86_64 How reproducible: 100% Steps to Reproduce: 1. Rebuild the ocaml-ocamlbuild package. Additional info: I modified find-debuginfo.sh to collect the full strace of dwz (attached). The important lines are: open("/tmp/dwz.debug_info.9kw7ba", O_RDWR|O_CREAT|O_EXCL, 0600) = 3 unlink("/tmp/dwz.debug_info.9kw7ba") = 0 getpid() = 12159 open("/tmp/dwz.debug_abbrev.AdCBhi", O_RDWR|O_CREAT|O_EXCL, 0600) = 4 unlink("/tmp/dwz.debug_abbrev.AdCBhi") = 0 getpid() = 12159 open("/tmp/dwz.debug_line.NCN6mq", O_RDWR|O_CREAT|O_EXCL, 0600) = 5 unlink("/tmp/dwz.debug_line.NCN6mq") = 0 getpid() = 12159 open("/tmp/dwz.debug_str.yZQCsy", O_RDWR|O_CREAT|O_EXCL, 0600) = 6 unlink("/tmp/dwz.debug_str.yZQCsy") = 0 getpid() = 12159 open("/tmp/dwz.debug_macro.vMI9xG", O_RDWR|O_CREAT|O_EXCL, 0600) = 7 unlink("/tmp/dwz.debug_macro.vMI9xG") = 0 ... mmap(NULL, 0, PROT_READ, MAP_PRIVATE, 3, 0) = -1 EINVAL (Invalid argument) mmap(NULL, 0, PROT_READ, MAP_PRIVATE, 4, 0) = -1 EINVAL (Invalid argument) mmap(NULL, 17, PROT_READ, MAP_PRIVATE, 5, 0) = 0x7fbe5b1cc000 write(2, "dwz: ", 5) = 5 write(2, "Error mmapping multi-file temporary files", 41) = 41 write(2, "\n", 1) = 1 Linux returns -EINVAL because the length (second) parameter is 0. In the code: debug_sections[DEBUG_INFO].size = multi_info_off; debug_sections[DEBUG_INFO].data = mmap (NULL, multi_info_off, PROT_READ, MAP_PRIVATE, multi_info_fd, 0); debug_sections[DEBUG_ABBREV].size = multi_abbrev_off; debug_sections[DEBUG_ABBREV].data = mmap (NULL, multi_abbrev_off, PROT_READ, MAP_PRIVATE, multi_abbrev_fd, 0); debug_sections[DEBUG_LINE].size = multi_line_off; debug_sections[DEBUG_LINE].data = mmap (NULL, multi_line_off, PROT_READ, MAP_PRIVATE, multi_line_fd, 0); debug_sections[DEBUG_STR].size = multi_str_off; debug_sections[DEBUG_STR].data = multi_str_off ? mmap (NULL, multi_str_off, PROT_READ, MAP_PRIVATE, multi_str_fd, 0) : NULL; debug_sections[DEBUG_MACRO].size = multi_macro_off; debug_sections[DEBUG_MACRO].data = multi_macro_off ? mmap (NULL, multi_macro_off, PROT_READ, MAP_PRIVATE, multi_macro_fd, 0) : NULL; if (debug_sections[DEBUG_INFO].data == MAP_FAILED || debug_sections[DEBUG_ABBREV].data == MAP_FAILED || debug_sections[DEBUG_LINE].data == MAP_FAILED || debug_sections[DEBUG_STR].data == MAP_FAILED || debug_sections[DEBUG_MACRO].data == MAP_FAILED) { error (0, 0, "Error mmapping multi-file temporary files"); It's unclear to me why multi_info_off & multi_abbrev_off are both 0, but I guess there's something about the files which confuses dwz.
The files ./usr/bin/ocamlbuild.debug and ocamlbuild.native.debug seem to be corrupted somehow: /home/rjones/rpmbuild/BUILDROOT/ocaml-ocamlbuild-0.11.0-9.fc28.x86_64/usr/lib/debug/usr/bin/ocamlbuild.debug: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter \004, for GNU/Linux 2.6.32, BuildID[sha1]=ec831c5586a89a32a380257fec4e4ade7b68dd1c, with debug_info, not stripped /home/rjones/rpmbuild/BUILDROOT/ocaml-ocamlbuild-0.11.0-9.fc28.x86_64/usr/lib/debug/usr/bin/ocamlbuild.native.debug: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter \004, for GNU/Linux 2.6.32, BuildID[sha1]=ec831c5586a89a32a380257fec4e4ade7b68dd1c, with debug_info, not stripped Note that the interpreter ("\004") seems broken. It's not very clear to me how this works. Perhaps they are broken because we haven't finished writing them yet, or possibly this is expected.
(In reply to Richard W.M. Jones from comment #1) > The files ./usr/bin/ocamlbuild.debug and ocamlbuild.native.debug > seem to be corrupted somehow: > [...] > Note that the interpreter ("\004") seems broken. It's not very clear > to me how this works. Perhaps they are broken because we haven't > finished writing them yet, or possibly this is expected. A .debug file doesn't have an interpreter. It doesn't make sense for it to have one, because it isn't really an executable. So this isn't an issue. You might want to show eu-readelf -hS of the files to show the section headers. Or upload or attach the files for inspection.
ELF Header: Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 Class: ELF64 Data: 2's complement, little endian Ident Version: 1 (current) OS/ABI: UNIX - System V ABI Version: 0 Type: EXEC (Executable file) Machine: AMD x86-64 Version: 1 (current) Entry point address: 0x403d60 Start of program headers: 64 (bytes into file) Start of section headers: 2351712 (bytes into file) Flags: Size of this header: 64 (bytes) Size of program header entries: 56 (bytes) Number of program headers entries: 9 Size of section header entries: 64 (bytes) Number of section headers entries: 35 Section header string table index: 34 Section Headers: [Nr] Name Type Addr Off Size ES Flags Lk Inf Al [ 0] NULL 0000000000000000 00000000 00000000 0 0 0 0 [ 1] .interp PROGBITS 0000000000400238 00000238 0000001c 0 A 0 0 1 [ 2] .note.ABI-tag NOTE 0000000000400254 00000254 00000020 0 A 0 0 4 [ 3] .note.gnu.build-id NOTE 0000000000400274 00000274 00000024 0 A 0 0 4 [ 4] .gnu.hash GNU_HASH 0000000000400298 00000298 000000ac 0 A 5 0 8 [ 5] .dynsym DYNSYM 0000000000400348 00000348 00001200 24 A 6 1 8 [ 6] .dynstr STRTAB 0000000000401548 00001548 00000691 0 A 0 0 1 [ 7] .gnu.version GNU_versym 0000000000401bda 00001bda 00000180 2 A 5 0 2 [ 8] .gnu.version_r GNU_verneed 0000000000401d60 00001d60 000000e0 0 A 6 3 8 [ 9] .rela.dyn RELA 0000000000401e40 00001e40 00000078 24 A 5 0 8 [10] .rela.plt RELA 0000000000401eb8 00001eb8 00001140 24 AI 5 23 8 [11] .init PROGBITS 0000000000402ff8 00002ff8 00000017 0 AX 0 0 4 [12] .plt PROGBITS 0000000000403010 00003010 00000b90 16 AX 0 0 16 [13] .text PROGBITS 0000000000403ba0 00003ba0 000abcb2 0 AX 0 0 16 [14] .fini PROGBITS 00000000004af854 000af854 00000009 0 AX 0 0 4 [15] .rodata PROGBITS 00000000004af860 000af860 00003e80 0 A 0 0 32 [16] .eh_frame_hdr PROGBITS 00000000004b36e0 000b36e0 00007c9c 0 A 0 0 4 [17] .eh_frame PROGBITS 00000000004bb380 000bb380 00022e8c 0 A 0 0 8 [18] .init_array INIT_ARRAY 00000000006ded30 000ded30 00000008 8 WA 0 0 8 [19] .fini_array FINI_ARRAY 00000000006ded38 000ded38 00000008 8 WA 0 0 8 [20] .data.rel.ro PROGBITS 00000000006ded40 000ded40 000000a8 0 WA 0 0 32 [21] .dynamic DYNAMIC 00000000006dede8 000dede8 000001f0 16 WA 6 0 8 [22] .got PROGBITS 00000000006defd8 000defd8 00000018 8 WA 0 0 8 [23] .got.plt PROGBITS 00000000006df000 000df000 000005d8 8 WA 0 0 8 [24] .data PROGBITS 00000000006df5e0 000df5e0 00094418 0 WA 0 0 32 [25] .bss NOBITS 0000000000773a00 001739f8 000155f0 0 WA 0 0 32 [26] .comment PROGBITS 0000000000000000 001739f8 00000084 1 MS 0 0 1 [27] .debug_aranges PROGBITS 0000000000000000 00173a80 00000870 0 0 0 16 [28] .debug_info PROGBITS 0000000000000000 001742f0 00000816 0 0 0 1 [29] .debug_abbrev PROGBITS 0000000000000000 00174b06 00000384 0 0 0 1 [30] .debug_line PROGBITS 0000000000000000 00174e8a 0000a514 0 0 0 1 [31] .debug_str PROGBITS 0000000000000000 0017f39e 00000366 1 MS 0 0 1 [32] .symtab SYMTAB 0000000000000000 0017f708 000530a0 24 33 8933 8 [33] .strtab STRTAB 0000000000000000 001d27a8 0006b962 0 0 0 1 [34] .shstrtab STRTAB 0000000000000000 0023e10a 00000150 0 0 0 1
Created attachment 1328368 [details] ocamlbuild.native I believe this is only one file causing the problem, which is attached.
I don't immediately see anything wrong with it. It is just very boring, since it has only minimal debuginfo produced by GAS. So just one compile_unit DIE per file, but no other content at all. In fact it is so boring that dwz cannot do anything with it: $ dwz ocamlbuild.native dwz: ocamlbuild.native: DWARF compression not beneficial - old size 2960 new size 2960 So without the other files it is hard to reproduce.
Created attachment 1328403 [details] Reproducer Unpack the attached tarball and do: $ dwz -h -q -r -m ocaml-ocamlbuild-0.11.0-9.fc28.x86_64 -l 10000000 -L 110000000 ./usr/bin/ocamlbuild ./usr/bin/ocamlbuild.native dwz: Error mmapping multi-file temporary files
(In reply to Richard W.M. Jones from comment #6) > $ dwz -h -q -r -m ocaml-ocamlbuild-0.11.0-9.fc28.x86_64 -l 10000000 -L > 110000000 ./usr/bin/ocamlbuild ./usr/bin/ocamlbuild.native > dwz: Error mmapping multi-file temporary files Note that ocamlbuild and ocamlbuild.native are identical binaries. So as a workaround this is changed to make ocamlbuild a symlink to ocamlbuild.native and the rpmbuild succeeds.
This message is a reminder that Fedora 26 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '26'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 26 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 26 changed to end-of-life (EOL) status on 2018-05-29. Fedora 26 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.