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

crash on close cbp project (rev 7773)

<< < (5/6) > >>

thomas:

--- Quote from: MortenMacFly on February 05, 2012, 05:00:45 pm ---alternatively the first macro can expand to "{ wxMutexLocker(BLAH)" and the second to "}".
--- End quote ---
*closes eyes as Morten opens Pandora's box*  8)

Hopefully we don't ever declare a local variable somewhere after a CC_LOCK then. Well, the world ends in 2012 anyway, so let's not worry.  ;D

But yeah, I see it like you... the scoping is not at all an issue. Usually you lock exactly once per function, so it's clear anyway. And where that isn't the case, you want to have an extra pair of curly braces either way, to make the intent clear. And lastly, hopefully you'll get rid of 90% of these locks (which is the entire point).

Jenna:
In svn r7785 I fixed a possible crash in the layout-managers update routine, if the classbrowser is set to floating (and not integrated in the management-pane.
This happened due to an error in the refactoring in r7767, where a local variable hides the member-variable.

I also removed all calls of TestDestroy(), because they are only needed with Delete ( which can/should not be used for joinable threads ) and added a termination request therefore.
Without this request the call to semaphore->Post() in the classbrowser dtor awakes the builderthread for exactly one time, it loops through the Entry-functions and reaches the wait-state again, without termination.
A call of the  Wait()-function of the builderthread, did never return in this case.
We also did not delete the thread-object on the heap, what can cause a memory-leak.
This might also fix crashes on shutdown that occured from time to time since some revisions.

ollydbg:
There are a lot of TestDestroy() in Parserthread.cpp(In IS_ALIVE macro), should they be deleted too?

Jenna:

--- Quote from: ollydbg on February 09, 2012, 02:11:28 pm ---There are a lot of TestDestroy() in Parserthread.cpp(In IS_ALIVE macro), should they be deleted too?

--- End quote ---

No, because ParserThread is derived from cbThreadedTask, which has an own implementation of TestDestroy() .

MortenMacFly:

--- Quote from: jens on February 09, 2012, 09:06:46 am ---Without this request the call to semaphore->Post() in the classbrowser dtor awakes the builderthread for exactly one time, it loops through the Entry-functions and reaches the wait-state again, without termination.

--- End quote ---
That was a good one, a relict from my trials to remove calling "directly" into the thread from the class browser UI. I had in mind to (and actually did) provide the builder thread with a job queue so that the class browser attaches jobs as needed and once they are done the UI event is fired up again if signalled from the thread. However, this didn't work reliable. My second thought was to move the UI parts out f the thread to the class browser (where they belong to) and send events every time as needed. But also this didn't work well due to the fact, that wxTreeCtrl events need to be allowed (event.Allow()) in time to be processed correctly. So if you hit a plus (to expand a tree item) "too fast" you ended up in a race condition. I gave up for the moment (due to other stuff) but I still don't like the implementation of the class browser as it is in the moment...

Navigation

[0] Message Index

[#] Next page

[*] Previous page