Author Topic: [Solved] Distracting SymbolBrowser Behaviour  (Read 18163 times)

Offline Miguel Gimenez

  • Developer
  • Lives here!
  • *****
  • Posts: 1644
Re: [Solved] Distracting SymbolBrowser Behaviour
« Reply #15 on: January 22, 2024, 01:02:51 pm »
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().

Offline sodev

  • Lives here!
  • ****
  • Posts: 500
Re: [Solved] Distracting SymbolBrowser Behaviour
« Reply #16 on: January 22, 2024, 08:22:11 pm »
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.

Offline Pecan

  • Plugin developer
  • Lives here!
  • ****
  • Posts: 2813
Re: [Solved] Distracting SymbolBrowser Behaviour
« Reply #17 on: January 23, 2024, 01:21:19 am »
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. ;D
« Last Edit: January 23, 2024, 01:26:18 am by Pecan »

Offline Miguel Gimenez

  • Developer
  • Lives here!
  • *****
  • Posts: 1644
Re: [Solved] Distracting SymbolBrowser Behaviour
« Reply #18 on: January 23, 2024, 09:09:01 am »
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.

Offline sodev

  • Lives here!
  • ****
  • Posts: 500
Re: [Solved] Distracting SymbolBrowser Behaviour
« Reply #19 on: January 23, 2024, 07:06:16 pm »
That makes sense, i didn't take the dangerous Yield() into account.

Offline Pecan

  • Plugin developer
  • Lives here!
  • ****
  • Posts: 2813
Re: [Solved] Distracting SymbolBrowser Behaviour
« Reply #20 on: January 26, 2024, 08:59:50 pm »
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

Offline tigerbeard

  • Almost regular
  • **
  • Posts: 196
Re: [Solved] Distracting SymbolBrowser Behaviour
« Reply #21 on: January 30, 2024, 12:04:29 pm »
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.

Offline Miguel Gimenez

  • Developer
  • Lives here!
  • *****
  • Posts: 1644
Re: [Solved] Distracting SymbolBrowser Behaviour
« Reply #22 on: January 31, 2024, 02:02:23 pm »
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.
« Last Edit: January 31, 2024, 03:52:21 pm by Miguel Gimenez »

Offline Pecan

  • Plugin developer
  • Lives here!
  • ****
  • Posts: 2813
Re: [Solved] Distracting SymbolBrowser Behaviour
« Reply #23 on: January 31, 2024, 04:35:58 pm »
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.

Offline Pecan

  • Plugin developer
  • Lives here!
  • ****
  • Posts: 2813
Re: [Solved] Distracting SymbolBrowser Behaviour
« Reply #24 on: January 31, 2024, 05:19:41 pm »
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

Offline Miguel Gimenez

  • Developer
  • Lives here!
  • *****
  • Posts: 1644
Re: [Solved] Distracting SymbolBrowser Behaviour
« Reply #25 on: January 31, 2024, 06:02:51 pm »
It works now, thank you.