Segmentation Fault when starting Code

[lobre]

What Happened?

I have tried to do a global search, and then the application crashed. And now, each time I try to start it again, it crashes again at boot.

Here is the log when trying to start it with the terminal.

$ io.elementary.code 

(io.elementary.code:39416): Gdk-CRITICAL **: 17:58:56.994: gdk_wayland_window_set_dbus_properties_libgtk_only: assertion 'GDK_IS_WAYLAND_WINDOW (window)' failed
*** BUG ***
In pixman_region32_init_rect: Invalid rectangle passed
Set a breakpoint on '_pixman_log_error' to debug

*** BUG ***
In pixman_region32_init_rect: Invalid rectangle passed
Set a breakpoint on '_pixman_log_error' to debug

*** BUG ***
In pixman_region32_init_rect: Invalid rectangle passed
Set a breakpoint on '_pixman_log_error' to debug

*** BUG ***
In pixman_region32_init_rect: Invalid rectangle passed
Set a breakpoint on '_pixman_log_error' to debug

*** BUG ***
In pixman_region32_init_rect: Invalid rectangle passed
Set a breakpoint on '_pixman_log_error' to debug

*** BUG ***
In pixman_region32_init_rect: Invalid rectangle passed
Set a breakpoint on '_pixman_log_error' to debug

*** BUG ***
In pixman_region32_init_rect: Invalid rectangle passed
Set a breakpoint on '_pixman_log_error' to debug

*** BUG ***
In pixman_region32_init_rect: Invalid rectangle passed
Set a breakpoint on '_pixman_log_error' to debug

*** BUG ***
In pixman_region32_init_rect: Invalid rectangle passed
Set a breakpoint on '_pixman_log_error' to debug

*** BUG ***
In pixman_region32_init_rect: Invalid rectangle passed
Set a breakpoint on '_pixman_log_error' to debug


(io.elementary.code:39416): Gtk-CRITICAL **: 17:58:57.244: gtk_widget_queue_draw_area: assertion 'width >= 0' failed

(io.elementary.code:39416): Gtk-CRITICAL **: 17:58:57.244: gtk_widget_queue_draw_area: assertion 'width >= 0' failed

(io.elementary.code:39416): Gtk-CRITICAL **: 17:58:57.244: gtk_widget_queue_draw_area: assertion 'width >= 0' failed
Segmentation fault (core dumped)

Steps to Reproduce

Mess with search and then just try to start the editor.

Expected Behavior

Not crash.

OS Version

8.x (Circe)

OS Architecture

amd64 (on most hardwares)

Session Type

Secure Session (Wayland)

Software Version

Latest release (I have run all updates)

Log Output

Hardware Info

No response

[jeremypw]

Does this also occur with X11 (Classic) session?

I get "Invalid rectangle passed" and "queue_draw_area" messages (usually when closing tabs) but I am pretty sure those are an upstream issue as they are not limited to Code.

If you are able to run Code under gdb and post the backtrace when it crashes here, that would be helpful.
You can get further info here: https://docs.elementary.io/contributor-guide/feedback/reporting-issues/inspecting-crashes

[jeremypw]

I recently noticed a crash caused by the Vala symbol pane under some conditions. see #1355

In order to get Code to run again try the following:

• Open dconf-editor - available in the AppCenter
• Change the setting io/elementary/code/settings/open-files to [] (default value)
• Change the setting io/elementary/code/settings/plugins-enabled to []
• Change the setting io/elementary/code/folder-manager/opened-folders to []

If Code then runs turn off the Vala symbol panel in the AppMenu.

You should then be able to gradually re-activate documents and features to narrow down what is causing the problem

[jeremypw]

Unfortunately I am not sure the Vala symbol panel is fixable here (apart from by avoiding some code structures) - last time I looked into it I concluded it is an upstream issue

[lobre]

Hey, sorry for the delay, trying to retrieve information about the crash.

So far, I have opened the application with gdb io.elementary.code, and then, I try a global search with the keyword test and click Search.

And here, the editor does not respond anymore (I do have the dialogue saying that the application does not seem to answer, and asking if I want to force quit).

And I see in the gdb output that there is this:

Thread 1 "io.elementary.c" received signal SIGSEGV, Segmentation fault.
0x000055555559d449 in scratch_folder_manager_folder_item_get_loading_required ()

Doing backtrace at that point just repeats the last line.

[lobre]

Also, the crash happens exactly the same way in the "Classic Session".

[jeremypw]

You need to do bt before quitting the Code app to get a full trace - so ignore the dialog. You can quit both the app and gdb by typing q and y into gdb. Thanks for investigating. It looks like something different from the crash I mentioned. I don't recall ever getting a crash with global search so maybe depends on the docs being searched. Could you try closing most docs and seeing whether it happens with all docs or only some of them open.

[jeremypw]

The error you reported appears to be something to do with the sidebar - one of the items is "abnormal" somehow.

[lobre]

Thanks for you feedback, I had little time yesterday to try to find out more about what was happening. I will continue today and share here.

I managed to get a more complete backtrace if that already helps a little more.

Thread 1 "io.elementary.c" received signal SIGSEGV, Segmentation fault.
0x000055555559d449 in scratch_folder_manager_folder_item_get_loading_required ()
(gdb) bt
#0  0x000055555559d449 in scratch_folder_manager_folder_item_get_loading_required ()
#1  0x00005555555a03b2 in scratch_folder_manager_folder_item_load_children ()
#2  0x00005555555a05f9 in ??? ()
#3  0x00005555555a061a in ??? ()
#4  0x00005555555a0642 in ??? ()
#5  0x00005555555ab259 in ??? ()
#6  0x00005555555ab360 in ??? ()
#7  0x00007ffff6061c6c in git_status_foreach_ext
    (repo=<optimised out>, opts=opts@entry=0x555556fe82d0, cb=cb@entry=0x5555555ab2a0, payload=payload@entry=0x5555560218d0)
    at /usr/src/libgit2-1.7.2+ds-1ubuntu3/src/libgit2/status.c:443
#8  0x00007ffff7014d25 in ggit_repository_file_status_foreach
    (repository=0x555556002690, options=<optimised out>, callback=0x5555555ab2a0, user_data=0x5555560218d0, error=0x7fffffffc200)
    at ../libgit2-glib/ggit-repository.c:1307
#9  0x00005555555abd6d in scratch_folder_manager_project_folder_item_global_search ()
#10 0x00005555555a1a31 in scratch_folder_manager_file_view_search_global ()
#11 0x000055555558e5e0 in ??? ()
#12 0x00007ffff7c3a2fa in g_closure_invoke () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#13 0x00007ffff7c6990c in ??? () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#14 0x00007ffff7c5a591 in ??? () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#15 0x00007ffff7c5a7c1 in g_signal_emit_valist () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#16 0x00007ffff7c5a883 in g_signal_emit () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#17 0x00007ffff7d76be5 in ??? () at /lib/x86_64-linux-gnu/libgio-2.0.so.0
#18 0x00007ffff7d6a5bf in g_action_activate () at /lib/x86_64-linux-gnu/libgio-2.0.so.0
#19 0x00007ffff72d978f in ??? () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#20 0x00007ffff7c5a6bd in ??? () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#21 0x00007ffff7c5a7c1 in g_signal_emit_valist () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#22 0x00007ffff7c5a883 in g_signal_emit () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#23 0x00007ffff72daf08 in ??? () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#24 0x00007ffff7c5a6bd in ??? () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#25 0x00007ffff7c5a7c1 in g_signal_emit_valist () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#26 0x00007ffff7c5a883 in g_signal_emit () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#27 0x00007ffff72daccd in ??? () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#28 0x00007ffff7299b43 in ??? () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#29 0x00007ffff7c5a6bd in ??? () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#30 0x00007ffff7c5a7c1 in g_signal_emit_valist () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#31 0x00007ffff7c5a883 in g_signal_emit () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#32 0x00007ffff73b62f3 in ??? () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#33 0x00007ffff7c3e8da in g_cclosure_marshal_VOID__BOXEDv () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#34 0x00007ffff7c5a6bd in ??? () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#35 0x00007ffff7c5a7c1 in g_signal_emit_valist () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#36 0x00007ffff7c5a883 in g_signal_emit () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#37 0x00007ffff73adf5c in ??? () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#38 0x00007ffff73b5ccb in ??? () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#39 0x00007ffff73b95ca in ??? () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#40 0x00007ffff7378ab3 in gtk_event_controller_handle_event () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#41 0x00007ffff755e6d8 in ??? () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#42 0x00007ffff72982f7 in ??? () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#43 0x00007ffff7c5a6bd in ??? () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#44 0x00007ffff7c5a7c1 in g_signal_emit_valist () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#45 0x00007ffff7c5a883 in g_signal_emit () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#46 0x00007ffff7566bf4 in ??? () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#47 0x00007ffff7403390 in ??? () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#48 0x00007ffff7403f2a in gtk_main_do_event () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#49 0x00007ffff7aa5407 in ??? () at /lib/x86_64-linux-gnu/libgdk-3.so.0
#50 0x00007ffff7ade68e in ??? () at /lib/x86_64-linux-gnu/libgdk-3.so.0
#51 0x00007ffff7eb55c5 in ??? () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#52 0x00007ffff7f14737 in ??? () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#53 0x00007ffff7eb4a63 in g_main_context_iteration () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#54 0x00007ffff7d6f87d in g_application_run () at /lib/x86_64-linux-gnu/libgio-2.0.so.0
#55 0x00005555555833ad in main ()

I may have multiple small issues, and I need to debug them correctly and identify the differents triggers and issues. Will report more as soon as I find out.

[jeremypw]

Thanks - the backtrace shows it is something todo with the Git manager service. I am working with Git repositories and Code all the time and have not experienced this. Could you try closing all the (git) projects re-opening them individually to see if there is one that is causing the issue and if there is anything unusual about it?

[jeremypw]

If you identify a problematic procject, could you try using the "Find in Folder" option from the sidebar context menu to see if you get crashes there? It might serve as a workround anyway.

[jeremypw]

I've pushed a possible fix that protect the loading_required property from simultaneous access. Hopefully this will fix the problem. If you are able to test #1660 that would be great.

[lobre]

I have managed to install the build deps and to build the version of your branch. However, I still have the crash when trying to validate a global search...

Here is the new backtrace from gdb ./build/src/io.elementary.code, but it might look similar to the previous one.

#0  scratch_folder_manager_folder_item_get_loading_required (self=0x555555d46220)
    at ../src/FolderManager/FolderItem.vala:34
#1  0x00005555555b4843 in scratch_folder_manager_folder_item_load_children (self=0x555555d46220)
    at ../src/FolderManager/FolderItem.vala:67
#2  0x00005555555adc52 in scratch_folder_manager_file_view_find_path
    (self=0x555555dab7c0, list=0x555556896c00, path=0x5555570d6c50 "/home/lobre/src/github.com/raliance/flunter/backend/.env.test", expand=1) at ../src/FolderManager/FileView.vala:232
#3  0x00005555555add10 in scratch_folder_manager_file_view_find_path
    (self=0x555555dab7c0, list=0x555556140b70, path=0x5555570d6c50 "/home/lobre/src/github.com/raliance/flunter/backend/.env.test", expand=1) at ../src/FolderManager/FileView.vala:239
#4  0x00005555555add10 in scratch_folder_manager_file_view_find_path
    (self=0x555555dab7c0, list=0x555555da35e0, path=0x5555570d6c50 "/home/lobre/src/github.com/raliance/flunter/backend/.env.test", expand=1) at ../src/FolderManager/FileView.vala:239
#5  0x00005555555ae21e in scratch_folder_manager_file_view_expand_to_path
    (self=0x555555dab7c0, path=0x5555570d6c50 "/home/lobre/src/github.com/raliance/flunter/backend/.env.test")
    at ../src/FolderManager/FileView.vala:264
#6  0x00005555555c30cc in scratch_folder_manager_project_folder_item_perform_match
    (self=0x555556140b70, target=0x555556ff0080, search_regex=0x5555569cc440, check_is_text=1, target_info=0x0)
    at ../src/FolderManager/ProjectFolderItem.vala:722
#7  0x00005555555c0df4 in ____lambda98_
    (_data25_=0x555555d8f3f0, rel_path=0x555555faab98 "backend/.env.test", status=GGIT_STATUS_CURRENT)
    at ../src/FolderManager/ProjectFolderItem.vala:625
#8  0x00005555555c0e57 in _____lambda98__ggit_status_callback
    (path=0x555555faab98 "backend/.env.test", status_flags=GGIT_STATUS_CURRENT, self=0x555555d8f3f0)
    at /home/lobre/src/github.com/elementary/code/build/ProjectFolderItem.c:3794
#9  0x00007ffff6061c6c in git_status_foreach_ext
    (repo=<optimised out>, opts=opts@entry=0x555555d2ee90, cb=cb@entry=0x5555555c0e2a <_____lambda98__ggit_status_callback--Type <RET> for more, q to quit, c to continue without paging--
>, payload=payload@entry=0x555555d8f3f0) at /usr/src/libgit2-1.7.2+ds-1ubuntu3/src/libgit2/status.c:443
#10 0x00007ffff7014d25 in ggit_repository_file_status_foreach
    (repository=0x555555774a80, options=<optimised out>, callback=0x5555555c0e2a <_____lambda98__ggit_status_callback>, user_data=0x555555d8f3f0, error=0x7fffffffbd98) at ../libgit2-glib/ggit-repository.c:1307
#11 0x00005555555c1e02 in scratch_folder_manager_project_folder_item_global_search (self=Python Exception <class 'gdb.MemoryError'>: Cannot access memory at address 0x7fffffffbd48

   #12 0x00005555555ae625 in scratch_folder_manager_file_view_search_global
    (self=0x555555dab7c0, path=0x555556bd9900 <error: Cannot access memory at address 0x555556bd9900>, term=0x7ffff764b1fd <error: Cannot access memory at address 0x7ffff764b1fd>) at ../src/FolderManager/FileView.vala:278
#13 0x00005555555929cf in scratch_main_window_action_find_global
    (self=0x5555557d0610, action=0x555555873c30, param=0x555555ac0c00) at ../src/MainWindow.vala:1331
#14 0x0000555555586d79 in _scratch_main_window_action_find_global_gsimple_action_activate_callback
    (action=0x555555873c30, parameter=0x555555ac0c00, self=0x5555557d0610) at ../src/MainWindow.vala:134
#15 0x00007ffff7c3a2fa in g_closure_invoke () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#16 0x00007ffff7c6990c in ??? () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#17 0x00007ffff7c5a591 in ??? () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#18 0x00007ffff7c5a7c1 in g_signal_emit_valist () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#19 0x00007ffff7c5a883 in g_signal_emit () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#20 0x00007ffff7d76be5 in ??? () at /lib/x86_64-linux-gnu/libgio-2.0.so.0

[lobre]

Oh, I forgot:

Could you try closing all the (git) projects re-opening them individually to see if there is one that is causing the issue and if there is anything unusual about it?

This is easy, as I only have one git project loaded in code.

If you identify a problematic procject, could you try using the "Find in Folder" option from the sidebar context menu to see if you get crashes there?

Not sure about which one you talk about, but I have tried both from right-click on the tree-view -> "Find in folder", and from the hamburger "Menu" -> "magnifying glass" (right one). And I do have the same crash after I try to validate the search.

[jeremypw]

OK, thanks. Not sure what you mean by "hamburger" menu - I don't think Code has a "hamburger" icon in OS8. The magnifying glass on the right (in a LTR locale) is in the Vala symbol pane?

Are you able to build the linked PR and test it? You will need to have git installed as well as build-essentials, meson and valac. You can install the build dependencies with sudo apt build-dep io.elementary.code There is more info here: https://wiki.gnome.org/Projects(2f)Vala(2f)Tools(2f)Meson.html