Program received signal SIGSEGV, Segmentation fault.
dwarf_diecu (die=0x7fffffffd540, result=0x7fffffffd560, address_sizep=0x0, offset_sizep=0x0) at libdwP.h:947
Downloading source file /usr/src/debug/elfutils-0.182-1.fc33.x86_64/libdw/libdwP.h...
947	  return cu->sec_idx;
This one is from /lib64/libclang.so.11 also from clang-libs-11.0.0-2.fc33.x86_64

Even though the backtrace is different at level 0 and 1, #2 is the same.

#0  dwarf_diecu (die=0x7fffffffd540, result=0x7fffffffd560, address_sizep=0x0, offset_sizep=0x0) at libdwP.h:947
#1  0x00007ffff7ef1e74 in abigail::dwarf_reader::imported_unit_point::imported_unit_point (from=4294956352, imported_die=..., import_off=<optimized out>, this=0x7fffffffd580) at ../../../libabigail/src/abg-dwarf-reader.cc:271
#2  abigail::dwarf_reader::read_context::build_die_parent_relations_under (this=0x442c40, die=0x7fffffffd650, source=abigail::dwarf_reader::PRIMARY_DEBUG_INFO_DIE_SOURCE, imported_units=std::vector of length 0, capacity 0) at ../../../libabigail/src/abg-dwarf-reader.cc:7686
#3  0x00007ffff7ef22ab in abigail::dwarf_reader::read_context::build_die_parent_maps (this=this@entry=0x442c40) at ../../../libabigail/src/abg-dwarf-reader.cc:7819
#4  0x00007ffff7ee4d57 in abigail::dwarf_reader::read_debug_info_into_corpus (ctxt=...) at ../../../libabigail/src/abg-dwarf-reader.cc:15895
#5  abigail::dwarf_reader::read_corpus_from_elf (ctxt=..., status=@0x7fffffffd80c: abigail::dwarf_reader::STATUS_UNKNOWN) at ../../../libabigail/src/abg-dwarf-reader.cc:17149
#6  0x0000000000405c93 in load_corpus_and_write_abixml (opts=..., context=std::shared_ptr<abigail::dwarf_reader::read_context> (use count 1, weak count 0) = {...}, env=std::shared_ptr<abigail::ir::environment> (use count 1, weak count 0) = {...}, argv=0x7fffffffdd58) at ../../../libabigail/tools/abidw.cc:494
#7  main (argc=<optimized out>, argv=0x7fffffffdd58) at ../../../libabigail/tools/abidw.cc:866

This continues to reproduce with commit a488f9b4

This continues to reproduce as of commit b0f6b8e on dodji/PR26769 for both libclang-cpp.so and libclang.so.11

Hello,

So clang and mozilla in particular have binaries that are so huge that I think they'll need some very specific work for libabigail to handle them.  For instance, just dumping the debug info of the libclang-cpp.so yields a file of more than 20GB.  That is insane.  Just analyzing that in the current mode of operation takes an herculean machine, at least.

I'll defer that work for later when we have more bandwidth, not because I don't like clang, but because I think we can be helpful to many many many more projects of realistic size in a shorter period of time.

Trying to read the binary however should not crash.  So I'll look at it somewhat, but I won't be able to spend a lot of time on it for now.  I just wanted to let you know about this.  I believe there is a bug opened for the support of clang binaries (huge huge quasi pathological c++ binaries really), if I am not mistaken.  If not, I think we should open one.

Okay, it turned out this wasn't that difficult to handle after all :-)

This should be fixed by patch https://sourceware.org/git/?p=libabigail.git;a=commit;h=2417efb2b7619ed2a2bd089d267833ee9d171eea, applied to the master branch.

Note that just doing abidw --noout on the libclang-cpp.so binary takes 19 minutes and 11GB of RAM to complete.  The full abidw --abidiff takes 5 hours to complete on a power7 box here.  As I said in my comment earlier, it would take a separate "project" to bring those numbers down for binaries with such a *huge* ABI surface as clang and the likes.

Thanks for reporting this issue!