[Solved] Distracting SymbolBrowser Behaviour

[Miguel Gimenez]

I wrote that code three years ago, but I have forgotten the details.

CallAfter() is executed in call order (it uses the event queue), but it is possible for a second call to execute while the first is still running. Probably a mutex in ClassBrowser::TreeOperation() fixes this, or waiting for a "finished" flag after each call to CallAfter().

[sodev]

I don't know the code you are referring to but your description of how CallAfter() works is wrong. CallAfter() does always post to the main thread, so even if the code executed by CallAfter() does use CallAfter() itself, that code won't execute immediately, your described interleaving of calls can't happen.

[Pecan]

I wrote that code three years ago, but I have forgotten the details.

CallAfter() is executed in call order (it uses the event queue), but it is possible for a second call to execute while the first is still running. Probably a mutex in ClassBrowser::TreeOperation() fixes this, or waiting for a "finished" flag after each call to CallAfter().

Thank you You're suggestion worked.
By placing a semafore.Wait() after the CallAfter()s and  a semaphore.Post() in the CallAfter()'s target function, all the crashes that I could previously create disappeared.

Whew !!, Thanks again.

[Miguel Gimenez]

Happy it worked, good job.

@sodev, what I am telling is: if you execute two consecutive CallAfter(foo) in the worker thread, and foo() in the main thread calls p.e. Yield(), directly or indirectly, then the second foo() will start executing before the first has ended. Control will return to the first foo() when the second ends.

[sodev]

That makes sense, i didn't take the dangerous Yield() into account.

[Pecan]

Head ver 13432 contains many fixes to the ClassBrowser after treating it badly with stress testing and beating out every crash I could find.

Give it a try,  beat up on it,and let us know how it goes.
Backup your current codecompletion.dll and copy the the devel version to the output folder version so that any crash shows us the line numbers in the backtrace file.

Thanks

[tigerbeard]

Give it a try,  beat up on it,and let us know how it goes.

Thanks for your work. I am currently testing that as my main development version. Its very stable so far but I need more testing.
I am testing svn13342 under a Linux Ubuntu 22.04 environment.

Some early feedback
* when opening a new project the symbol tree is not shown unless I click into the empty tab. I am not sure if its a 100% rule, but I did not have another case yet

* during work sometimes the three would not rebuild and an empty tab is shown with no working context menu. It was notable, because I found no other way to display the symbol tree again other than rebuilding the project. That happening out of nowhere would be a bit annoying for a new user. It happened during a full work day about 5 times, so I only can say there seems to be something, but i need to find a way to reproduce it.

* Subjectively the symbol tree seems to re-build a bit less often than before, which is a good thing. I had not crashes at all.

I keep on testing.

[Miguel Gimenez]

Using svn13436, if I open C::B workspace, wait for CC to complete and close the program then codeblocks.exe still shows in the task manager (tested on MSW).

I have detected this after compiling svn13437: executing update32.bat shows a lot of "file in use" errors.

EDIT: nightly 13430 works OK, nightly 13434 fails. This leaves 13432 as the suspect, probably the thread is waiting for a semaphore.

[Pecan]

Using svn13436, if I open C::B workspace, wait for CC to complete and close the program then codeblocks.exe still shows in the task manager (tested on MSW).

I have detected this after compiling svn13437: executing update32.bat shows a lot of "file in use" errors.

EDIT: nightly 13430 works OK, nightly 13434 fails. This leaves 13432 as the suspect, probably the thread is waiting for a semaphore.

Thanks, I'll look into it.

[Pecan]

Using svn13436, if I open C::B workspace, wait for CC to complete and close the program then codeblocks.exe still shows in the task manager (tested on MSW).

I have detected this after compiling svn13437: executing update32.bat shows a lot of "file in use" errors.

EDIT: nightly 13430 works OK, nightly 13434 fails. This leaves 13432 as the suspect, probably the thread is waiting for a semaphore.

I could not recreate this problem, so I changed all CallAfter semaphore Wait()s to WaitTimeout(500).

Please test to see if this solved the problem.
Thanks

[Miguel Gimenez]

It works now, thank you.