Hm, exo is 4.16.0, not 4.16.1, I will try to update it.
Backtrace:
[user@rosa2019 ~]$ gdb --args thunarGNU gdb (GDB) 9.0.90-1 (ROSA Desktop Fresh R12 release 2019.1)<...>Reading symbols from thunar...Reading symbols from /usr/lib/debug/usr/bin/thunar-4.16.6-1.x86_64.debug...(gdb) runStarting program: /usr/bin/thunar [Thread debugging using libthread_db enabled]Using host libthread_db library "/lib64/libthread_db.so.1".[New Thread 0x7ffff5c55640 (LWP 18722)][New Thread 0x7ffff5454640 (LWP 18723)][New Thread 0x7fffeffff640 (LWP 18724)][New Thread 0x7fffef7fe640 (LWP 18725)][Thread 0x7fffef7fe640 (LWP 18725) exited][New Thread 0x7fffef7fe640 (LWP 18727)](thunar:18718): thunar-WARNING **: 10:58:32.138: Имя "org.freedesktop.FileManager1" потеряно в сообщении dbus.[Thread 0x7fffeffff640 (LWP 18724) exited]**Gtk:ERROR:gtkcellrenderer.c:1796:gtk_cell_renderer_get_aligned_area: assertion failed: (aligned_area->x >= cell_area->x && aligned_area->x <= cell_area->x + cell_area->width)Bail out! Gtk:ERROR:gtkcellrenderer.c:1796:gtk_cell_renderer_get_aligned_area: assertion failed: (aligned_area->x >= cell_area->x && aligned_area->x <= cell_area->x + cell_area->width)Thread 1 "thunar" received signal SIGABRT, Aborted.0x00007ffff6f07397 in raise () from /lib64/libc.so.6(gdb) bt#0 0x00007ffff6f07397 in raise () at /lib64/libc.so.6#1 0x00007ffff6eed538 in abort () at /lib64/libc.so.6#2 0x00007ffff70e7dcc in g_assertion_message_expr.cold () at /usr/lib64/libglib-2.0.so.0#3 0x00007ffff714501b in g_assertion_message_expr () at /usr/lib64/libglib-2.0.so.0#4 0x00007ffff789cde7 in gtk_cell_renderer_get_aligned_area () at /usr/lib64/libgtk-3.so.0#5 0x00007ffff7f7788b in exo_icon_view_calculate_item_size.part () at /usr/lib64/libexo-2.so.0#6 0x00007ffff7f7838c in exo_icon_view_layout () at /usr/lib64/libexo-2.so.0#7 0x00007ffff7f7896c in layout_callback () at /usr/lib64/libexo-2.so.0#8 0x00007ffff7677dd9 in gdk_threads_dispatch () at /usr/lib64/libgdk-3.so.0#9 0x00007ffff711ca8f in g_main_context_dispatch () at /usr/lib64/libglib-2.0.so.0#10 0x00007ffff711ce38 in g_main_context_iterate.constprop () at /usr/lib64/libglib-2.0.so.0#11 0x00007ffff711ceef in g_main_context_iteration () at /usr/lib64/libglib-2.0.so.0#12 0x00007ffff7332495 in g_application_run () at /usr/lib64/libgio-2.0.so.0#13 0x0000000000420932 in main (argc=1, argv=0x7fffffffd948) at main.c:86(gdb)
Maybe we have to prepare our aligned_area in some way before feeding it into gtk_cell_renderer_get_aligned_area, so that we can pass that assertion (allign_area as sub-area of cell_area)? Currently we just feed it with some empty aligned_area (code).
However, that would be strange, since the purpose of the method actually is to fill the aligned_area. So it makes perfect sense to pass an uninitialized variable. Possibly we should check the related gtk code.
/* Default implementation assumes that a cell renderer will never use more * space than its natural size (this is fine for toggles and pixbufs etc * but needs to be overridden from wrapping/ellipsizing text renderers) */static voidgtk_cell_renderer_real_get_aligned_area ( ...
Problem could be, that we use the default renderer for wrapping/ellipsizing. At least it looks like exo only uses a custom renderer for icons. Possibly we have to add another renderer.
On the other side, I would expect more frequent crashes (or at least CTK-CRITICALS) in that case.
Thread 1 "thunar" hit Breakpoint 1, exo_icon_view_calculate_item_size (icon_view=icon_view@entry=0xc5c3e0, item=item@entry=0x97a700) at exo-icon-view.c:35713571 gtk_cell_renderer_get_aligned_area (info->cell, GTK_WIDGET (icon_view),(gdb) p cell_area$218 = {x = 2147483647, y = 0, width = 97, height = 22}(gdb) p aligned_area$219 = {x = 12960736, y = 0, width = 0, height = 0}(gdb) cContinuing.**Gtk:ERROR:gtkcellrenderer.c:1796:gtk_cell_renderer_get_aligned_area: assertion failed: (aligned_area->x >= cell_area->x && aligned_area->x <= cell_area->x + cell_area->width)Bail out! Gtk:ERROR:gtkcellrenderer.c:1796:gtk_cell_renderer_get_aligned_area: assertion failed: (aligned_area->x >= cell_area->x && aligned_area->x <= cell_area->x + cell_area->width)Thread 1 "thunar" received signal SIGABRT, Aborted.0x00007ffff6f07397 in raise () from /lib64/libc.so.6
So, yes, it looks like sth like "more space than its natural size"
But what is it? Is it calculation for some icons? What is the easiest way to track which icon it is?
Note for myself:
$ sleep 5; while true; do xdotool key p; xdotool key space; for i in c e l l underscore a r e a ; do xdotool key $i ; done; xdotool key KP_Enter; xdotool key p; xdotool key space; for i in a l i g n e d underscore a r e a ; do xdotool key $i ; done; xdotool key KP_Enter; xdotool key c ; xdotool key KP_Enter; done
But what is it? Is it calculation for some icons? What is the easiest way to track which icon it is?
My assumption would be, that it is not an icon, but a wrapped text-string which causes the crash .. though that is just an assumption. And it does not explain well why that crash happens for you while you type something into the URL bar.
Maybe it only happens for specific folders for you? Possibly file-names are wrapped there ?
Maybe it only happens for specific folders for you? Possibly file-names are wrapped there ?
Well, I can type either a local file name or start typing: "sftp://...", type: "sf", and it crashes. In other cases it crashes in other moments. Also seems that there is a microfreeze before crash. I saw that freeze in gdb better than without it.
@alexxcons How can the exact answer be found via debugger?
I dont know it the debugger can be of help here. Sure, you can do gdb thunar/thunar in the source folder and add a breakpoint in the method above exo_icon_view_calculate_item_size. But that most likely will only show what we already know.
If I would be able to reproduce, I rather would try to disable URL bar features one by one. E.g: Does it as well crash without auto-complete ? Put a printf in all the callbacks of thunar-path-entry, to see which methods are triggered while writing letters.
I tried to reproduce this bug, and while I couldn't reproduce the crash, typing an URL did make thunar freeze for a moment. (I typed https://google.com and thunar freezes after https://.) Maybe freezing and crash is a different issue triggered by similar situation.