RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1750470 - gdb fails to set breakpoint on binary compiler from souce which is a symbolic link to a file with different name
Summary: gdb fails to set breakpoint on binary compiler from souce which is a symbolic...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: gdb
Version: 7.5
Hardware: All
OS: Linux
medium
high
Target Milestone: rc
: ---
Assignee: Keith Seitz
QA Contact: Michal Kolar
URL:
Whiteboard:
Depends On: 1639077
Blocks: 1771136 1771138 1771140 1771142
TreeView+ depends on / blocked
 
Reported: 2019-09-09 16:18 UTC by Paulo Andrade
Modified: 2023-12-15 16:45 UTC (History)
14 users (show)

Fixed In Version: gdb-7.6.1-119.el7
Doc Type: No Doc Update
Doc Text:
Clone Of: 1639077
: 1771136 1771138 1771140 1771142 (view as bug list)
Environment:
Last Closed: 2020-03-31 19:09:11 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2020:0993 0 None None None 2020-03-31 19:09:26 UTC

Description Paulo Andrade 2019-09-09 16:18:55 UTC 
+++ This bug was initially created as a clone of Bug #1639077 +++

Description of problem:
Setting break on a binary loaded in gdb, which has been compiled from a file which is a symbolic link to a file with different name throws below error:

(gdb) b 15
No line 15 in the current file.
Make breakpoint pending on future shared library load? (y or [n])

Pressing "y" at this point, before punching run command, has no effect and process exits through it normally. Instead specifying breakpoint in the format <file name>:<linenum> works as expected: 

(gdb) b bitmapS.c:15
Breakpoint 2 at 0x40088c: file bitmapS.c, line 15.


Version-Release number of selected component (if applicable):
gdb-7.6.1-110.el7

How reproducible:
Always

Steps to Reproduce:
1. move the attached reproducer program bitmapSort.c to /tmp
   # mv bitmapSort.c /tmp
2. Create a symbolic link to /tmp/bitmapSort.c with a different name
   # cd
   # ln -s /tmp/bitmapSort.c bitmapS.c
3. Compile bitmapS.c to produce a binary and load in gdb and try to set breakpoint specifying just line number: 
   # gcc -o bitmapS -lm -g bitmapS.c
   # gdb ./bitmapS
   (gdb) b 15

Actual results:
Breakpoint is not set just with <linenum> format, whereas setting breakpoing in <filename>:<linume> does work as expected.

Expected results:
Breakpoint with just <linenum> format should work.

Additional info:
Same was working fine in RHEL-6.

--- Additional comment from Divya on 2018-10-15 02:37:08 UTC ---

I am marking this regression because it is working on RHEL-6
Comment 3 Paulo Andrade 2019-09-09 16:22:34 UTC 
Cannot reopen the previous bug report, but the problem is
not corrected.

With gdb 7.6.1-114:

(gdb) b 15
No line 15 in the current file.
Make breakpoint pending on future shared library load? (y or [n])

With gdb 7.6.1-115:

(gdb) b 15
Breakpoint 1 at 0x4007dc: file bitmapSort.c, line 15.
(gdb) r
Starting program: /home/pcpa/bitmapSort 
Error in re-setting breakpoint 1: No source file named /home/pcpa/tmp/12345.

But as you can see, when actually reaching the breakpoint, it misbehaves.

The problem also happens at least on Fedora 30.
Comment 6 Keith Seitz 2019-09-19 17:48:21 UTC 
Moving to 7.9.
Comment 8 David Smith 2019-09-23 14:23:13 UTC 
This upstream regression, while a regression, isn't important enough to be a blocker. Moving out to 7.9.
Comment 18 Keith Seitz 2019-11-11 18:15:21 UTC 
QE: Use test case in DESCRIPTION.

BEFORE (-116.el7):
$ gdb -q bitmapS
Reading symbols from /home/rhel7/rhbz/1750470/bitmapS...done.
(gdb) b 15
Breakpoint 1 at 0x4007ec: file bitmapS.c, line 15.
(gdb) r
Starting program: /home/rhel7/rhbz/1750470/bitmapS 
Error in re-setting breakpoint 1: No source file named /home/rhel7/rhbz/1750470/tmp/bitmapSort.c.
Made 26019726 comparisons, 8500000 assignments, 17000000 file writes, and 0 file reads
[Inferior 1 (process 3473) exited normally]
(gdb) 

AFTER (-117.el7):
$ gdb -q bitmapS
Reading symbols from /home/rhel7/rhbz/1750470/bitmapS...done.
(gdb) b 15
Breakpoint 1 at 0x4007ec: file bitmapS.c, line 15.
(gdb) r
Starting program: /home/rhel7/rhbz/1750470/bitmapS 

Breakpoint 1, main (argc=1, argv=0x7fffffffe038) at bitmapS.c:20
20		int             filewrites = 0;
(gdb)
Comment 21 Keith Seitz 2019-11-13 17:45:13 UTC 
I am going to need a new test cases for this. The one provided in the description is no longer sufficient.
Comment 22 Paulo Andrade 2019-11-18 12:29:44 UTC 
  Updated testcase:

  Basically execute 'list' twice:

$ gdb bitmapS
...
(gdb) list
...
(gdb) list
...
(gdb) run
...
Error in re-setting breakpoint 1: No source file named /tmp/bitmapSort.c.
...

  The 'list' command causes it again to fail.
Comment 23 Paulo Andrade 2019-11-18 12:30:58 UTC 
Ops, cut&paste problem, it is:

(gdb) list
(gdb) list
(gdb) b 15
(gdb) run

to reproduce the regression.
Comment 32 Paulo Andrade 2019-12-02 19:25:32 UTC 
  There is still a problem.

  Reproducer:

$ mkdir foo,bar
$ cp bitmapSort.c foo,bar
$ gcc -O0 -g3 $PWD/foo,bar/bitmapSort.c -o bitmapS -lm
$ gdb bitmapS
(gdb) b 15
Breakpoint 1 at 0x4007ec: file .../foo,bar/bitmapSort.c, line 15.
(gdb) r
Starting program: .../bitmapS 
Error in re-setting breakpoint 1: Function ".../foo" not defined.
Made 26018941 comparisons, 8500000 assignments, 17000000 file writes, and 0 file reads
[Inferior 1 (process 2413) exited normally]

  Now they have a workaround with symbolic links, but previously commas
in paths did work.
Comment 33 Keith Seitz 2019-12-03 14:22:25 UTC 
(In reply to Paulo Andrade from comment #32)
> $ mkdir foo,bar
> $ cp bitmapSort.c foo,bar
> $ gcc -O0 -g3 $PWD/foo,bar/bitmapSort.c -o bitmapS -lm
> $ gdb bitmapS
> (gdb) b 15
> Breakpoint 1 at 0x4007ec: file .../foo,bar/bitmapSort.c, line 15.
> (gdb) r
> Starting program: .../bitmapS 
> Error in re-setting breakpoint 1: Function ".../foo" not defined.
> Made 26018941 comparisons, 8500000 assignments, 17000000 file writes, and 0
> file reads
> [Inferior 1 (process 2413) exited normally]

This is a new bug. If this must be fixed in gdb-7.6, please file a new bug
for it.

I have to ask, though: Why is DTS not an option?

That debugger is significantly newer than this RHEL 7 version, providing
much more maturity and new features.

>   Now they have a workaround with symbolic links, but previously commas
> in paths did work.

Because of 1777914, I've had to revert this patch. A team member has updated
tests for this bug, included in the -119 build, and he recommends using
"set basenames-may-differ on" option to resolve this original bug. [This
flag should also be set with the DTS gdb.]
Comment 34 Paulo Andrade 2019-12-03 15:00:54 UTC 
  Previously (around the time the original bug report was opened) the user
tested devtoolset-7, and it did fail. Testing latest devtoolset-7 and the
problem still exist.
  User has been previously asked to test devtoolset-8, and has been asked
again, as latest devtoolset-8 works.
Comment 35 Keith Seitz 2019-12-03 15:27:48 UTC 
I see what's happened. I apologize: I'm testing DTS9 which has not yet
been released. Very sorry about that.

For the symlink bug, "set basenames-may-differ on" will need to be used for every
shipping version of GDB (RHEL 7+ and DTS 8+).

To be absolutely clear, does turning on  basenames-may-differ resolve
the customer's symlink issues?

I have tested the reported symlink test cases on
the (proposed) -119 build, DTS7.1, DTS8, and DTS9. All versions work with
"set basenames-may-differ on".

The reported comma-in-pathname problem (now 1779246) works on DTS8 and DTS9.
Only the RHEL7 system GDB fails this case. [But we'll move further discussion
about this problem to that bug.]
Comment 37 Michal Kolar 2019-12-06 13:33:36 UTC 
Verified against gdb-7.6.1-119.el7.
Comment 39 errata-xmlrpc 2020-03-31 19:09:11 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2020:0993
Note You need to log in before you can comment on or make changes to this bug.