[gentoo-user] segfault in gedit / glib

[gentoo-user] segfault in gedit / glib

[Adam Carter]

[-- Attachment #1: Type: text/plain, Size: 1948 bytes --]

System is ~amd64. If i try to open a text file in gnome via double click, i
get;
$ journalctl -b | grep segf
Dec 29 12:17:32 phat kernel: gedit[1177]: segfault at 7f7c0d36e880 ip
00007f7c2550ba74 sp 00007fff66834850 error 4 in
libglib-2.0.so.0.5200.3[7f7c254c0000+114000]

The following work;
Open gedit first, then open the file
Use right click -> Open With Other Application and chose LibreOffice writer.

I've rebuild glib and gedit. Are there any clues on the issue in this trace?

$ strace gedit <filename>
<snip>
futex(0x55bf3d691a90, FUTEX_WAKE_PRIVATE, 1) = 1
access("/usr/share/fonts/liberation-fonts/LiberationMono-Regular.ttf",
R_OK) = 0
openat(AT_FDCWD,
"/usr/share/fonts/liberation-fonts/LiberationMono-Regular.ttf", O_RDONLY) =
18
fcntl(18, F_SETFD, FD_CLOEXEC)          = 0
fstat(18, {st_mode=S_IFREG|0644, st_size=313408, ...}) = 0
mmap(NULL, 313408, PROT_READ, MAP_PRIVATE, 18, 0) = 0x7fbea8020000
close(18)                               = 0
brk(0x55bf3e33b000)                     = 0x55bf3e33b000
write(11, "\1\0\0\0\0\0\0\0", 8)        = 8
futex(0x55bf3d79e270, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7fbec2c1c578, FUTEX_WAIT_PRIVATE, 2, NULL) = -1 EAGAIN (Resource
temporarily unavailable)
futex(0x7fbec2c1c578, FUTEX_WAKE_PRIVATE, 1) = 0
futex(0x55bf3d79e270, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7fbec2c1c608, FUTEX_WAIT_PRIVATE, 2, NULL) = -1 EAGAIN (Resource
temporarily unavailable)
futex(0x7fbec2c1c608, FUTEX_WAKE_PRIVATE, 1) = 0
futex(0x7fbec2c1c608, FUTEX_WAIT_PRIVATE, 2, NULL) = -1 EAGAIN (Resource
temporarily unavailable)
futex(0x7fbec2c1c608, FUTEX_WAKE_PRIVATE, 1) = 0
futex(0x7fbec2c1c578, FUTEX_WAKE_PRIVATE, 1) = 0
futex(0x7fbec2c1c608, FUTEX_WAIT_PRIVATE, 2, NULL) = -1 EAGAIN (Resource
temporarily unavailable)
futex(0x7fbec2c1c608, FUTEX_WAKE_PRIVATE, 1) = 0
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x7fbe9b976880}
---
+++ killed by SIGSEGV (core dumped) +++
Segmentation fault (core dumped)

[-- Attachment #2: Type: text/html, Size: 2272 bytes --]

Re: [gentoo-user] segfault in gedit / glib

[P Levine]

[-- Attachment #1: Type: text/plain, Size: 2223 bytes --]

On Thu, Dec 28, 2017 at 9:01 PM, Adam Carter <adamcarter3@gmail.com> wrote:

> System is ~amd64. If i try to open a text file in gnome via double click,
> i get;
> $ journalctl -b | grep segf
> Dec 29 12:17:32 phat kernel: gedit[1177]: segfault at 7f7c0d36e880 ip
> 00007f7c2550ba74 sp 00007fff66834850 error 4 in libglib-2.0.so.0.5200.3[
> 7f7c254c0000+114000]
>
> The following work;
> Open gedit first, then open the file
> Use right click -> Open With Other Application and chose LibreOffice
> writer.
>
> I've rebuild glib and gedit. Are there any clues on the issue in this
> trace?
>
> $ strace gedit <filename>
> <snip>
> futex(0x55bf3d691a90, FUTEX_WAKE_PRIVATE, 1) = 1
> access("/usr/share/fonts/liberation-fonts/LiberationMono-Regular.ttf",
> R_OK) = 0
> openat(AT_FDCWD, "/usr/share/fonts/liberation-
> fonts/LiberationMono-Regular.ttf", O_RDONLY) = 18
> fcntl(18, F_SETFD, FD_CLOEXEC)          = 0
> fstat(18, {st_mode=S_IFREG|0644, st_size=313408, ...}) = 0
> mmap(NULL, 313408, PROT_READ, MAP_PRIVATE, 18, 0) = 0x7fbea8020000
> close(18)                               = 0
> brk(0x55bf3e33b000)                     = 0x55bf3e33b000
> write(11, "\1\0\0\0\0\0\0\0", 8)        = 8
> futex(0x55bf3d79e270, FUTEX_WAKE_PRIVATE, 1) = 1
> futex(0x7fbec2c1c578, FUTEX_WAIT_PRIVATE, 2, NULL) = -1 EAGAIN (Resource
> temporarily unavailable)
> futex(0x7fbec2c1c578, FUTEX_WAKE_PRIVATE, 1) = 0
> futex(0x55bf3d79e270, FUTEX_WAKE_PRIVATE, 1) = 1
> futex(0x7fbec2c1c608, FUTEX_WAIT_PRIVATE, 2, NULL) = -1 EAGAIN (Resource
> temporarily unavailable)
> futex(0x7fbec2c1c608, FUTEX_WAKE_PRIVATE, 1) = 0
> futex(0x7fbec2c1c608, FUTEX_WAIT_PRIVATE, 2, NULL) = -1 EAGAIN (Resource
> temporarily unavailable)
> futex(0x7fbec2c1c608, FUTEX_WAKE_PRIVATE, 1) = 0
> futex(0x7fbec2c1c578, FUTEX_WAKE_PRIVATE, 1) = 0
> futex(0x7fbec2c1c608, FUTEX_WAIT_PRIVATE, 2, NULL) = -1 EAGAIN (Resource
> temporarily unavailable)
> futex(0x7fbec2c1c608, FUTEX_WAKE_PRIVATE, 1) = 0
> --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR,
> si_addr=0x7fbe9b976880} ---
> +++ killed by SIGSEGV (core dumped) +++
> Segmentation fault (core dumped)
>

Try opening the file via gedit in a user shell and see if segfaults and if
there is any other output.

[-- Attachment #2: Type: text/html, Size: 3104 bytes --]

Re: [gentoo-user] segfault in gedit / glib

[Adam Carter]

[-- Attachment #1: Type: text/plain, Size: 960 bytes --]

On Fri, Dec 29, 2017 at 4:59 PM, P Levine <plevine457@gmail.com> wrote:

> On Thu, Dec 28, 2017 at 9:01 PM, Adam Carter <adamcarter3@gmail.com>
> wrote:
>
>> System is ~amd64. If i try to open a text file in gnome via double click,
>> i get;
>> $ journalctl -b | grep segf
>> Dec 29 12:17:32 phat kernel: gedit[1177]: segfault at 7f7c0d36e880 ip
>> 00007f7c2550ba74 sp 00007fff66834850 error 4 in
>> libglib-2.0.so.0.5200.3[7f7c254c0000+114000]
>>
>> The following work;
>> Open gedit first, then open the file
>> Use right click -> Open With Other Application and chose LibreOffice
>> writer.
>>
>> I've rebuild glib and gedit. Are there any clues on the issue in this
>> trace?
>>
>> $ strace gedit <filename>
>> <snip>
>>
>
> Try opening the file via gedit in a user shell and see if segfaults and if
> there is any other output.
>

The "Segmentation fault (core dumped)" from above is the only non-strace
output (or have I misunderstood your instruction?)

[-- Attachment #2: Type: text/html, Size: 2089 bytes --]

Re: [gentoo-user] segfault in gedit / glib

[P Levine]

[-- Attachment #1: Type: text/plain, Size: 1360 bytes --]

On Fri, Dec 29, 2017 at 3:07 AM, Adam Carter <adamcarter3@gmail.com> wrote:

>
>
> On Fri, Dec 29, 2017 at 4:59 PM, P Levine <plevine457@gmail.com> wrote:
>
>> On Thu, Dec 28, 2017 at 9:01 PM, Adam Carter <adamcarter3@gmail.com>
>> wrote:
>>
>>> System is ~amd64. If i try to open a text file in gnome via double
>>> click, i get;
>>> $ journalctl -b | grep segf
>>> Dec 29 12:17:32 phat kernel: gedit[1177]: segfault at 7f7c0d36e880 ip
>>> 00007f7c2550ba74 sp 00007fff66834850 error 4 in
>>> libglib-2.0.so.0.5200.3[7f7c254c0000+114000]
>>>
>>> The following work;
>>> Open gedit first, then open the file
>>> Use right click -> Open With Other Application and chose LibreOffice
>>> writer.
>>>
>>> I've rebuild glib and gedit. Are there any clues on the issue in this
>>> trace?
>>>
>>> $ strace gedit <filename>
>>> <snip>
>>>
>>
>> Try opening the file via gedit in a user shell and see if segfaults and
>> if there is any other output.
>>
>
> The "Segmentation fault (core dumped)" from above is the only non-strace
> output (or have I misunderstood your instruction?)
>

The segfault message would exist in the dmesg/journalctl.  Please open a
user shell in Gnome and type "gedit <file>",​ substituting a text file for
<file>.  Press enter.  Does this segfault and if so is there anything else
printed?
​ ​

[-- Attachment #2: Type: text/html, Size: 3372 bytes --]

Re: [gentoo-user] segfault in gedit / glib

[Adam Carter]

[-- Attachment #1: Type: text/plain, Size: 529 bytes --]

>
> The segfault message would exist in the dmesg/journalctl.  Please open a
> user shell in Gnome and type "gedit <file>",​ substituting a text file for
> <file>.  Press enter.  Does this segfault and if so is there anything else
> printed?
> ​ ​
>

The journalctl message is;
Dec 29 12:17:32 phat kernel: gedit[1177]: segfault at 7f7c0d36e880 ip
00007f7c2550ba74 sp 00007fff66834850 error 4 in
libglib-2.0.so.0.5200.3[7f7c254c0000+114000]

the gedit <filename> message is;
Segmentation fault (core dumped)

[-- Attachment #2: Type: text/html, Size: 1133 bytes --]

Re: [gentoo-user] segfault in gedit / glib

[Mart Raudsepp]

On Sat, 2017-12-30 at 11:58 +1100, Adam Carter wrote:
> > The segfault message would exist in the dmesg/journalctl.  Please
> > open a user shell in Gnome and type "gedit <file>", substituting a
> > text file for <file>.  Press enter.  Does this segfault and if so
> > is there anything else printed?
> >  
> > 
> 
> The journalctl message is;
> Dec 29 12:17:32 phat kernel: gedit[1177]: segfault at 7f7c0d36e880 ip
> 00007f7c2550ba74 sp 00007fff66834850 error 4 in libglib-
> 2.0.so.0.5200.3[7f7c254c0000+114000]
> 
> the gedit <filename> message is;
> Segmentation fault (core dumped)

* Install gdb if it isn't already installed

* Make sure a core file is presend in coredumpd, coredumpctl should
show; if not, have it crash again so it's fresh and saved in there

* coredumpctl gdb gedit

* bt full

Post output of that "bt full"


Mart

Re: [gentoo-user] segfault in gedit / glib

[Adam Carter]

[-- Attachment #1: Type: text/plain, Size: 901 bytes --]

* Install gdb if it isn't already installed

>
> * Make sure a core file is presend in coredumpd, coredumpctl should
> show; if not, have it crash again so it's fresh and saved in there
>
> * coredumpctl gdb gedit
>
> * bt full
>
> Post output of that "bt full"
>
> (gdb) bt full
#0  0x00007f60cd333a74 in g_main_context_prepare () from
/usr/lib64/libglib-2.0.so.0
No symbol table info available.
#1  0x00007f60cd33449b in ?? () from /usr/lib64/libglib-2.0.so.0
No symbol table info available.
#2  0x00007f60cd334693 in g_main_context_iteration () from
/usr/lib64/libglib-2.0.so.0
No symbol table info available.
#3  0x00007f60d047676a in g_application_run () from
/usr/lib64/libgio-2.0.so.0
No symbol table info available.
#4  0x0000563890d41d59 in main ()
No symbol table info available.

FWIW I have -fomit-frame-pointer set - should i rebuild glib & gedit with
that or some other options changed?

[-- Attachment #2: Type: text/html, Size: 1350 bytes --]

Re: [gentoo-user] segfault in gedit / glib

[Mart Raudsepp]

On Sun, 2017-12-31 at 09:47 +1100, Adam Carter wrote:
> * Install gdb if it isn't already installed
> > * Make sure a core file is presend in coredumpd, coredumpctl should
> > show; if not, have it crash again so it's fresh and saved in there
> > 
> > * coredumpctl gdb gedit
> > 
> > * bt full
> > 
> > Post output of that "bt full"
> > 
> > 
> 
> (gdb) bt full
> #0  0x00007f60cd333a74 in g_main_context_prepare () from
> /usr/lib64/libglib-2.0.so.0
> No symbol table info available.
> #1  0x00007f60cd33449b in ?? () from /usr/lib64/libglib-2.0.so.0
> No symbol table info available.
> #2  0x00007f60cd334693 in g_main_context_iteration () from
> /usr/lib64/libglib-2.0.so.0
> No symbol table info available.
> #3  0x00007f60d047676a in g_application_run () from
> /usr/lib64/libgio-2.0.so.0
> No symbol table info available.
> #4  0x0000563890d41d59 in main ()
> No symbol table info available.
> 
> FWIW I have -fomit-frame-pointer set - should i rebuild glib & gedit
> with that or some other options changed?

-fomit-frame-pointer is the default on x86_64/amd64 in most situations.
-fno-omit-frame-pointer might help, but usually that's useful for
sample based profiling (like sysprof), which can't spend time unwinding
the traces with more complex ways during sample collection.
Here you already actually have the full backtrace available, even most
symbol names, so it could already unwind it. Best to have full debug
symbols then with CFLAGS including e.g -ggdb and FEATURES having
"splitdebug compressdebug". This can be done per-package, but if
there's disk space available for /usr/lib64/debug (could also be a
symlink to an always mounted data disk), it doesn't hurt to just always
have it enabled for all. Well, it does hurt compilation time a bit, and
a lot for big packages like chromium/webkit-gtk, for which this could
then be disabled instead. Anyhow, up to you how much you enable. For
this backtrace, dev-libs/glib is the one of interest.

That said, this looks really weird place to crash, and I doubt there's
threads going on with it unable to show the correct one.
t a a b f would make sure instead of bt full (the former is short for
thread apply all backtrace full, so the same as bt full, but will show
all threads, not current only).
I'm not sure debug information for the backtrace will help much, but
debug symbols + some more gdb usage than just getting the trace might
help.

Mart