[Bug default/26315] New: abidiff segfaults from 9a113ce but works in 1.7

[Bug default/26315] New: abidiff segfaults from 9a113ce but works in 1.7

[sourceware at sgoth dot de]

https://sourceware.org/bugzilla/show_bug.cgi?id=26315

            Bug ID: 26315
           Summary: abidiff segfaults from 9a113ce but works in 1.7
           Product: libabigail
           Version: unspecified
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: default
          Assignee: dodji at redhat dot com
          Reporter: sourceware at sgoth dot de
                CC: libabigail at sourceware dot org
  Target Milestone: ---

Created attachment 12730
  --> https://sourceware.org/bugzilla/attachment.cgi?id=12730&action=edit
backtrace

calling abidiff on a propriertary library crashes for me when called with:

abidiff libold.so libnew.so --hd1 /old/includes --hd2 /new/includes
--leaf-changes-only --impacted-interfaces --drop-private-types

There is no output printed but 'Segmentation fault'.

See full backtrace attached.

Running it through `git bisect run` blames
9a113ce77139d5b0fd55e0f554d930b38e0a856a

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug default/26315] abidiff segfaults from 9a113ce but works in 1.7

[gprocida+abigail at google dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=26315

Giuliano Procida <gprocida+abigail at google dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |gprocida+abigail at google dot com

--- Comment #1 from Giuliano Procida <gprocida+abigail at google dot com> ---
Please confirm which libabigail version the stack backtrace corresponds to.
Thanks!

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug default/26315] abidiff segfaults from 9a113ce but works in 1.7

[gprocida+abigail at google dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=26315

--- Comment #2 from Giuliano Procida <gprocida+abigail at google dot com> ---
Based on IRC, it sounds like it was current master.
fd8640dc09b99bee11745a4d5b176b2dee3400f4

Another question, does your source contain any forward-declared enums?

(approximately) grep -w 'enum *[A-Za-z0-9_]*;'

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug default/26315] abidiff segfaults from 9a113ce but works in 1.7

[sourceware at sgoth dot de]

https://sourceware.org/bugzilla/show_bug.cgi?id=26315

--- Comment #3 from Sebastian Goth <sourceware at sgoth dot de> ---
Yes, you deduced the correct commit for the stacktrace :)

And yes, there is a single 'enum class Foo;' in the public API.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug default/26315] abidiff segfaults from 9a113ce but works in 1.7

[sourceware at sgoth dot de]

https://sourceware.org/bugzilla/show_bug.cgi?id=26315

--- Comment #4 from Sebastian Goth <sourceware at sgoth dot de> ---
Regarding the forward declared enum:

The layout is:

A.h:
```
enum class Foobar;
```

Abstract.h:
```
#include "A.h"
enum class Foobar {
  A, B, C;
};

class Abstract {

public:
   void pure() = 0;
   Foobar somefunc();
private:
   Foobar member;
};
```

All that is contained in the library.
But there is no implementation of Abstract inside the lib!

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug default/26315] abidiff segfaults from 9a113ce but works in 1.7

[dodji at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=26315

dodji at redhat dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2020-09-10
             Status|UNCONFIRMED                 |WAITING
     Ever confirmed|0                           |1

--- Comment #5 from dodji at redhat dot com ---
Thank you for reporting this issue, and sorry for the inconvenience.

Looking at the backtrace it looks like libabigail the segmentation fault is
happening on this line:

··if·(*l.get_underlying_type()·!=·*r.get_underlying_type())$  


basically, l and r are typdef types.  Normally, {l,r}.get_underlying_type() can
never be NULL, because typedef always have underlying types.

So I am not sure what is happening there.  It would be really helpful if I
could look at the binary itself to see what is happening, but I guess that is
not possible, is it?

Just for the record, the git hash I am looking at is this one:
fd8640dc09b99bee11745a4d5b176b2dee3400f4

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug default/26315] abidiff segfaults from 9a113ce but works in 1.7

[sourceware at sgoth dot de]

https://sourceware.org/bugzilla/show_bug.cgi?id=26315

--- Comment #6 from Sebastian Goth <sourceware at sgoth dot de> ---
Hey. Sorry for the late reply but vacation happened.

Sadly i can't attach the binary here but I'd be happy to help debug it. My
attempts to create a test case failed so far..

A bit more info:

- still happens in current master ( ebaf3305 )
- is unrelated to any actual change, comparing the same bins/includes crashes
- only crashes if called with '--drop-private-types'


$ ./bin/abidiff /path/to/lib.so /path/to/lib.so --hd1 /path/to/hdr --hd2
/path/to/hdr
$ ./bin/abidiff --drop-private-types /path/to/lib.so /path/to/lib.so --hd1
/path/to/hdr --hd2 /path/to/hdr
Segmentation fault (core dumped)

at same location:

#0  abigail::ir::equals (l=..., r=..., k=0x0) at ../../src/abg-ir.cc:15819
#1  0x00007ffff7c456d9 in
abigail::ir::try_canonical_compare<abigail::ir::typedef_decl>
(l=0x555557a18710, r=0x555555e1d8b0) at ../../src/abg-ir.cc:670
#2  0x00007ffff7c0efc6 in abigail::ir::typedef_decl::operator==
(this=0x555557a18710, o=...) at ../../src/abg-ir.cc:15842
#3  0x00007ffff7c0f041 in abigail::ir::typedef_decl::operator==
(this=0x555557a18710, o=...) at ../../src/abg-ir.cc:15857
#4  0x00007ffff7be9204 in abigail::ir::operator==
(l=std::shared_ptr<abigail::ir::type_base> (use count 4, weak count 11) =
{...}, r=std::shared_ptr<abigail::ir::type_base> (use count 9, weak count 10) =
{...}) at ../../src/abg-ir.cc:4322
#5  0x00007ffff7c0114c in abigail::ir::type_base::get_canonical_type_for
(t=std::shared_ptr<abigail::ir::type_base> (use count 9, weak count 10) =
{...}) at ../../src/abg-ir.cc:12178
#6  0x00007ffff7c01808 in abigail::ir::canonicalize
(t=std::shared_ptr<abigail::ir::type_base> (use count 9, weak count 10) =
{...}) at ../../src/abg-ir.cc:12301
#7  0x00007ffff7dfa1b1 in
abigail::dwarf_reader::read_context::canonicalize_types_scheduled
(this=0x555565bc2f50,
source=abigail::dwarf_reader::PRIMARY_DEBUG_INFO_DIE_SOURCE) at
../../src/abg-dwarf-reader.cc:4833
#8  0x00007ffff7dfa9b6 in
abigail::dwarf_reader::read_context::perform_late_type_canonicalizing
(this=0x555565bc2f50) at ../../src/abg-dwarf-reader.cc:4949
#9  0x00007ffff7deb4c7 in abigail::dwarf_reader::read_debug_info_into_corpus
(ctxt=...) at ../../src/abg-dwarf-reader.cc:16024
#10 0x00007ffff7df00f6 in abigail::dwarf_reader::read_corpus_from_elf
(ctxt=..., status=@0x7fffffffd05c: abigail::dwarf_reader::STATUS_UNKNOWN) at
../../src/abg-dwarf-reader.cc:17149
#11 0x0000555555559c15 in main (argc=<optimized out>, argv=0x7fffffffd488) at
/usr/include/c++/10.2.0/bits/shared_ptr_base.h:1324

-- 
You are receiving this mail because:
You are on the CC list for the bug.