problems with filemanager plugin

[frithjofh]

Hi everybody,

I recently erased all files pertaining to my c::b setup, did a clean checkout of the svn sources, and then recompiled c::b.

The version is svn9673, and I am running it under OpenSuSe 13.1. AMD machine with 4 processors.

I observed that c:b started alright and worked as expected, but when shutting it down closed the window but leaving a process behind which consumed 99% CPU and had to be killed in console.

I could narrow this down to the filemanager plugin as culprit. I had to edit the config file of c::b setting the bool to zero making c::b not load this particular plugin. Then c::b starts and works and shuts down as should be.

Starting c::b now is running it with filemanager plugin disabled. Now I can enable it without problem, but when I try to disable it again, I get random results from c::b between crashing directly or entering a loop (making it necessary to kill the whole process). I tried to debug it, but in debug mode everything seems to work just fine, I could never reproduce neither crash nor infinite loop.

On one crash I obtained a crash report, which I attach. Mostly the process just crashes without report or hangs in loop and doesn't even save its settings if changes had been made.

I suppose filemanager has some serious problem. glibc is of version 2.17-4.7.1 on my system.

Regards

frithjofh

[oBFusCATed]

Search the forum for gamin or famin, the problem is there if I remember correctly.

[dmoore]

You need to install (lib)gamin. One of these days I will convert it over to inotify.

[Jenna]

Here is a snippet of frithjofh's debug-report:

    <module path="/usr/lib64/libgamin-1.so.0.1.10" address="7fdebb7b0000" size="00007000" version="0.1.10"/>
    <module path="/usr/lib64/libgamin-1.so.0.1.10" address="7fdebb9b7000" size="00001000" version="0.1.10"/>

It looks like libgamin is installed.

[dmoore]

maybe needed gamin-devel when he compiled?

[Jenna]

maybe needed gamin-devel when he compiled?

I don't think it compiles without gamin-devel, but I do not remember if I ever tried it.

[dmoore]

maybe needed gamin-devel when he compiled?

I don't think it compiles without gamin-devel, but I do not remember if I ever tried it.

It shouldn't but wonder if there are conflicting versions or something.

[Jenna]

fam-devel would possibly also work (if it still exists Fedora only provides gamin these days), but libfam and libgamin can not be installed at the same time as far as I know.

[frithjofh]

hi, and thanks for the replies,

it turns out, I have libgamin installed with version 0.1.10-4.4.1 . Also gamin-devel and libfam0-gamin both with the same version number.

These packages were installed prior to compiling and installing c::b.

When I try to deinstall libfam, the system complains about gamin-devel depending on it. So I left it as is.

Regards

frithjofh

[frithjofh]

hi,

to whom it may concern:

I looked into the source and think that the problem is in the file dirctorymonitor.cpp in the destructor of DirMonitorThread. The hang definitively takes place on the line where Wait() is called on the wxThread.

So I read about wxThread, and after finding the hint that POSIX threads need the function TestDestroy() to be called on a wxThread object before Pause() or Delete() I assumed, that same might be true for Wait() on POSIX threads, so I added TestDestroy() to the conditional statement which triggers the Wait() command.

This certainly does it on Linux. The hangs or crashes are gone, no zombies left over.

I didn't make a patch, because I am not very experienced in threads and want to put the decision up to the maintainer.

Regards

frithjofh

[oBFusCATed]

Please post a patch, so we can discuss it.

[dmoore]

+1 Sounds like a plausible solution, so please post a patch.

[frithjofh]

tomorrow. have to understand some loose ends first... 

[dmoore]

Nevermind, I think I can just replace the code with a mutex.

EDIT: Code needs a much bigger overhaul but try this patch for linux -- untested, may not even compile...

[dmoore]

should probably do something similar for windows, though oddly the same wait code doesn't fail.