Project

General

Profile

Bug #9682

GUI stops responding after lua callback is triggered

Added by Attila Gróf over 5 years ago. Updated over 5 years ago.

Status:
Fixed
Priority:
Medium
Category:
Lua
Start date:
11/19/2013
Due date:
% Done:

100%

Affected Version:
git development version
System:
Ubuntu
bitness:
64-bit
hardware architecture:
amd64/x86

Description

To reproduce the bug

  • Add the 'select images with given color label' example from the blog to the
    ~/.config/darktable/luarc
    .
  • Assign a shortcut
  • Import more than 15 images
  • mark several images with red color label
  • Activate the callback with the shortcut

Symptoms

Darktable stops responding: none of the GUI elements respond, window refreshing does not work.
'killall darktable' or <CTRL-C> (if started from terminal) the only way to quit.

uname -a: Linux L-teszt 3.11.0-13-generic #20-Ubuntu SMP Wed Oct 23 07:38:26 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
darktable version: 1.3+1389~gc83cc58

Associated revisions

Revision d57c3a1c
Added by Jérémy Rosen over 5 years ago

lua : fix bug #9682

we properly release the lua lock and take the gtk lock
when updating the selection

Revision 78e4df7f
Added by Jérémy Rosen over 5 years ago

lua : fix bug #9682 in the single cpu case

some functions take the gdk lock implicitely.
we need to release the lua lock before calling them

History

#1 Updated by Jérémy Rosen over 5 years ago

  • Status changed from New to In Progress
  • % Done changed from 0 to 50

I can't reproduce what you describe... I don't see a freez but a crash (which is worse)

can you reproduce with today's git ? there have been some recent changes in the way lua deals with the gui thread...

#2 Updated by Jérémy Rosen over 5 years ago

note to self :

lua uses dt_selection_toggle to set the image, each call to this function tries to update a hint message which assumes that the gdk lock is held.

I need to implement a new dt_selection_set(glist*) function that would set the list without updating the hint.

#3 Updated by Attila Gróf over 5 years ago

I used virtualbox VM with a single CPU for the initial test.

In this round:
  • I have updated to the latest version (1.3+1413~g722fd01) from the unstable repository.
  • It worked fine with 40+ images in the database with 4 CPUs in the virtual machine.

I have also executed tests with 5500 images in the DB.
4 CPU VM: worked fine.
Single CPU VM: The callback function was completed and the GUI is responsive while the callback function is running (I have added dt.print_error to the loop to print an attribute for each image, therefore the callback execution lasts for cca 30 secs). Darktable freezes after the callback function is completed.

It crashed only once for me with the single CPU VM. Darktable printed an error message that it is not able to start gdb right before the crash. It also claimed that a backtrace file in /tmp was created, however there was no such file. I use the default core dump settings of lubuntu which is 'no core dump' as far as I know.

#4 Updated by Jérémy Rosen over 5 years ago

ok. I have found the bug that causes the crash and I will submit a fix soon. Once this is fixed we will see if it also fixes the freeze.

I'll get back to you at this point

#5 Updated by Jérémy Rosen over 5 years ago

Ok, I've commited a fix...

could you please test if that fixes your problem and report back so I can close the bug ? thx

#6 Updated by Attila Gróf over 5 years ago

'>1 CPU core case': works fine
'1 CPU core case': first activation of the callback works fine. GUI remains responsive. Second activation of the callback causes the GUI to freeze.

The single CPU case should not prevent from closing this bug.

#7 Updated by Attila Gróf over 5 years ago

Build used for testing: 1.3+1420~gd57c3a1

#8 Updated by Jérémy Rosen over 5 years ago

note to self:

the single CPU case can be reproduced with

taskset -c 0 ./darktable.sh

#9 Updated by Jérémy Rosen over 5 years ago

Ok, I have fixed that for the single CPU case.

the single cpu case was actually triggering something serious but hard to trigger with multiple CPU, thx for reporting it

could you confirm that everything is fine with latest git on your side ?

after that i'll close the bug

#10 Updated by Attila Gróf over 5 years ago

The sinlge CPU case works fine now with build 1.3+1448~gd13f981.
Thanks for the quick fix.

#11 Updated by Jérémy Rosen over 5 years ago

  • % Done changed from 50 to 100
  • Status changed from In Progress to Fixed

Also available in: Atom PDF