This is the mail archive of the
gdb-prs@sources.redhat.com
mailing list for the GDB project.
gdb/909: Headers included by "gcc -include file.h" cause assertion failure
- From: bugs at referential dot org dot uk
- To: gdb-gnats at sources dot redhat dot com
- Date: 6 Jan 2003 18:55:52 -0000
- Subject: gdb/909: Headers included by "gcc -include file.h" cause assertion failure
- Reply-to: bugs at referential dot org dot uk
>Number: 909
>Category: gdb
>Synopsis: Headers included by "gcc -include file.h" cause assertion failure
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: unassigned
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Mon Jan 06 10:58:02 PST 2003
>Closed-Date:
>Last-Modified:
>Originator: bugs@referential.org.uk
>Release: GNU gdb 2003-01-06-cvs
>Organization:
>Environment:
Linux GWA3 2.2.16 i686 unknown
gcc version 3.2
This GDB was configured as "i686-pc-linux-gnu"...
>Description:
If a header file was included using the -include command-line argument to gcc rather than by #include in the source file then gdb can get confused:
../../gdb-src/gdb/macrotab.c:275: internal-error: compare_locations: Assertion `! included1 || ! included2' failed.
The problem is caused because gcc records that both math.h and stdio.h are included at line 1. It changes stdio.h's line to be 2 to avoid this conflict but then doesn't notice that stdlib.h's line number 2 conflicts with stdio.h.
>How-To-Repeat:
$ gcc -g3 -Wall -include math.h test_inc.c -o test_inc
$ ./gdb-build/gdb/gdb test_inc
(gdb) r
[Sometimes this causes the internal error, if not then doing]
(gdb) bt
[after test_inc segfaults will cause the error.]
>Fix:
macro_include sorts files in decreasing order of inclusion line (ie. from last to first) but if a file f1.h is included at line n and then another file is created, f2.h, which is also included at line n then it puts f2.h after f1.h and sets its line to n+1 which upsets the ordering. The correct behaviour is to put f2.h before f1.h but the included files are in a singly linked list so this is difficult, or to set f2.h's line to n-1, but this can create negative line numbers. Since nothing seems to depend on the ordering of the list I just reversed it to be sorted from first (lowest line number) to last. The preceding comment suggests that the original ordering was a bug anyway.
--- macrotab.c.~1.7.~ Tue Dec 17 00:39:07 2002
+++ macrotab.c Mon Jan 6 18:49:34 2003
@@ -430,7 +430,7 @@
which is therefore the file we should directly precede --- or
reach the end of the list. */
for (link = &source->includes;
- *link && line < (*link)->included_at_line;
+ *link && line > (*link)->included_at_line;
link = &(*link)->next_included)
;
>Release-Note:
>Audit-Trail:
>Unformatted:
----gnatsweb-attachment----
Content-Type: application/octet-stream; name="test_inc.c"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="test_inc.c"
I2luY2x1ZGUgInN0ZGlvLmgiCiNpbmNsdWRlICJzdGRsaWIuaCIKCmludAptYWluICgpCnsKICBp
bnQgKnAgPSAwOwogIGludCBpID0gKnA7CiAgcmV0dXJuIDA7Cn07CgovKgogKiBMb2NhbCBWYXJp
YWJsZXM6CiAqIGNvbXBpbGUtY29tbWFuZDogImdjYyAtZzMgLVdhbGwgLWluY2x1ZGUgbWF0aC5o
IHRlc3RfaW5jLmMgLW8gdGVzdF9pbmMiCiAqIEVuZDoKICovCg==