Bug 68704 - crash when using temporary preprocessor macros (possibly related to code completion)
Summary: crash when using temporary preprocessor macros (possibly related to code comp...
Status: RESOLVED FIXED
Alias: None
Product: kdevelop
Classification: Applications
Component: Language Support: CPP (old) (show other bugs)
Version: 3.0.0b1
Platform: Mandrake RPMs Linux
: NOR crash
Target Milestone: ---
Assignee: KDevelop Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-11-21 02:04 UTC by Ted Cipicchio
Modified: 2013-03-31 00:57 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
crash-patch (574 bytes, patch)
2003-11-21 06:17 UTC, Jens Dagerbo
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ted Cipicchio 2003-11-21 02:04:20 UTC
Version:           3.0.0 beta 1 (using KDE KDE 3.1.3)
Installed from:    Mandrake RPMs
Compiler:          GCC 3.3 
OS:          Linux

In a C++ project, I have defined a preprocessor macro temporarily to help avoid copying and pasting code for a particular block similar to what's shown below:

int foo (int bar)
{
    int a, b, c, d;
    ...
#define TMP_HELPER_MACRO(X, Y) { ... }
    TMP_HELPER_MACRO(a, b)
    TMP_HELPER_MACRO(c, d)
#undef TMP_HELPER_MACRO
    ...
}

Let's say I create the #define/#undef statements first and start filling in the calls to TMP_HELPER_MACRO in between them.  If you wait a second after typing the opening parenthesis after TMP_HELPER_MACRO (where you would expect KDevelop's code completion to try to come up with a hint as to function parameters or such), KDevelop will crash.  For example:

#define TMP_HELPER_MACRO(X, Y) { ... }
    // Type the following line after typing the surrounding #define and #undef lines, and KDevelop will crash.
    TMP_HELPER_MACRO(
#undef TMP_HELPER_MACRO

The name of the macro and the macro's code don't seem to make a difference.  The crash does not occur if you don't write the #undef statement first.

Hopefully this is enough information, but I'll try to provide more if needed.

Thanks,
Ted
Comment 1 Jens Dagerbo 2003-11-21 06:17:44 UTC
Created attachment 3314 [details]
crash-patch
Comment 2 Jens Dagerbo 2003-11-21 06:22:42 UTC
Confirmed.

Somewhere in the middle of Lexer::nextToken(), the referenced mapentry seems to get invalidated. This simplistic patch avoids crashing on my system, but as I have no idea about the code, I can't be sure the fix is correct. Please test.

Roberto? :)

(Patch attached above. I'm sure I'll learn this system one day... )
Comment 3 Jens Dagerbo 2003-11-21 13:25:21 UTC
Subject: kdevelop/lib/cppparser

CVS commit by dagerbo: 

Take a copy of the structure while it is valid in order not to crash later. 
I don't know why the map entry gets invalidated, but Roberto says the 
patch works, so here goes...

CCMAIL: 68704-done@bugs.kde.org


  M +2 -1      lexer.cpp   1.21


--- kdevelop/lib/cppparser/lexer.cpp  #1.20:1.21
@@ -290,5 +290,6 @@ void Lexer::nextToken( Token& tk, bool s
             int svColumn = currentColumn();
 
-            Macro& m = m_driver->macro( ide );
+//          Macro& m = m_driver->macro( ide );
+            Macro m = m_driver->macro( ide );
             //m_driver->removeMacro( m.name() );
 


Comment 4 Ted Cipicchio 2003-11-22 00:54:12 UTC
Looks to be working okay on my end, too.  (Figured I'd reply anyway even though the bug is already marked as fixed.)
Comment 5 Jens Dagerbo 2003-11-22 01:35:14 UTC
Great. Thanks for the input!
Comment 6 Aleix Pol 2013-03-31 00:57:30 UTC
Moving all the bugs from the CPP Parser. It was not well defined the difference between it and C++ Language Support and people kept reporting in both places indistinctively