Developer forums (C::B DEVELOPMENT STRICTLY!) > Development

NativeParser lockup when parsing Visual Studio 2013 and Boost 1.55.0 headers

<< < (3/3)

sodev:
So i've spend more time to try to solve this problem myself and got a little further, the cause of the lockup is a mutex deadlock because the parser thread gets stuck in an endless loop.

This is how i compiled CodeBlocks to track the error:

* enabled CC_ENABLE_LOCKER_TRACK in cclogger.h
* specified the defines CC_PROCESS_LOG_EVENT_TO_PARENT=1, CC_PARSERTHREAD_DEBUG_OUTPUT=1
* fixed parserthread.cpp to not define CC_PARSERTHREAD_DEBUG_OUTPUT to zero and the beginning so that my compiler switches actually work
* i disabled pretty much all TRACE calls in parserthread.cpp except the ones for found includes and tokenizer initialization
Opening my test project results in the following log: <log attached because of post size limit>

After it stoppped writing more debug messages i've clicked into the opened main.cpp and got one more line:

--- Code: ---s_TokenTreeMutex.Lock() : IsFileParsed(), C:\SVN\xternal\codeblocks\src\plugins\codecompletion\parser\parser.cpp, 1170
--- End code ---

The GUI stopped responding after this, which makes sense because that mutex was still locked.

To track the problem further, i enabled more debug messages, but this ended up in chaos, i tried to enable file logging but that somehow didn't work, so all i have is a screenshot. However, these are the additional changes:

* specified the additional defines CC_PARSER_DEBUG_OUTPUT=1, CC_TOKENIZER_DEBUG_OUTPUT=1
* fixed parser.cpp and tokenizer.cpp to not override these defines
And this is the screenshot of the lockup: <see attachment>

So looks like that is the endless loop the thread is locked in, the last filename from the reduced log from the previous try was


--- Code: ---InitTokenizer() : m_Filename='C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\Include\ObjBase.h', m_FileSize=38379.
Parse() : Parsing 'C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\Include\ObjBase.h'

--- End code ---

so it might be stuck in there or in some of its included headers. Now the strange thing is, if i include that file directly instead of windows.h it does not lockup?! The parsing finishes in that case!

[attachment deleted by admin]

ollydbg:
Hi, sodev, thanks for the testing.

Looking at your screen shot, I believe there is a bug in the Tokenizer/Parserthread, you see, all the log messages show Tokenizer is in line 863, and Current Char is E, and next Char is C. It is also the macro replacement functions which cause such bug, you can see ”_Group_impl_" is the key point. Maybe, some text replacement go into a endless loop, such as text "A" was replaced by text "B", then text "B" was replaced by text "C", then text "C" replaced by text "A" again.....

Here, Tokenizer dose not go ahead, so in this time, the Parserthread instance is holding the Tokentree, thus the mutex is never released. Now any access from the GUI thread (mostly in the event handler) to the Tokentree is blocked, so the main GUI get blocked too.

I would recommand to see what is the line 863 in the opened file, maybe parser are running endless loop in the file 'C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\Include\ObjBase.h'.

Also, you can disable the macro-expansion feature in the CodeCompletion setting dialog, and see whether such loop happens again.

Since I can't reproduce your bug here(I don't have VC++ installed), so I can't give more help, sorry.

sodev:
The fragment you can see in the screenshot is part of the SAL macros from Visual Studio used for source code annotions, it can be found in sal.h


--- Code: ---// _When_(expr, annos) specifies that the annotations listed in 'annos' only
// apply when 'expr' evaluates to non-zero.
#define _When_(expr, annos)            _When_impl_(expr, annos _SAL_nop_impl_)
#define _Group_(annos)                 _Group_impl_(annos _SAL_nop_impl_)
#define _GrouP_(annos)                 _GrouP_impl_(annos _SAL_nop_impl_)

--- End code ---

I couldn't find any of these macros in the SDK headers so it looks they are only used for the c runtime headers of Visual Studio, but _Group_impl_(annos _SAL_nop_impl_) doesn't appear anywhere outside of sal.h and even there it is only part of other defines. So that fragment in the debug message must be part of a deep nested define chain or something like that, can't figure out in what file the parser was when the deadlock happened.

Disabling parse complex macros in CodeBlocks made the deadlock go away, so for now this is my solution, i can't spend more time on messing around with CodeBlocks to tailor down the debug messages to figure out where it happens. It looks like SAL was introduced with Visual Studio 2012 so that explains why stahta01 couldn't reproduce with VS 2010.

ollydbg:
@sodev, can you try the latest nightly build version, when I fix the issue of Re: Code blocks using too much cpu, I think your problem should also be solved, can you give some feedback?

Thanks.

sodev:
I compiled r9614 and the lockup indeed is gone now, thanks for that.

Navigation

[0] Message Index

[*] Previous page