Dear Maintainer,

Gedit is not working as expected. If I create a file (or edit and save) with
gedit and later try to open it with gedit I get Segmentation fault (in
terminal, if I try to double click the file I just get waiting cursor and
program crashes). It's random, sometimes it fails to open, sometimes it opens.
I tried creating file with other editors and those files open successfully in
gedit. The files can be opened if gedit is already runing and I double click
the file. I noticed that I get a new entry in coredumpctl every time I open
gedit.

Hello Nenad Cvetkovic,
I tried to have a look at your core file.
It shows a crash with following backtrace [1].
The reason seems to be an invalid function pointer in variable "prepare".

The upstream issue in [2] shows a similar backtrace, but I
am not sure if they are related about what is causing it.


Investigation with a core file needs the same installed
package version, therefore the inspection at the host
creating the core has less chances for discrepancies.
Therefore, if you have gdb installed, you should be able
to generate a backtrace on your system too by e.g.:
     coredumpctl list
     coredumpctl gdb <PID>
         bt

This gets normally improved by installing the dbgsym packages
or setting the environment DEBUGINFOD_URLS,
both and more described in [3].

Therefore the question, is there a reason for what looks like
local rebuilt packages libenchant1c2a and libxml2
due to the "~1.gbp73138d" version postfix?

Kind regards,
Bernhard


[1]
     Core was generated by `/usr/bin/gedit --gapplication-service'.
     Program terminated with signal SIGSEGV, Segmentation fault.
     #0  0x00000000007f198f in ?? ()
     [Current thread is 1 (Thread 0x7f7cde497a80 (LWP 15100))]
     (gdb) bt
     #0  0x00000000007f198f in ?? ()
     #1  0x00007f7ce25f7669 in g_main_context_prepare (context=context@entry=0x55ba65041ad0, priority=priority@entry=0x7ffcb3349aa0) at ../../../glib/gmain.c:3492
     #2  0x00007f7ce25f806b in g_main_context_iterate (context=context@entry=0x55ba65041ad0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at ../../../glib/gmain.c:3900
     #3  0x00007f7ce25f825c in g_main_context_iteration (context=context@entry=0x55ba65041ad0, may_block=may_block@entry=1) at ../../../glib/gmain.c:3981
     #4  0x00007f7ce37aea2d in g_application_run (application=0x55ba650231e0, argc=<optimized out>, argv=0x7ffcb3349c88) at ../../../gio/gapplication.c:2470
     #5  0x000055ba63f271fa in main (argc=2, argv=0x7ffcb3349c88) at gedit/gedit.c:146
     (gdb) info local
     No symbol table info available.
     (gdb) up
     #1  0x00007f7ce25f7669 in g_main_context_prepare (context=context@entry=0x55ba65041ad0, priority=priority@entry=0x7ffcb3349aa0) at ../../../glib/gmain.c:3492
     3492              result = (* prepare) (source, &source_timeout);
     (gdb) info local
     result = <optimized out>
     prepare = 0x7f198f
     source_timeout = -1
     i = <optimized out>
     n_ready = 16
     current_priority = 0
     source = 0x55ba658e7d00
     iter = {context = 0x55ba65041ad0, may_modify = 1, current_list = 0x7f7cd00020e0, source = 0x55ba658e7d00}

https://sources.debian.org/src/glib2.0/2.58.3-2+deb10u2/glib/gmain.c/#L3492

[2]
https://gitlab.gnome.org/GNOME/gedit/-/issues/51

[3]
https://wiki.debian.org/HowToGetABacktrace

Sent from ProtonMail, encrypted email based in Switzerland.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

Hello Nenad Cvetkovic,


thank you for the backtrace, at least it is equal to
what your core file generated in my test.

I still guess this might be a manifestation of upstream bug [1].
Unfortunately this got closed as it could no longer be reproduced
with at least gedit-3.30.2 and glib-2.60.6.
Unfortunately in Buster/stable is glib-2.58.3 in use.

Kind regards,
Bernhard

[1] https://gitlab.gnome.org/GNOME/gedit/-/issues/51

-- 
Hello,
how are you?