Developer forums (C::B DEVELOPMENT STRICTLY!) > CodeCompletion redesign
Macro expansion infinite loop.
ollydbg:
OK. I will test it.
ollydbg:
I see infinite loop too. :(
Bug located. Patch here:
--- Code: --- src/plugins/codecompletion/parser/tokenizer.cpp | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/plugins/codecompletion/parser/tokenizer.cpp b/src/plugins/codecompletion/parser/tokenizer.cpp
index 764bcbe..6202eda 100644
--- a/src/plugins/codecompletion/parser/tokenizer.cpp
+++ b/src/plugins/codecompletion/parser/tokenizer.cpp
@@ -1794,6 +1794,10 @@ bool Tokenizer::ReplaceBufferText(const wxString& target)
m_TokenIndex = m_BufferLen - m_FirstRemainingLength;
m_PeekAvailable = false;
SkipToEOL(false);
+ SkipToOneOfChars(_T(",;}"), true, false, false);
+ m_SavedTokenIndex = m_UndoTokenIndex = m_TokenIndex;
+ m_SavedLineNumber = m_UndoLineNumber = m_LineNumber;
+ m_SavedNestingLevel = m_UndoNestLevel = m_NestLevel;
return false;
}
else
--- End code ---
It is a workaround patch and will cause parsing the Test class body wrongly, you will notice one extra member in the symbol tree :). But it works around a bug that macro replacement cause infinite loop when parsing. The fundamental solution is to ONLY do macro replacement in the Tokenizer level. (We currently do in both ParserThread and Tokenizer).
Can you test it?
I noticed another issue is that token numbers are becomes large because we save all the "macro usage tokens". I think they should not be saved in the tokentree, they are just like function call. Since we only restore the function declaration/definition, we don't save the function call, I think we also don't need to store the macro usage.
About macro usage check in the Tokenizer level, I have locally implement this feature, and it solve the bug Macro replacement in CC should remember the used macro definition(this is the similar issue as OBF's test case), but my local implementation contains many commits and massive code change in Tokenizer and Parserthread class. :(
oBFusCATed:
Yes, it does prevent the infinite loop and yes it screws the members of the struct that are declared after the broken member.
If you have some code that needs testing post a branch on github or even a patch and I'll give it a try.
ollydbg:
--- Quote from: oBFusCATed on January 23, 2015, 07:35:18 pm ---Yes, it does prevent the infinite loop and yes it screws the members of the struct that are declared after the broken member.
If you have some code that needs testing post a branch on github or even a patch and I'll give it a try.
--- End quote ---
OK, after taking several hours to clean up my local git(merge some patches, split some patches, move some patches up and down) , I create a patches serials which contains 31 patches which are against SVN rev 10081.
Any comments are welcome. :)
MortenMacFly:
--- Quote from: ollydbg on January 24, 2015, 02:45:42 pm ---Any comments are welcome. :)
--- End quote ---
No patches against SVN, and/or does not apply against SVN, so I am out (as usual)...
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version