Bug 479781 - gdb trips on "finish" command
gdb trips on "finish" command
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: gdb (Show other bugs)
rawhide
All Linux
low Severity medium
: ---
: ---
Assigned To: Jan Kratochvil
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-01-12 20:18 EST by Michal Jaegermann
Modified: 2009-02-09 07:36 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-02-09 07:36:10 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
backtrace from gdb (3.72 KB, text/plain)
2009-01-12 20:18 EST, Michal Jaegermann
no flags Details

  None (edit)
Description Michal Jaegermann 2009-01-12 20:18:44 EST
Created attachment 328811 [details]
backtrace from gdb

Description of problem:

gdb got confused in a debuggin session and after "finish" command informed me that further debugging will be "unreliable".  It offered to dump a core from an incident and a backtrace from it is attached.

It this is the same issue as bug 479381?  That was not clear to me

Version-Release number of selected component (if applicable):
gdb-6.8.50.20081214-1.fc11.x86_64

How reproducible:
no idea
Comment 1 Jan Kratochvil 2009-01-13 04:50:10 EST
No, this looks as an original bug report.

It comes from an inlining support which is not being imported upstream and being maintained separately, from:
http://sourceware.org/ml/gdb-patches/2008-07/msg00442.html

Shortly tried to reproduce it with no luck.  Do you have some testcase you could provide, please?
Comment 2 Michal Jaegermann 2009-01-13 12:28:02 EST
> Do you have some testcase you could provide, please?

I wish.  gdb dumped that on me while I was trying to do some walk through /usr/sbin/privoxy;  mostly to confirm that bug 479781 no longer applies and because I already had 'privoxy-debuginfo' on hands because of other, earlier, issues. While  stepping deeper in an inner "wait" loop, I guess in some static inlined function, I typed "fin" and got a notification from gdb that an "internal problem occured" and I may want to see a core.

I am not sure how to reproduce that but I have that core around if of any interest.

I may try more times if there is some (semi?) reliable way to reproduce but originally I did not get very far.
Comment 3 Michal Jaegermann 2009-01-13 20:23:17 EST
I think that I may have a repeatable test case.

In a directory with a copy of /usr/sbin/privoxy from privoxy-3.0.10-2.fc11.x86_64 and with privoxy-debuginfo-3.0.10-2.fc11
(actually after 'debuginfo-install privoxy' which installs other packages too) and with the following .gdbinit file:

dir /usr/src/debug/privoxy-3.0.10-stable/
set args --no-daemon /etc/privoxy/config
b main
b jcc.c:3457
b jcc.c:3434

After 'debuginfo-install gdb' and from emacs "gud" interface I see the following:
....
(gdb) c
Continuing.
Jan 13 17:43:19.546 Privoxy(7ffff7fdf6f0) Info: Privoxy version 3.0.10
Jan 13 17:43:19.546 Privoxy(7ffff7fdf6f0) Info: Program name: /var/tmp/privoxy/privoxy

Breakpoint 2, bind_port_helper (config=0x63cc10) at jcc.c:3457
(gdb) fin
Run till exit from #0  bind_port_helper (config=0x63cc10) at jcc.c:3457
../../gdb/breakpoint.c:4917: internal-error: set_momentary_breakpoint: Assertion `!frame_id_inlined_p (frame_id)' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n)

So far I repeated that three times and it looks like that "fin" from the second breakpoint does the job.

I am not sure if this detail that already another instance of privoxy, started from a boot sequence, is running is significant or not.
Comment 4 Jan Kratochvil 2009-02-09 07:36:10 EST
* Mon Feb  9 2009 Jan Kratochvil <jan.kratochvil@redhat.com> - 6.8.50.20081214-2
- Fix crash / implement `finish' into inlined functions (BZ 479781).

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