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

CodeCompletion Close project anomally

<< < (2/3) > >>

Pecan:
Thanks again !!

That really clears up a mystery for me.

I'll look for some clever way to get the recursive .h threads to check for something like the main thread calls TestDestroy().

Here we go.... more hours of stepping through CodeCompletion.

Pecan:
ollydbg,

I'd like to propose a patch to parser.h/cpp that records the internal threads (just like cbthreadpool) and posts Abort() to the internal threads when ~parser is invoked.

Initial testing with the patch shows that closing a large project (like CodeBlocks.cbp) terminates very fast (without the long delay previously experienced).

If you agree/modify the patch, we can later clean it up (removing //(pecan 2015/11/13) tags which I use to find mods fast) and apply.

I also include one line patches to the logger code to avoid crashes I've experienced a few times when closing CB while CC was busy.

svn build  rev 10554 (2015-11-01 09:18:34)   gcc 4.9.2 Windows/unicode - 32 bit


--- Code: ---Index: src/plugins/codecompletion/parser/cclogger.cpp
===================================================================
--- src/plugins/codecompletion/parser/cclogger.cpp (revision 10554)
+++ src/plugins/codecompletion/parser/cclogger.cpp (working copy)
@@ -87,6 +87,10 @@
 
 void CCLogger::Log(const wxString& msg)
 {
+    //(pecan 2015/11/12) could crash here; should check if shutting down
+    if (Manager::IsAppShuttingDown())
+        return;
+
     if (!m_Parent || m_LogId<1) return;
 
     CodeBlocksThreadEvent evt(wxEVT_COMMAND_MENU_SELECTED, m_LogId);
@@ -100,6 +104,10 @@
 
 void CCLogger::DebugLog(const wxString& msg)
 {
+    //(pecan 2015/11/12) could crash here; should check if shutting down
+    if (Manager::IsAppShuttingDown())
+        return;
+
     if (!m_Parent || m_DebugLogId<1) return;
 
     CodeBlocksThreadEvent evt(wxEVT_COMMAND_MENU_SELECTED, m_DebugLogId);
Index: src/plugins/codecompletion/parser/parser.cpp
===================================================================
--- src/plugins/codecompletion/parser/parser.cpp (revision 10554)
+++ src/plugins/codecompletion/parser/parser.cpp (working copy)
@@ -338,7 +338,9 @@
 
             TRACE(_T("Parser::Parse(): Parsing included header, %s"), filename.wx_str());
             // run the parse recursively
+            AddParserThread(thread);
             result = thread->Parse();
+            RemoveParserThread(thread);
             delete thread;
             return true;
         }
@@ -538,6 +540,7 @@
     // NOTE: This should not be locked with s_ParserMutex, otherwise we'll be stuck in an
     // infinite loop below since the worker thread also enters s_ParserMutex.
     // In fact cbThreadPool maintains it's own mutex, so m_Pool is probably threadsafe.
+    AbortParserThreads();
     m_Pool.AbortAllTasks();
     while (!m_Pool.Done())
         wxMilliSleep(1);
@@ -919,3 +922,38 @@
     // Page "Documentation:
     // m_Options.storeDocumentation will be written by DocumentationPopup
 }
+
+void Parser::AddParserThread (cbThreadedTask *task) //(pecan 2015/11/13)+
+{
+    if (!task)
+        return;
+
+    m_tasksQueue.push_back (task);
+
+}
+void Parser::RemoveParserThread (cbThreadedTask* task) //(pecan 2015/11/13)+
+{
+    if (!task)
+        return;
+
+    for (TasksQueue::iterator it = m_tasksQueue.begin(); it != m_tasksQueue.end(); ++it)
+    {
+        if ((*it) == task)
+        {
+            m_tasksQueue.erase(it);
+            break;
+        }
+
+    }
+}
+void Parser::AbortParserThreads() //(pecan 2015/11/13)+
+{
+    if (not m_tasksQueue.size())
+        return;
+
+    for (TasksQueue::iterator it = m_tasksQueue.begin(); it != m_tasksQueue.end(); ++it)
+    {
+            (*it)->Abort();
+
+    }
+}
Index: src/plugins/codecompletion/parser/parser.h
===================================================================
--- src/plugins/codecompletion/parser/parser.h (revision 10554)
+++ src/plugins/codecompletion/parser/parser.h (working copy)
@@ -355,6 +355,13 @@
 
     /** if true, all the files of the current project will be labeled as "local" */
     bool                      m_NeedMarkFileAsLocal;
+
+    typedef std::list<cbThreadedTask*> TasksQueue; //(pecan 2015/11/13)+
+    TasksQueue m_tasksQueue;    //(pecan 2015/11/13)+
+    void AddParserThread(cbThreadedTask* task); //(pecan 2015/11/13)+
+    void RemoveParserThread(cbThreadedTask* task); //(pecan 2015/11/13)+
+    void AbortParserThreads(); //(pecan 2015/11/13)+
+
 };
 
 #endif // PARSER_H

--- End code ---

oBFusCATed:
Hm, Am I correct in thinking that the need for Manager::IsAppShuttingDown() is a sign that there is a bug somewhere else?

Pecan:

--- Quote from: oBFusCATed on November 13, 2015, 08:26:52 pm ---Hm, Am I correct in thinking that the need for Manager::IsAppShuttingDown() is a sign that there is a bug somewhere else?

--- End quote ---

I'm not sure that's the case.

Way back in CB history, we went through a period where CB often crashed when being shutdown because something about the logs had already been destroyed when plugins attempted to use them during shutdown.

It was some kind of race condition with plugin termination. But now I'm getting too old to remember what it was.

Martin or Lievin might remember.

MortenMacFly:
Yes, I recall something like the logger gets re- intantiated after already being destroyed... Wasn't it like that?

Btw, Pecan - nice work, although I didn't experience this delay on daily work I can reproduce and also confirm that the patch fixes it.

Navigation

[0] Message Index

[#] Next page

[*] Previous page