Bug 170044 - kdevelop parser crash/freeze - non-threadsafe QString
Summary: kdevelop parser crash/freeze - non-threadsafe QString
Status: RESOLVED FIXED
Alias: None
Product: kdevelop
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: Gentoo Packages Linux
: NOR crash
Target Milestone: ---
Assignee: kdevelop-bugs-null
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-08-29 17:38 UTC by Bernd Buschinski
Modified: 2008-08-31 19:19 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
main.cpp (21.58 KB, text/plain)
2008-08-29 17:39 UTC, Bernd Buschinski
Details
crash backtrace 1 (3.12 KB, text/plain)
2008-08-29 17:40 UTC, Bernd Buschinski
Details
crash backtrace 2 (3.29 KB, text/plain)
2008-08-29 17:41 UTC, Bernd Buschinski
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Bernd Buschinski 2008-08-29 17:38:15 UTC
Version:           3.5.3 (using KDE 3.5.9)
Compiler:          gcc-4.3.1 
OS:                Linux
Installed from:    Gentoo Packages

KDevelop crashes with different backtraces or freezes when parsing and clicking in a "special" file.

steps to reproduce:
- create an qmake empty project
- add main.cpp
- paste content of attached file (main.cpp)
- scroll down
(- save file, it will crash with the next step)
- click in line 513
        tXml.up();
between the () and ;
tXml.up()<click here>;
- and it crashes
Comment 1 Bernd Buschinski 2008-08-29 17:39:32 UTC
Created attachment 27129 [details]
main.cpp
Comment 2 Bernd Buschinski 2008-08-29 17:40:33 UTC
Created attachment 27130 [details]
crash backtrace 1
Comment 3 Bernd Buschinski 2008-08-29 17:41:27 UTC
Created attachment 27131 [details]
crash backtrace 2
Comment 4 Andreas Pakulat 2008-08-29 23:41:00 UTC
100% reproduceable. It looks like an out-of-bounds access into the token stream, but sincerely I have no idea how/why that would happen. I'll leave this open for now, maybe David has some time to look into this.
Comment 5 Andreas Pakulat 2008-08-31 00:12:53 UTC
The problem apparently is an unbound access into the token stream, lookAhead(0) crashes. I'm not sure why though, m_size is 5001 and m_index is 5000 in Lexer::lookAhead( int n ). So accessing the last token shouldn't be a problem, but the token pointer is simply bogus 0x05c in my first try.
Comment 6 Andreas Pakulat 2008-08-31 00:14:49 UTC
A check for the m_tokens.count() shows that in fact its only 5000 tokens long, so apparently at some place m_size isn't updated properly.
Comment 7 Andreas Pakulat 2008-08-31 00:21:04 UTC
Ok, staring at the lexer code won't help much, at least not without sitting down for a few hours and trying to find out how it works. So unfortunately this means that I can't fix this bug. Hopefully somebody else has some idea.
Comment 8 Andreas Pakulat 2008-08-31 00:24:57 UTC
I guess I could also add that the problem is that I can't easily see when ADD_TOKEN is needed to be called after running "nextToken". I can only see this macro called in tokenize, but nextToken is called quite a bit more often in the lexer.

Of course I still have no idea why it triggers only on that particular line in that particular example.
Comment 9 Andreas Pakulat 2008-08-31 00:48:27 UTC
Just tried the obvious fix to prevent the out-of-bounds access. That results in an infinite loop somewhere.

Then I wondered wether it might have something to do with the fact that 5000 is a hardcoded "resizing" value in the lexer. That would kind of fit with the fact that using the same position after the up() in the line before and after 513 in the example doesn't produce a crash. The former needs < 5000 tokens, the latter > 5000.

And in fact changing to 6000 there is a workaround for this particular crash. Obviously this can bit us back as soon as someone has a source file with >6000 tokens and manages to place the cursor exactly after token 6000.
Comment 10 Andreas Pakulat 2008-08-31 19:19:25 UTC
:( svn keywords still not working. I've fixed this last night in kdevelop3.5. David didn't have anything to add, except that its a weird fix for a weird problem :)