This is the mail archive of the gdb-prs@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

gdb/909: Headers included by "gcc -include file.h" cause assertion failure


>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==


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]