Re: still crashes on file deletion?

On Sat, 6 Jun 2009 01:40:06 +0200
aryah <aryah47@xxxxxxxxx> wrote:

> On Sat, Jun 06, 2009 at 08:27:01AM +1000, tpgww@xxxxxxxxxxx wrote:
> > On Fri, 5 Jun 2009 23:35:47 +0200
> > Yes, there has been no other report of any problem of that sort, with 0.6.0.
> > 
> > I'm not familiar with the details of 'Debian testing' - which gtk ? which 
> > xorg ?
> 
> Its a rolling release, at this moment:
> libgtk is marked as version 2.16.1-2 , libx11 2:1.2.1-1 , of other 
> dependencies mentioned on the homepage, gcc is 4.1.2-25, file is 5.03-1 

OK, nothing obvious there. Problems in the recent past were due to some change 
in gtk 2.16, but emelFM2 0.6 has now been tested on gtk 2.16.[012], and with 
later X than 1.2. I haven't used gcc 4.1 for a while, but it was never an issue 
in the past.

The sort of problem you initially reported arises from parallel usage of the X 
backend. Such usage is supposed to be prevented by a mutex ('lock', if you 
like). Reading around a bit, I get a sniff that eglibc mutex arrangements may 
not be the same as in other libc's. If that turns out to be true, and it's not 
fixed to become posix-compliant, well then there's not much we can do to help.

For now, a couple of things can be tried:

1. a fresh build with [additional] make option DEBUG=1.
This changes the mutex type to one that detects some inappropriate usage, and 
error messages will be sent to the terminal in that case. However, if there's a 
problem with the normal (recursive) mutex, the error-check mutex may not work 
either.

2. in file emelfm2.h, at line 678 or thereabouts, is:
//#define NATIVE_BGL
Do a fresh build with that line un-commented. This will revert to gtk's 
standard form of mutex, which can cause a UI freeze in certain circumstances, 
but which may otherwise provide indication (i.e. different failure(s)) that the 
mutex is the cause of the problem. Again, I'd build with DEBUG=1 and run from a 
terminal.

Regards
Tom


-- 
Users can unsubscribe from the list by sending email to 
emelfm2-request@xxxxxxxxxxxxx with 'unsubscribe' in the subject field or by 
logging into the web interface.

Other related posts: