User forums > Nightly builds
The 25 september 2010 build (6634) CODECOMPLETION BRANCH version is out.
ollydbg:
it should be a bug in Macro expansion related code. some infinite recursive macro replacement happens. like
--- Quote ---AAA is replaced to BBB
Then BBB is replaced to AAA
...AAA is replaced to BBB
...BBB is replaced to AAA
...
--- End quote ---
--- Quote ---With every loop the real length of m_Buffer grows by one (that's the cause for the great amount of memory used in my test).
--- End quote ---
Macro expansion is just replace some characters in the m_Buffer.
--- Code: ---xxxxxxxxxAAAA(u,v)yyyyyyyyy
--- End code ---
For example, the above is a char Array m_Buffer, then "AAAA(u,v)" need to do a Macro expansion to some other text. So, we just do a "backward" text replace, so that, after replacement, The last replacement char was ")" in "AAAA(u,v)" (We say it as an entry point), so the text becomes:
--- Code: ---xxxNNNNNNNNNNNNNNNyyyyyyyyy
--- End code ---
Note that "NNNNNNNNNNNN" is some macro expansion text. then the m_TokenIndex was moved backward to the beginning of the text.
if the macro expansion result text is small enough, then m_Buffer's length do not need to change.
The situation when our m_Buffer's length need to be change is that the macro expansion text is too long, so the buffer before "entry point" can not hold the new text, this way, m_Buffer's length will adjusted. like:
--- Code: ---NNNNNNNNNNNNNNNNNNNNNNyyyyyyyyy
--- End code ---
Hope this helps to find the bug.
Loaden:
--- Quote from: jens on October 03, 2010, 12:03:16 am ---It's in fact an endless loop cc runs in:
--- Code: ---ReplaceBufferForReparse() : <FROM> UL<TO>(x)
The replaced actual context are '_AC(x, UL)'.
ReplaceBufferForReparse() : <FROM> _AC(x,(x)<TO>_AC(x, UL)
ReplaceBufferForReparse() : <FROM> UL<TO>(x)
The replaced actual context are '_AC(x, UL)'.
ReplaceBufferForReparse() : <FROM> _AC(x,(x)<TO>_AC(x, UL)
ReplaceBufferForReparse() : <FROM> UL<TO>(x)
The replaced actual context are '_AC(x, UL)'.
ReplaceBufferForReparse() : <FROM> _AC(x,(x)<TO>_AC(x, UL)
ReplaceBufferForReparse() : <FROM> UL<TO>(x)
The replaced actual context are '_AC(x, UL)'.
ReplaceBufferForReparse() : <FROM> _AC(x,(x)<TO>_AC(x, UL)
ReplaceBufferForReparse() : <FROM> UL<TO>(x)
The replaced actual context are '_AC(x, UL)'.
ReplaceBufferForReparse() : <FROM> _AC(x,(x)<TO>_AC(x, UL)
ReplaceBufferForReparse() : <FROM> UL<TO>(x)
The replaced actual context are '_AC(x, UL)'.
ReplaceBufferForReparse() : <FROM> _AC(x,(x)<TO>_AC(x, UL)
ReplaceBufferForReparse() : <FROM> UL<TO>(x)
--- End code ---
Happens in tokenizer.cpp in CalcConditionExpression after call of ReplaceBufferForReparse in
--- Code: ---else if (!tk->m_Args.IsEmpty())
--- End code ---
.
--- End quote ---
It shoud be fixed by this patch.
Thanks!
Loaden:
--- Quote from: ollydbg on October 03, 2010, 04:27:54 am ---AAA is replaced to BBB
Then BBB is replaced to AAA
...AAA is replaced to BBB
...BBB is replaced to AAA
...
--- End quote ---
Yes, like this, AAA is macro, and BBB is argument. I can't write a sample too.
But i find the reason, and avoid the endless loop.
Jenna:
--- Quote from: ollydbg on October 03, 2010, 04:27:54 am ---it should be a bug in Macro expansion related code. some infinite recursive macro replacement happens. like
--- Quote ---AAA is replaced to BBB
Then BBB is replaced to AAA
...AAA is replaced to BBB
...BBB is replaced to AAA
...
--- End quote ---
--- Quote ---With every loop the real length of m_Buffer grows by one (that's the cause for the great amount of memory used in my test).
--- End quote ---
Macro expansion is just replace some characters in the m_Buffer.
--- Code: ---xxxxxxxxxAAAA(u,v)yyyyyyyyy
--- End code ---
For example, the above is a char Array m_Buffer, then "AAAA(u,v)" need to do a Macro expansion to some other text. So, we just do a "backward" text replace, so that, after replacement, The last replacement char was ")" in "AAAA(u,v)" (We say it as an entry point), so the text becomes:
--- Code: ---xxxNNNNNNNNNNNNNNNyyyyyyyyy
--- End code ---
Note that "NNNNNNNNNNNN" is some macro expansion text. then the m_TokenIndex was moved backward to the beginning of the text.
if the macro expansion result text is small enough, then m_Buffer's length do not need to change.
The situation when our m_Buffer's length need to be change is that the macro expansion text is too long, so the buffer before "entry point" can not hold the new text, this way, m_Buffer's length will adjusted. like:
--- Code: ---NNNNNNNNNNNNNNNNNNNNNNyyyyyyyyy
--- End code ---
Hope this helps to find the bug.
--- End quote ---
The cause for the growing m_Buffer is, that in every loop one of the two replacements made needed 10 bytes, but m_TokenIndex is 9, so one space is prepended.
As posted there are thousnads (after some times millions of colsing brackets visible in m_pchData but not seen by our function to display wxString's in gdb.
@ Loaden:
I test the patch and give you feedback.
Jenna:
--- Quote from: jens on October 03, 2010, 09:29:58 am ---@ Loaden:
I test the patch and give you feedback.
--- End quote ---
First endless-loop seems to be fixed, now we get one some lines later.
--- Code: ---ReplaceBufferForReparse() : <FROM>printf<TO>printk
ReplaceBufferForReparse() : <FROM>printk<TO>printf
--- End code ---
tk->m_Type is printf and token is printk and vice versa.
Can this be handled in ReplaceBufferForReparse, so it only has to be done in one place ?
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version