Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1694091 - gdb-8.3.50.20190321-3.fc31.x86_64: crashing
Summary: gdb-8.3.50.20190321-3.fc31.x86_64: crashing
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: gdb
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Sergio Durigan Junior
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-03-29 13:46 UTC by Tomasz Kłoczko
Modified: 2019-04-01 21:05 UTC (History)
5 users (show)

Fixed In Version: gdb-8.3.50.20190321-4.fc31
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-04-01 21:05:24 UTC


Attachments (Terms of Use)
gdb core (deleted)
2019-03-29 15:32 UTC, Tomasz Kłoczko
no flags Details
Fix of a crash regression by: 96770ac25f2074e0ce0df2f58c938cbf69a2a50e (deleted)
2019-03-29 17:16 UTC, Jan Kratochvil
no flags Details | Diff

Description Tomasz Kłoczko 2019-03-29 13:46:36 UTC
gdb-8.3.50.20190321-3.fc31.x86_64
back trace generated using lldb:

* thread #1, name = 'gdb', stop reason = signal SIGSEGV
  * frame #0: 0x00007f17fd394eee libc.so.6`__strcmp_sse2_unaligned + 30
    frame #1: 0x00005606debc749d gdb`missing_rpm_list_compar(char const*, char const*) at build-id.c:1038:18
    frame #2: 0x00005606debca10f gdb`.annobin__ZSt16__introsort_loopIN9__gnu_cxx17__normal_iteratorIPPKcSt6vectorIS3_SaIS3_EEEElNS0_5__ops15_Iter_comp_iterIPFbS3_S3_EEE
EvT_SE_T0_T1_.start at predefined_ops.h:143:23
    frame #3: 0x00005606debc9ae7 gdb`missing_rpm_list_print() at stl_algo.h:1957:25
    frame #4: 0x00005606dec9c4b2 gdb`display_gdb_prompt(char const*) at event-top.c:363:23
    frame #5: 0x00005606ded38c55 gdb`captured_command_loop() at main.c:329:29
    frame #6: 0x00005606ded3a32d gdb`gdb_main(captured_main_args*) at main.c:1266:30
    frame #7: 0x00005606deb3298f gdb`.annobin_main.start at gdb.c:40:19
    frame #8: 0x00007f17fd326f73 libc.so.6`.annobin_libc_start.c + 243
    frame #9: 0x00005606deb36fce gdb`_start + 46

If it you want I can attach compressed core file.

Comment 1 Sergio Durigan Junior 2019-03-29 13:51:49 UTC
Thanks.  I'm interested to know how to reproduce this issue.  It's not the first time I see it.  Thanks.

Comment 2 Tomasz Kłoczko 2019-03-29 14:16:40 UTC
GDB crashes on loading core generated when I've been trying to investigate issue with gnome-shell running with 
glib build with -DG_DISABLE_CHECKS -DG_DISABLE_ASSERT.
So if you want fully reproduce that case first you need to install glib with added "-DG_DISABLE_CHECKS -DG_DISABLE_ASSERT".
However to compile such glib is not easy because only recently I've pointed gliub developers that they are not checking over CI glib build with those defines (next glib release will hopefully clean from that angle).
You can find more details about that in already sorted out glib ticket https://gitlab.gnome.org/GNOME/glib/issues/1708

Comment 3 Sergio Durigan Junior 2019-03-29 15:27:54 UTC
If you provide the corefile you've been trying to examine, maybe I can reproduce the problem without having to compile glib.  Otherwise, I will need some help (in other words, instructions) on how to do that.

Comment 4 Tomasz Kłoczko 2019-03-29 15:32:20 UTC
Created attachment 1549482 [details]
gdb core

Comment 5 Tomasz Kłoczko 2019-03-29 15:34:24 UTC
Cannot second compressed core which is causing gdb crash because it is bigger than 18MB limit :/

Comment 6 Sergio Durigan Junior 2019-03-29 15:38:09 UTC
(In reply to Tomasz Kłoczko from comment #5)
> Cannot second compressed core which is causing gdb crash because it is
> bigger than 18MB limit :/

I need the core that is causing GDB to crash.  Please use either fedorapeople.org or https://framadrop.org/, where you can upload bigger files.  Thanks.

Comment 7 Tomasz Kłoczko 2019-03-29 15:43:21 UTC
https://framadrop.org/r/3XurYqJ3DJ#VPlBdPQh3j3xpNrxtyqL+pt5XskQygUJFMGUXcyx/nc=

I think that if you will try to use that core I would be not surprised if it will not fail.
Looking on bt output I think that it could be something whad gdb received from rpm database query.

Comment 8 Sergio Durigan Junior 2019-03-29 17:09:54 UTC
(In reply to Tomasz Kłoczko from comment #7)
> https://framadrop.org/r/3XurYqJ3DJ#VPlBdPQh3j3xpNrxtyqL+pt5XskQygUJFMGUXcyx/
> nc=
> 
> I think that if you will try to use that core I would be not surprised if it
> will not fail.
> Looking on bt output I think that it could be something whad gdb received
> from rpm database query.

Well, it was worth a try...  I wasn't able to reproduce it here.

Are you still able to reproduce the bug?  Can you give me instructions on how to compile glib and try to reproduce it here?  Thanks.

Comment 9 Jan Kratochvil 2019-03-29 17:16:32 UTC
Created attachment 1549556 [details]
Fix of a crash regression by: 96770ac25f2074e0ce0df2f58c938cbf69a2a50e

Comment 10 Sergio Durigan Junior 2019-03-29 17:21:07 UTC
(In reply to Jan Kratochvil from comment #9)
> Created attachment 1549556 [details]
> Fix of a crash regression by: 96770ac25f2074e0ce0df2f58c938cbf69a2a50e

I have the same patch ready to be pushed here, but I don't understand how it fixes a segmentation fault.  I'd like to be able to reproduce this first.  Were you able to create a reproducer?  Thanks.

Comment 11 Jan Kratochvil 2019-03-29 17:31:41 UTC
GDB is just crashing for me with the core file from Comment 4, I haven't investigated it more.

The buggy comparison function was violating:
  https://en.cppreference.com/w/cpp/algorithm/sort
  "returns ​true if the first argument is less than (i.e. is ordered before) the second"
in a way which violated
  https://en.wikipedia.org/wiki/Asymmetric_relation
which can apparently lead to a crash of std::sort but I agree I also did not expect a crash due to it myself.
Another possibility is that std::sort crash due to violation of valid states of 'bool' type (which is only 0==false and 1==true), one could find that out by -fsanitize=undefined.

Comment 12 Sergio Durigan Junior 2019-03-29 17:37:07 UTC
(In reply to Jan Kratochvil from comment #11)
> GDB is just crashing for me with the core file from Comment 4, I haven't
> investigated it more.

I can't make GDB crash with that corefile.  I guess I might have extra debuginfo installed here, which doesn't trigger the bug.

> The buggy comparison function was violating:
>   https://en.cppreference.com/w/cpp/algorithm/sort
>   "returns ​true if the first argument is less than (i.e. is ordered before)
> the second"
> in a way which violated
>   https://en.wikipedia.org/wiki/Asymmetric_relation

Yes, I noticed that while investigating this bug as well.  As I said, I had the patch ready here, but after doing some tests I could not see a crash when I don't use "< 0".

> which can apparently lead to a crash of std::sort but I agree I also did not
> expect a crash due to it myself.
> Another possibility is that std::sort crash due to violation of valid states
> of 'bool' type (which is only 0==false and 1==true), one could find that out
> by -fsanitize=undefined.

Fair enough.

Tomasz, are you still able to reproduce the crash?  If yes, can I provide you a scratch build of GDB for you to test?  Thanks.

Comment 13 Jan Kratochvil 2019-03-29 17:50:53 UTC
(In reply to Sergio Durigan Junior from comment #12)
> I can't make GDB crash with that corefile.  I guess I might have extra
> debuginfo installed here, which doesn't trigger the bug.

FYI my array is:
$1 = std::__debug::vector of length 28, capacity 28 = {"elfutils-libs-0.176-1.fc30.x86_64", "lua-libs-5.3.5-5.fc30.x86_64", "libacl-2.2.53-3.fc30.x86_64", "libcap-2.26-5.fc30.x86_64", "rpm-libs-4.14.2.1-4.fc30.1.x86_64", "libicu-63.1-2.fc30.x86_64", "pcre-8.43-1.fc31.x86_64", "bzip2-libs-1.0.6-29.fc30.x86_64", "boost-regex-1.69.0-6.fc30.x86_64", "gmp-6.1.2-10.fc31.x86_64", "glib2-2.60.0-3.fc31.x86_64", "libuuid-2.33.1-4.fc31.x86_64", "popt-1.16-17.fc30.x86_64", "elfutils-libelf-0.176-1.fc30.x86_64", "libdb-5.3.28-37.fc30.x86_64", "pcre2-10.33-0.4.RC1.fc31.x86_64", "libgcc-9.0.1-0.11.fc31.x86_64", "libstdc++-9.0.1-0.11.fc31.x86_64", "source-highlight-3.1.8-24.fc31.x86_64", "libbabeltrace-1.5.6-2.fc30.x86_64", "xz-libs-5.2.4-5.fc30.x86_64", "expat-2.2.6-2.fc30.x86_64", "python3-libs-3.7.2-8.fc31.x86_64", "glibc-2.29.9000-8.fc31.x86_64", "ncurses-libs-6.1-10.20180923.fc30.x86_64", "libselinux-2.9-1.fc31.x86_64", "zlib-1.2.11-15.fc30.x86_64", "readline-8.0-2.fc30.x86_64"}

Error: attempt to dereference a past-the-end iterator.

Comment 14 Tomasz Kłoczko 2019-03-29 18:26:28 UTC
(In reply to Sergio Durigan Junior from comment #8)
> (In reply to Tomasz Kłoczko from comment #7)
> > https://framadrop.org/r/3XurYqJ3DJ#VPlBdPQh3j3xpNrxtyqL+pt5XskQygUJFMGUXcyx/
> > nc=
> > 
> > I think that if you will try to use that core I would be not surprised if it
> > will not fail.
> > Looking on bt output I think that it could be something whad gdb received
> > from rpm database query.
> 
> Well, it was worth a try...  I wasn't able to reproduce it here.
> 
> Are you still able to reproduce the bug?  Can you give me instructions on
> how to compile glib and try to reproduce it here?  Thanks.

I can try to swap glib in next few hours and try to do logout/login over GUI.

Comment 15 Sergio Durigan Junior 2019-03-29 18:31:11 UTC
Please give this a try: https://koji.fedoraproject.org/koji/taskinfo?taskID=33817201

It's a scratch build containing what we think is the fix for the problem.

Comment 16 Sergio Durigan Junior 2019-04-01 21:02:43 UTC
I'll push the changes now, and close this bug, since (AFAIU) Jan has confirmed that the patch fixes the bug.  Tomasz, feel free to reopen this bug if you're still experiencing the problem.

Comment 17 Tomasz Kłoczko 2019-04-01 21:04:19 UTC
Really sorry but I had no time to do more gdb tests :(

Comment 18 Sergio Durigan Junior 2019-04-01 21:05:09 UTC
(In reply to Tomasz Kłoczko from comment #17)
> Really sorry but I had no time to do more gdb tests :(

That's OK.  When (and if) you have time, please update this bug with your findings.  Thanks.


Note You need to log in before you can comment on or make changes to this bug.