Bug 9583 - -break-insert failed when several source files have the same name
Summary: -break-insert failed when several source files have the same name
Status: RESOLVED FIXED
Alias: None
Product: gdb
Classification: Unclassified
Component: mi (show other bugs)
Version: 6.8
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-07-20 11:18 UTC by seb.sfo
Modified: 2009-12-03 07:04 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments
multiple_breakpoint_bug.log (3.90 KB, application/octet-stream)
, seb.sfo
Details
A fix for this bug (439 bytes, patch)
2009-03-02 21:28 UTC, seb.sfo
Details | Diff
A updated fix (874 bytes, patch)
2009-10-01 20:52 UTC, seb.sfo
Details | Diff
updated fix (1.01 KB, patch)
2009-10-02 20:57 UTC, seb.sfo
Details | Diff
Updated fix (1.54 KB, patch)
2009-10-29 21:56 UTC, seb.sfo
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description seb.sfo 2008-07-20 11:18:01 UTC
[Converted from Gnats 2478]

It seems that since the last changes done to support multiple breakpoints, setting breakpoints doesn't work when several files in the program have the same name.

This was working fine with gdb 6.6.

I get this in Anjuta (http://bugzilla.gnome.org/show_bug.cgi?id=541362) which is using the mi2 interface while debugging Anjuta itself.

I have attached a log of all communications between Anjuta and gdb. It's not very easy to read, so here is some explanations:

* line 10: insert on breakpoint at /home/seb/Programmation/Anjuta/anjuta/plugins/language-support-cpp-java/plugin.c:1695
I have used the switch -f just to check. Normally Anjuta doesn't use it currently. 

* line 14: insert on breakpoint at /home/seb/Programmation/Anjuta/anjuta/plugins/debug-manager/plugin.c:232
So, there are two breakpoints in 2 different files named plugin.c but in different directory.

* line30: There are a lots of stop on shared library events, because a big part of Anjuta is put in plugins which are loaded dynamically. I'm using these stops to try to put pending breakpoint in older version of gdb.

* line 454: The debugger stops due to a breakpoint, but it is reported to be at /home/seb/Programmation/Anjuta/a    njuta/plugins/tools/plugin.c:232 where I have never set any breakpoint.

* line 462: The list of breakpoints show something quite strange, the breakpoint 2, initially set on home/seb/Programmation/Anjuta/anjuta/plugins/debug-manager/plugin.c:232
has loosed its file name and it reported as a multiple breakpoint ("addr="<MULTIPLE>"), while it's a normal breakpoint in a C source file. 
Without using the -f switch with -break-insert, when the breakpoint can really be set, I get a similar report: the breakpoint is reported as a multiple breakpoint.

Do you need more informations ?

Release:
gdb 6.8

Environment:
linux
Comment 1 Nick Roberts 2009-01-18 10:18:56 UTC
I think the breakpoint at plugin.c:1695 might be a red herring.  The second
breakpoint looks like it *is*/gets converted to a multiple breakpoint.

The output to -break-list is known to be broken for multiple breakpoints.
What do you get if you type "info break" (assuming Anjuta has a console)
before/after hitting the breakpoint?

It should show where Gdb thinks thosebreakpoints are.

Comment 2 seb.sfo 2009-01-18 11:15:22 UTC
(In reply to comment #1)
> The output to -break-list is known to be broken for multiple breakpoints.
> What do you get if you type "info break" (assuming Anjuta has a console)
> before/after hitting the breakpoint?

I cannot get exactly the same things so I have put a breakpoint at
plugins/debug-manager/plugin.c:232 and
plugins/language-support-cpp-java/plugin.c:1648

And with gdb 6.8 I get a break in plugins/language-manager/plugin.c:232

info break gives the following output:
info break
Num     Type           Disp Enb Address    What
1       breakpoint     keep y   <MULTIPLE> 0xb5203453
	breakpoint already hit 1 time
1.1                         y     0xb5203453 in ilanguage_get_from_mime_type at
plugin.c:232
1.2                         y     0xb4f880ca in deactivate_plugin at plugin.c:232
1.3                         y     0xb45f2447 in value_added_fm_current_file at
plugin.c:232
done

The second breakpoints have been set in several files which is wrong. The
breakpoint 1.1 is in plugins/language-manager/plugin.c:232, the breakpoint 1.2
is in plugins/message-view/plugin.c:232, the breakpoint 1.3 is in
plugins/subversion/plugin.c:232
Comment 3 Nick Roberts 2009-01-18 19:13:19 UTC
Subject: Re:  -break-insert failed when several source files have the same name

 > I cannot get exactly the same things so I have put a breakpoint at
 > plugins/debug-manager/plugin.c:232 and
 > plugins/language-support-cpp-java/plugin.c:1648
 > 
 > And with gdb 6.8 I get a break in plugins/language-manager/plugin.c:232
 > 
 > info break gives the following output:

Several things surprise me about this output:

1) The breakpoint locations are from different files (I guess we already knew
   that).

2) The file plugins/language-manager/plugin.c isn't one of those files.

 > info break
 > Num     Type           Disp Enb Address    What
 > 1       breakpoint     keep y   <MULTIPLE> 0xb5203453
                                              ^^^^^^^^^^
3) The hexaecimal address on the above line.  This is the only line that
-break-list outputs and in your earlier log it looks like:

bkpt={number="2",type="breakpoint",disp="keep",enabled="y",addr="<MULTIPLE>",addr="0xb56f97dd",times="1"}

and the addr field is duplicated.

I don't see how this can happen in the gdb code.  Are you sure this is vanilla
gdb?

What does "show version" say? e.g for me: GNU gdb (GDB) 6.8.50.20090116-cvs

 > 	breakpoint already hit 1 time
 > 1.1                         y     0xb5203453 in ilanguage_get_from_mime_type at
 > plugin.c:232
 > 1.2                         y     0xb4f880ca in deactivate_plugin at plugin.c:232
 > 1.3                         y     0xb45f2447 in value_added_fm_current_file at
 > plugin.c:232
 > done
 > 
 > The second breakpoints have been set in several files which is wrong. The
 > breakpoint 1.1 is in plugins/language-manager/plugin.c:232, the breakpoint 1.2
 > is in plugins/message-view/plugin.c:232, the breakpoint 1.3 is in
 > plugins/subversion/plugin.c:232

Is it possible to set a breakpoint after plugins/language-manager/plugin.c:232
has loaded and and do "info break" to see if this results in a normal
breakpoint at the rght place?

Comment 4 seb.sfo 2009-01-18 21:48:52 UTC
(In reply to comment #3)
> 1) The breakpoint locations are from different files (I guess we already knew
>    that).

Yes, for me it looks like that gdb put a breakpoint in each file named plugin.c
without taking care of the file path. 

> 2) The file plugins/language-manager/plugin.c isn't one of those files.
> 
>  > info break
>  > Num     Type           Disp Enb Address    What
>  > 1       breakpoint     keep y   <MULTIPLE> 0xb5203453
>                                               ^^^^^^^^^^

I don't see a problem here, this is breakpoint 1.1 in info break output. As, I
have said, I haven't put the breakpoint in exactly the same program so the
breakpoints addresses are a bit different comparing to my first log.

> 3) The hexaecimal address on the above line.  This is the only line that
> -break-list outputs and in your earlier log it looks like
> and the addr field is duplicated.

For this program the output of -break-list is

-break-list
done,BreakpointTable={nr_rows="1",nr_cols="6",hdr=[{width="7",alignment="-1",col_name="number",colhdr="Num"},{width="14",alignment="-1",col_name="type",colhdr="Type"},{width="4",alignment="-1",col_name="disp",colhdr="Disp"},{width="3",alignment="-1",col_name="enabled",colhdr="Enb"},{width="10",alignment="-1",col_name="addr",colhdr="Address"},{width="40",alignment="2",col_name="what",colhdr="What"}],body=[bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="<MULTIPLE>",addr="0xb5203453",times="1"}]}

It looks quite similar with 2 address field too.

> I don't see how this can happen in the gdb code.  Are you sure this is vanilla
> gdb?

I'm quite sure, I have compiled it from the gdb-6.8.tar.bz2. The last entry in
the ChangeLog file is:

2008-03-27  Joel Brobecker  <brobecker@adacore.com>

        * NEWS: Replace "Changes since GDB 6.7" into changes in GDB 6.8".

> What does "show version" say? e.g for me: GNU gdb (GDB) 6.8.50.20090116-cvs

GNU gdb 6.8
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu".

> Is it possible to set a breakpoint after plugins/language-manager/plugin.c:232
> has loaded and and do "info break" to see if this results in a normal
> breakpoint at the rght place?

It's not very easy to do but I will do it if you think that it's useful.

I have tried to continue after the first break too see if gdb put others
breakpoints. It was a bit difficult to do because the first breakpoints is hit a
lots of time. So at the end, I have disabled it and stop the program when all
plugins have been loaded. I get the following result for info break

info break
Num     Type           Disp Enb Address    What
1       breakpoint     keep y   <MULTIPLE> 0xb5206453
	breakpoint already hit 333 times
1.1                         y     0xb5206453 in ilanguage_get_from_mime_type at
plugin.c:232
1.2                         y     0xb4fce0ca in deactivate_plugin at plugin.c:232
1.3                         y     0xb4fc3447 in value_added_fm_current_file at
plugin.c:232
1.4                         y     0xb333cd83 in skip_iter_to_previous_line at
plugin.c:232
2       breakpoint     keep y   <MULTIPLE> 0xb5ccff7b
2.1                         y     0xb5ccff7b in
project_manager_plugin_instance_init at plugin.c:1648
2.2                         y     0xb5a6c600 in prefs_init at plugin.c:1648
done
(gdb) 

So, we get more breakpoints (which is expected has more plugins have been
loaded). I get the strange behavior on both breakpoints. gdb hasn't put any of
the two expected breakpoints.
The first breakpoint plugins/debug-manager/plugin.c:232 should be in a function
named value_added_project_root_uri.
The second one plugins/language-support-cpp-java/plugin.c:1648 should be in a
function named on_value_added_current_editor.
Both plugin are loaded at that time.

In order to check this, I have tried to set one of the original breakpoint

-break-insert
/home/seb2008.1/Programmation/Anjuta/anjuta/plugins/debug-manager/plugin.c:232
done,bkpt={number="3",type="breakpoint",disp="keep",enabled="y",addr="<MULTIPLE>",addr="0xb5206453",times="0"}
(gdb) 
info break
Num     Type           Disp Enb Address    What
1       breakpoint     keep y   <MULTIPLE> 0xb5206453
	breakpoint already hit 333 times
1.1                         y     0xb5206453 in ilanguage_get_from_mime_type at
plugin.c:232
1.2                         y     0xb4fce0ca in deactivate_plugin at plugin.c:232
1.3                         y     0xb4fc3447 in value_added_fm_current_file at
plugin.c:232
1.4                         y     0xb333cd83 in skip_iter_to_previous_line at
plugin.c:232
2       breakpoint     keep y   <MULTIPLE> 0xb5ccff7b
2.1                         y     0xb5ccff7b in
project_manager_plugin_instance_init at plugin.c:1648
2.2                         y     0xb5a6c600 in prefs_init at plugin.c:1648
3       breakpoint     keep y   <MULTIPLE> 0xb5206453
3.1                         y     0xb5206453 in ilanguage_get_from_mime_type at
plugin.c:232
3.2                         y     0xb4fce0ca in deactivate_plugin at plugin.c:232
3.3                         y     0xb4fc3447 in value_added_fm_current_file at
plugin.c:232
3.4                         y     0xb333cd83 in skip_iter_to_previous_line at
plugin.c:232
done

The breakpoint stays quite strange.


info line
/home/seb2008.1/Programmation/Anjuta/anjuta/plugins/debug-manager/plugin.c:232
Line 232 of "plugin.c" starts at address 0xb5206453
<ilanguage_get_from_mime_type+35> and ends at 0xb520645f
<ilanguage_get_from_mime_type+47>.
/home/seb/Programmation/Anjuta/anjuta/plugins/language-manager/plugin.c:232:5683:beg:0xb5206453

info line get a wrong result.
Comment 5 Nick Roberts 2009-01-19 20:41:46 UTC
> > I don't see how this can happen in the gdb code.  Are you sure this is vanilla
> > gdb?

> I'm quite sure, I have compiled it from the gdb-6.8.tar.bz2. The last entry in
> the ChangeLog file is:

OK.  I can see that in current Gdb the extra address is no longer printed.
I can also see similar problems when two shared objects with the same filename
are loaded.  Gdb doesn't always seem to have a handle on the full path name.

> info line
> /home/seb2008.1/Programmation/Anjuta/anjuta/plugins/debug-manager/plugin.c:232
> Line 232 of "plugin.c" starts at address 0xb5206453
> <ilanguage_get_from_mime_type+35> and ends at 0xb520645f
<ilanguage_get_from_mime_type+47>.
>
/home/seb/Programmation/Anjuta/anjuta/plugins/language-manager/plugin.c:232:5683:beg:0xb5206453

This seems to say that the problem is with how Gdb reads the symbol information
from the file and not how the breakpoint code handles it.

I probably can't be of much help except to say that you could send this last
piece of information to the gdb list which is read by more people.  First though
I would check it hasn't been fixed by current Gdb either using a snapshot or
downloading from CVS. 
Comment 6 seb.sfo 2009-01-25 18:14:18 UTC
I have get the latest gdb snapshot 6.8.50.20090125 and try something simpler.

I start gdb directly without using Anjuta nor the mi2 interface and use it to
debug Anjuta itself which load several plugins. So I do the following:

$ gdb /usr/local/bin/anjuta
GNU gdb (GDB) 6.8.50.20090125
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
(gdb) run -c
... 
Wait about 30s, Anjuta is loading several plugins here
Ctrl+C
Program received signal SIGINT, Interrupt.
0xffffe410 in __kernel_vsyscall ()
(gdb) b
/home/seb2008.1/Programmation/Anjuta/anjuta/plugins/debug-manager/plugin.c:232
Breakpoint 1 at 0xb51d62c8: file plugin.c, line 232. (3 locations)
(gdb) info break
Num     Type           Disp Enb Address    What
1       breakpoint     keep y   <MULTIPLE> 
1.1                         y     0xb51d62c8 in ilanguage_get_from_mime_type
                                       at plugin.c:232
1.2                         y     0xb4784347 in value_added_fm_current_file
                                       at plugin.c:232
1.3                         y     0xb4332d53 in skip_iter_to_previous_line
                                       at plugin.c:232

So, the breakpoint has been put in 3 files
/home/seb2008.1/Programmation/Anjuta/anjuta/plugins/language-manager/plugin.c:232
/home/seb2008.1/Programmation/Anjuta/anjuta/plugins/subversion/plugin.c:232
/home/seb2008.1/Programmation/Anjuta/anjuta/plugins/language-support-cpp-java/plugin.c:232
but not in the right one.

If I do the same things with gdb 6.6 (from my distribution) I get

GNU gdb 6.6-5mdv2008.1 (Mandriva Linux release 2008.1)
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as ""...
Using host libthread_db library "/lib/i686/libthread_db.so.1".
(gdb) run -c
Ctrl+C
Program received signal SIGINT, Interrupt.
[Switching to Thread -1228109248 (LWP 16501)]
0xffffe410 in __kernel_vsyscall ()
(gdb)  b
/home/seb2008.1/Programmation/Anjuta/anjuta/plugins/debug-manager/plugin.c:232
Breakpoint 1 at 0xb470b993: file plugin.c, line 232.
(gdb) info break
Num Type           Disp Enb Address    What
1   breakpoint     keep y   0xb470b993 in value_added_project_root_uri
                                       at plugin.c:232

It is correct.
Comment 7 IngedevTeam.fr 2009-02-17 14:28:44 UTC
I can confirm the issue: since version 6.8 GDB does not take the full path into
account when setting breakpoints. This is a problem when several files have the
same name. This was working with version 6.7.
This is blocking for me because I need features added in version 6.8 (command
"remote put" + possibility to set pending breakpoints on Win32).

Any plans to fix this? Thanks.
Comment 8 seb.sfo 2009-03-02 21:28:01 UTC
Created attachment 3786 [details]
A fix for this bug

I have made some investigations.

In linespec.c:decode_line_1, symtab_from_filename get the right file, but then
it goes through decode_all_digits, calling find_line_symtab, which returns the
wrong one.

In symtab.c:find_line_symtab. Only the filename (without its path) is compared
so it can return completely unrelated symbols. This patch tries to use the full
path name if possible and fix the issue here.

There is another very similar piece of code in symtab.c:expand_line_sal. I
haven't change it because I don't know exactly when this code is executed. But
it probably has exactly the same problem as only the file names are compared.
Comment 9 seb.sfo 2009-10-01 18:00:24 UTC
It seems that it's working better with the latest development version of gdb. I
don't get the bug anymore in my sample. I think it is because the files are not
compiled from the source directory.


But it is still existing in a similar configuration as reported by Joel Brobecker:

For the record, here is how I reproduced the issue on my side:
I have two small files a/foo.c and b/foo.c, each containing an empty
function called foo_a and foo_b (resp). Then a file main.c:

     extern void foo_a (void);
     extern void foo_b (void);
     
     int
     main (void)
     {
       foo_a ();
       foo_b ();
     
       return 0;
     }

To build, I did:

    % (cd a && gcc -c -g foo.c)
    % (cd b && gcc -c -g foo.c)
    % gcc -o main main.c a/foo.o b/foo.o

The important part here, is to compile both foo.c files from
within the directory where these files are located, at least
with GCC.

Trying to break on either location, using the filename's fullname,
results in 2 breakpoints being inserted instead of just one:

    (gdb) b /t.a/brobecke/ex/break/a/foo.c:3
    Breakpoint 1 at 0x400480: file foo.c, line 4. (2 locations)
    (gdb) b /t.a/brobecke/ex/break/b/foo.c:3
    Note: breakpoint 1 also set at pc 0x400480.
    Note: breakpoint 1 also set at pc 0x400478.
    Breakpoint 2 at 0x400480: file foo.c, line 4. (2 locations)

With this case, my patch is useless. I'm doing some investigation.
Comment 10 seb.sfo 2009-10-01 20:52:38 UTC
Created attachment 4243 [details]
A updated fix 

I have checked again my fix on the latest development version of gdb and
updated it.

It changes now 2 functions in symtab.c: find_line_symtab and
append_exact_match_to_sals. The previous version of the patch was not working
with the latest version of gdb because now, the additional breakpoints were
coming from append_exact_match_to_sals.

In addition, I have tried to avoid calling symtab_to_fullname when possible and
I have kept the first simple string comparison of the filename.
Comment 11 seb.sfo 2009-10-02 20:57:43 UTC
Created attachment 4248 [details]
updated fix

Updated fix after review
Comment 12 seb.sfo 2009-10-29 21:56:40 UTC
Created attachment 4343 [details]
Updated fix

Update fix to apply on the current development version
Comment 13 Sourceware Commits 2009-11-09 22:03:08 UTC
Subject: Bug 9583

CVSROOT:	/cvs/src
Module name:	src
Changes by:	brobecke@sourceware.org	2009-11-09 22:02:56

Modified files:
	gdb            : symtab.c ChangeLog 

Log message:
	PR mi/9583:
	* symtab.c (find_line_symtab, append_exact_match_to_sals)
	(expand_line_sal): Use full filename when setting breakpoints if
	available

Patches:
http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/gdb/symtab.c.diff?cvsroot=src&r1=1.216&r2=1.217
http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/gdb/ChangeLog.diff?cvsroot=src&r1=1.11040&r2=1.11041

Comment 14 Vladimir Prus 2009-12-03 07:04:12 UTC
This issue appears to have been fixed.