Hi!
I started playing around with clang today, and hit a crash in the HTMLDiagnostics. Unfortunately I don't have the time to reduce the test case right now, but nevertheless I wanted to draw your attention to this (maybe it's something obvious for people who know the code).
I'll try to come up with a testcase that relies only on open source code for people to reproduce.
Stacktrace and gdb info:
$ gdb clang
(gdb) run -html-diags=/tmp/html-diag -pedantic -DHAVE_CONFIG_H -I=.. -I=/opt/local/include/glib-2.0 -I=/opt/local/include -I=/opt/local/lib/glib-2.0/include -I=/opt/mysql/include/mysql chassis.c
349 diagnostics generated.
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0xc033c4fb
0x001ee9f9 in clang::SourceManager::getColumnNumber (this=0xc02080, Loc={ID = 19692785}) at SourceManager.cpp:177
177 while (LineStart && Buf[LineStart-1] != '\n' && Buf[LineStart-1] != '\r')
(gdb) bt
#0 0x001ee9f9 in clang::SourceManager::getColumnNumber (this=0xc02080, Loc={ID = 19692785}) at SourceManager.cpp:177
#1 0x001ee223 in clang::FullSourceLoc::getColumnNumber (this=0xbfffe650) at SourceLocation.cpp:58
#2 0x0000b937 in (anonymous namespace)::HTMLDiagnostics::HandlePiece (this=0xc00550, R=@0xbfffeaa8, BugFileID=150, P=@0xe504e0, num=1, max=1) at HTMLDiagnostics.cpp:344
#3 0x0000c281 in (anonymous namespace)::HTMLDiagnostics::ReportDiag (this=0xc00550, D=@0xe50470) at HTMLDiagnostics.cpp:182
#4 0x0000ceb2 in (anonymous namespace)::HTMLDiagnostics::~HTMLDiagnostics (this=0xc00550) at HTMLDiagnostics.cpp:98
#5 0x000300eb in std::auto_ptr<clang::DiagnosticClient>::~auto_ptr (this=0xbfffeda4) at memory:259
#6 0x0002f012 in main (argc=10, argv=0xbfffee24) at clang.cpp:1515
(gdb) p LineStart
$1 = 31985
(gdb) p Buf
$2 = 0xc033480b <Address 0xc033480b out of bounds>
If you need more information or want me to try patches etc, please let me know.
Both LLVM and clang are built from a fresh checkout of trunk:
classdump:clang kroepke$ svn info
Last Changed Author: kremenek
Last Changed Rev: 54440
Last Changed Date: 2008-08-07 03:02:05 +0200 (Thu, 07 Aug 2008)
classdump:clang kroepke$ cd ../..
classdump:llvm-svn kroepke$ svn info
Last Changed Author: asl
Last Changed Rev: 54461
Last Changed Date: 2008-08-07 11:55:25 +0200 (Thu, 07 Aug 2008)
cheers,
-k
p.s.: (duh, stupid address autocompletion - sent it to cfe-dev-request originally :P)
I started playing around with clang today, and hit a crash in the
HTMLDiagnostics. Unfortunately I don't have the time to reduce the
test case right now, but nevertheless I wanted to draw your attention
to this (maybe it's something obvious for people who know the code).
I'll try to come up with a testcase that relies only on open source
code for people to reproduce.
It seems this (or at least something related) happens with any input file that produces a warning:
Macintosh-3:clang nico$ cat test.c
int main() {
char b[10] = "";
printf(b);
}
Macintosh-3:clang nico$ gdb ../../Debug/bin/clang GNU gdb 6.3.50-20050815 (Apple version gdb-768) (Tue Oct 2 04:07:49 UTC 2007)
Copyright 2004 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 "i386-apple-darwin"...Reading symbols for shared libraries .... done
^P
(gdb) run -fsyntax-only -html-diags=/Users/nico test.c
Starting program: /Users/nico/src/llvm-svn/Debug/bin/clang -fsyntax-only -html-diags=/Users/nico test.c
Reading symbols for shared libraries +++. done
1 diagnostic generated.
Assertion failed: (FileID-1 < FileIDs.size() && "Invalid FileID!"), function getFIDInfo, file /Users/nico/src/llvm-svn/tools/clang/Driver/../include/clang/Basic/SourceManager.h, line 453.
Program received signal SIGABRT, Aborted.
0x966eeb9e in __kill ()
(gdb) bt
#0 0x966eeb9e in __kill ()
#1 0x966eeb91 in kill$UNIX2003 ()
#2 0x96765ec2 in raise ()
#3 0x9677547f in abort ()
#4 0x96767063 in __assert_rtn ()
#5 0x00005422 in clang::SourceManager::getFIDInfo (this=0xd02090, FileID=1070333358) at SourceManager.h:453
#6 0x00005458 in clang::SourceManager::getContentCache (this=0xd02090, FileID=1070333358) at SourceManager.h:458
#7 0x0000e2e0 in clang::SourceManager::getBuffer (this=0xd02090, FileID=1070333358) at SourceManager.h:286
#8 0x0000bd77 in (anonymous namespace)::HTMLDiagnostics::HandlePiece (this=0xd01fd0, R=@0xbffff468, BugFileID=1070333358, P=@0xd073e0, num=1, max=1) at HTMLDiagnostics.cpp:338
#9 0x0000c611 in (anonymous namespace)::HTMLDiagnostics::ReportDiag (this=0xd01fd0, D=@0xd07310) at HTMLDiagnostics.cpp:182
#10 0x0000d242 in (anonymous namespace)::HTMLDiagnostics::~HTMLDiagnostics (this=0xd01fd0) at HTMLDiagnostics.cpp:98
#11 0x00030729 in std::auto_ptr<clang::DiagnosticClient>::~auto_ptr (this=0xbffff784) at memory:259
#12 0x0003073d in std::auto_ptr<clang::DiagnosticClient>::~auto_ptr (this=0xbffff784) at memory:259
#13 0x0002eb1e in main (argc=4, argv=0xbffff804) at clang.cpp:1515
(gdb) The program is running. Exit anyway? (y or n) y
I fixed the problem for Nico's test case:
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20080804/006855.html
The problem was that when using --html-diags we didn't have a Preprocessor available when constructing HTMLDiagnosticClient, which led to all sorts of badness.
Kay: can you confirm that this fixes the issue for you?
I m’ not sure, but it may be related to this (around line 1390 ~1400) :
if (!HTMLDiag.empty()) {
// FIXME: The HTMLDiagnosticClient uses the Preprocessor for
// (optional) syntax highlighting, but we don’t have a preprocessor yet.
// Fix this dependency later.
DiagClient.reset(CreateHTMLDiagnosticClient(HTMLDiag, 0, 0));
Ye thanks, I saw that too. It fixed it to fast 
Ted, confirmed.
Thank you very much for the quick response!
cheers,
-k