Since the 8 Feb. update photoflow crash with signal 11 upon any image closing

[pmo-19]

As it looks like my e-mails from yesterday have been overlooked. The Git version from yesterday and today crash with signal 11 caught from closing any open image.

~ImageEditor(): image deleted

(photoflow:13632): Gtk-CRITICAL **: IA__gtk_label_set_text: assertion 'GTK_IS_LABEL (label)' failed

(photoflow:13632): Gtk-CRITICAL **: IA__gtk_widget_queue_draw: assertion 'GTK_IS_WIDGET (widget)' failed Error: signal 11: photoflow(_Z7handleri+0x18)[0x657ff8] /lib/x86_64-linux-gnu/libc.so.6(+0x36d40)[0x7f80ebfa2d40] /usr/lib/x86_64-linux-gnu/libgtkmm-2.4.so.1(_ZN3Gtk8TreeView13get_selectionEv+0xc)[0x7f80eed100fc] photoflow(_ZN2PF9LayerTree21get_selected_layer_idEv+0x25)[0x66f1e5] photoflow(_ZN2PF11LayerWidget9updatecbEPS0+0x45)[0x72b9b5] /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0(+0x1dce7)[0x7f80ed823ce7] /lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_context_dispatch+0x135)[0x7f80ef9dace5] /lib/x86_64-linux-gnu/libglib-2.0.so.0(+0x49048)[0x7f80ef9db048] /lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_loop_run+0x6a)[0x7f80ef9db30a] /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0(gtk_main+0xa7)[0x7f80ee2c0447] memory: 54 allocations, 2153394 bytes files: 0 open memory: high-water mark 10.91 MB $

[aferrero2707]

I confirm the crash, and today I have committed a fix that should solve this issue (see https://github.com/aferrero2707/PhotoFlow/commit/5b564e61ed0eae2d433304354c7c643d50f17660).

Could you confirm that things work correctly for you as well?

Thanks!

[pmo-19]

Sorry, but this did not solve anything. Photoflow is still crashing. Beside that, there is a convenience bug when I open an image and photoflow is not maximized. Right after I open another image. Right after I maximize photoflow the currently viewed image is maximized (ok) but when switch to the 1st opened image it is still minimized. And going min / maxi on photoflow won't change its behaviour as well. If I open a third image then the 3td is ok but the second will stay minimized ... The state maximize / minimize for the app is not seen as a global variable when viewing images ...

~ImageEditor(): image deleted

(photoflow-unstable:29970): Gtk-CRITICAL **: IA__gtk_label_set_text: assertion 'GTK_IS_LABEL (label)' failed

(photoflow-unstable:29970): Gtk-CRITICAL **: IAgtk_widget_queue_draw: assertion 'GTK_IS_WIDGET (widget)' failed Error: signal 11: photoflow-unstable(_Z7handleri+0x18)[0x657aa8] /lib/x86_64-linux-gnu/libc.so.6(+0x36d40)[0x7f55c0189d40] photoflow-unstable[0x657dc4] /lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_context_dispatch+0x135)[0x7f55c3bc1ce5] /lib/x86_64-linux-gnu/libglib-2.0.so.0(+0x49048)[0x7f55c3bc2048] /lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_loop_run+0x6a)[0x7f55c3bc230a] /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0(gtk_main+0xa7)[0x7f55c225c447] /usr/lib/x86_64-linux-gnu/libgtkmm-2.4.so.1(_ZN3Gtk4Main3runERNS_6WindowE+0xfd)[0x7f55c2e9e32d] photoflow-unstable(main+0x4e5)[0x64e495] /lib/x86_64-linux-gnu/libc.so.6(libc_start_main+0xf5)[0x7f55c0174ec5] 82 objects alive: 0) VipsRegion (0x7f5558007ac0), count=1 VipsRegion (object), base class, VipsRegion: 0x7f5558007ac0, im = 0x7f55ad774960, left = 0, top = 0, width = 0

[pmo-19]

Today I made the update for the stable photoflow package and it looks like my adaptative patch is working. Both stable and unstable can be used at the time. While testing their behaviour I can confirm that the crash on closing an image bug is quite ancient as it is as well in the stable release 0.2.5 if you open more than one image. While in the unstable version the closing image bug appears with only one image open ... since last Monday Feb., 8th modifications. The unstable build from Feb. 7th did not crash with only one image, but probably behaved like the stable build 0.2.5 (quite old now). At one point the stable build 0.2.5 crashed with SIGABRT in libc-2.19.so I can confirm the bug is still there in release 0.2.4 as well. Another convenience bug is that the 'recently used' is not updated in real time. If the app crash then all history is lost.

[aferrero2707]

The remaining crash when closing image tabs was due to a missing return value from a GTK idle callback. This is hopefully finally solved in the current stable branch.

I will look into the other issues and suggestions during the next days.

[pmo-19]

OK. The crash bug is now corrected. Thanks. However, the maximize / minimize still apply only to one image (the open image while performing maximize Photo Flow main window). I understand you will look at that later on. Then in addition to the other "convenience" bugs, following a crash Photo Flow offers to recover the image (nice capability), but it then set the image as "changed" with a wildcard char * in its tab header and upon closing ask for saving the changes. That should not occur since the user didn't change anything. Photo Flow may only have restored its cache. This is the only change in cache which should not be deemed a change actually. Another new "convenience" bug: If you open the same image twice then upon opening the second in another tab, Photo Flow offers to recover it from a crash ... This should not happen. Then when closing one everything goes fine but when closing the other the processing rectangle stays red forever as the cache just disappeared I imagine. Photo Flow should keep a tab of open images and direct the user to the corresponding already open tab ? Or open it as a separate file in the cache and force to save with a different name and of course warn the user ? But I don't see the advantage of opening 2 times the same file in different tabs ...

[pmo-19]

Another convenience would be to change the color of the button icons as black on black is visually poor. The ideal would be one set of icon for dark themes and one set for light themes. The switch may be made somewhere in the configuration and may be automatic when switching theme. The same goes for the image(s) tab(s) title name(s) and closing X.

[pmo-19]

And I will finish with one question: Where do you set the title name of the main window ? As I realize I will need to add a patch to change its name to Photo Flow Git or Photo Flow Unstable. Thanks. I found the set_title in mainwindow.cc and I will update my adaptative patch tomorrow.

[pmo-19]

New side effect bug following yesterday crash bug correction. The first time I open an image in Photo Flow (i.e. the first opened image) I get a small image. Either closing and reopening or closing altogether Photo Flow and relaunching it will open the image in full frame. If I fully restart the system then the bug reappears on the first image opening. That was not occurring before. See the screen captures.

[aferrero2707]

pmo-19: concerning the bug in the preview image size, I'm aware of that and I'm still fighting with the GTK logic to properly fit the image to screen at program start-up. I plan to fix that once for all before next official release.

Concerning the email exchange you are mentioning in your last post, this is really not the place for such a discussion, because:

1. it has nothing to do with the bugs that are reported and followed in this issue
2. the rest of the readers don't have the least idea what we are talking about

Therefore I decided to remove the comment and I propose that we continue the discussion in a closed circle, like it was started.

[aferrero2707]

Most of the issues are fixed in stable branch.

The issue when opening the same image twice has been moved in a separate report.