Developer forums (C::B DEVELOPMENT STRICTLY!) > CodeCompletion redesign

parser test rev 7157 error?

(1/7) > >>

ollydbg:
Hi, morten, I found that in the rev 7157, you enabled the parsing include files. but look at this:

--- Code: ---bool ParserThread::Parse()
{
    wxCriticalSectionLocker locker(g_ParserThreadCritical);

    if (!IS_ALIVE || !InitTokenizer())
        return false;

    TRACE(_T("Parse() : Parsing '%s'"), m_Filename.wx_str());

    bool result = false;
    m_ParsingTypedef = false;

    do
    {
        if (!m_TokensTree || !m_Tokenizer.IsOK())
            break;

        if (!m_Options.useBuffer) // Parse a file
        {
            wxCriticalSectionLocker locker(s_TokensTreeCritical);
            m_FileIdx = m_TokensTree->ReserveFileForParsing(m_Filename);
            if (!m_FileIdx)
                break;
        }

        DoParse();

        if (!m_Options.useBuffer) // Parsing a file
        {
            wxCriticalSectionLocker locker(s_TokensTreeCritical);
            m_TokensTree->FlagFileAsParsed(m_Filename);
        }

        result = true;
    }
    while (false);

    return result;
}

--- End code ---

This function will be called recursively, but why the first statement:

--- Code: ---wxCriticalSectionLocker locker(g_ParserThreadCritical);
--- End code ---

It seems this locker should block the recursive call, but in-fact, it doesn't. I test under mingw+windows. That's was quite strange...

Any ideas?

MortenMacFly:

--- Quote from: ollydbg on May 24, 2011, 09:09:27 am ---It seems this locker should block the recursive call, but in-fact, it doesn't.
Any ideas?

--- End quote ---
I am aware of this and no, I havent' looked into it. I could imagine that another (wrong) mutex is locked, or, that the mutex is created multiple times. I've marked another (possible) crash anyways, as this still is a work-in-progress. My "masterplan" was to collect the included files and parse them one-by-one to avoid this and (most important) the other crash.

But as it works as it is now I wanted to do an interim-commit, so people see what's happening and we are avoiding conflicts. This is a test project after all, so it's not critical. My intention is to fix the bug with the parser being stalled.

Loaden:

--- Quote from: ollydbg on May 24, 2011, 09:09:27 am ---This function will be called recursively,

--- End quote ---
No, The DoParse will be called recursively, not is Parse.


--- Quote from: ollydbg on May 24, 2011, 09:09:27 am ---It seems this locker should block the recursive call, but in-fact, it doesn't. I test under mingw+windows. That's was quite strange...

--- End quote ---
A source file, *.h, or *.c/cpp, should call Parse() once.
This locker make them parsed one by one.

Loaden:

--- Quote from: MortenMacFly on May 24, 2011, 01:18:35 pm ---I've marked another (possible) crash anyways, as this still is a work-in-progress.

--- End quote ---
Sorry, I can't solved the random crash.
I am very happy to see you watched the same issue. :D

ollydbg:
Here is my test example:
let the test.h be like below:

--- Code: ---int aaaaa;
float bbbbb;
#include <a.h>
#include <b.h>

--- End code ---

create "a.h" and "b.h" along with "test.h". (in the same folder)

here is a.h

--- Code: ---int in_a_h;
#include "b.h"

--- End code ---

Here is b.h

--- Code: ---int in_b_h;

--- End code ---

Then debug the parsertest project, see the screenshot:


Why does the function "Parse" recursively called???

Navigation

[0] Message Index

[#] Next page