Re: Crashes on file deletion

  • From: <tpgww@xxxxxxxxxxx>
  • To: emelfm2@xxxxxxxxxxxxx
  • Date: Tue, 31 Mar 2009 12:55:18 +1100

On Sat, 28 Mar 2009 14:23:35 +0000
Geoff <capsthorne@xxxxxxxxxxx> wrote:

> Hello Tom,
> 
> Quite a while since I had reason to post here.
> 
> I run self-compiled emelfm2 under Arch Linux these
> days, which has behaved perfectly for the past 18 months or
> more.  I am using currently using Org X Server 1.5.3 and
> emelfm2 0.5.1 compiled with USE_INOTIFY=1 USE_LATEST=1
> 
> I update Arch itself daily, and today the following package
> upgrades installed.
> 
> atk (1.24.0-1 -> 1.26.0-1)
> randrproto (1.2.2-1 -> 1.3.0-1)
> libxrandr (1.2.3-1 -> 1.3.0-1)
> pango (1.22.4-1 -> 1.24.0-1)
> gtk2 (2.14.7-2 -> 2.16.0-1)
> 
> emelfm2 is now crashing when I select files to delete.  I
> can't establish a clear pattern but apart from one occasion
> when the program froze and had to be killed, and one when
> the delete confirmation window appeared, but contained no
> text : I am seeing :
> 
> emelfm2: Fatal IO error 11 (Resource temporarily
> unavailable) on X server :0.0
> 
> or
> 
> Xlib: sequence lost (0x121df > 0x2261) in reply type 0x0!
> The program 'emelfm2' received an X Window System error.
> This probably reflects a bug in the program.
> The error was 'RenderBadPicture (invalid Picture
> parameter)'. (Details: serial 8672 error_code 178
> request_code 154 minor_code 5) (Note to programmers:
> normally, X errors are reported asynchronously; that is,
> you will receive the error a while after causing it. To
> debug your program, run it with the --sync command line
> option to change this behavior. You can then get a
> meaningful backtrace from your debugger if you break on the
> gdk_x_error() function.) The program 'emelfm2' received an
> X Window System error. This probably reflects a bug in the
> program. The error was 'BadDrawable (invalid Pixmap or
> Window parameter)'. (Details: serial 8671 error_code 9
> request_code 154 minor_code 4) (Note to programmers:
> normally, X errors are reported asynchronously; that is,
> you will receive the error a while after causing it. To
> debug your program, run it with the --sync command line
> option to change this behavior. You can then get a
> meaningful backtrace from your debugger if you break on the
> gdk_x_error() function.)
> 
> Sometimes I can succeed in deleting a single file, but a
> group delete crashes every time.
> 
> I am, of course, happy to supply more information, run
> tests etc.

This is the sort of error message I associate with more than 1 (parallel) 
attempt to update the screen. There are supposed to be blocks in place to 
prevent this happening.

It could be that gtk 2.16 does something badly (e2 uses threads more than many 
apps, and will show up any weakness). Or perhaps gtk 2.16 just works 
differently, and so unmasks something that emelfm2 is doing badly. But we did 
look into thread locking quite a bit in times past.

I can't check any of this ATM, but meantime, can you confirm that your lockup 
is not delete-specific i.e. happens with, say, changing a bunch of items' 
permissions, or moving a bunch of items, or even copying a bunch.

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: