Re: [gentoo-user] segfault in gedit / glib
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 0x7f60cd333a74 in g_main_context_prepare () from > /usr/lib64/libglib-2.0.so.0 > No symbol table info available. > #1 0x7f60cd33449b in ?? () from /usr/lib64/libglib-2.0.so.0 > No symbol table info available. > #2 0x7f60cd334693 in g_main_context_iteration () from > /usr/lib64/libglib-2.0.so.0 > No symbol table info available. > #3 0x7f60d047676a in g_application_run () from > /usr/lib64/libgio-2.0.so.0 > No symbol table info available. > #4 0x563890d41d59 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
Re: [gentoo-user] segfault in gedit / glib
* 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 0x7f60cd333a74 in g_main_context_prepare () from /usr/lib64/libglib-2.0.so.0 No symbol table info available. #1 0x7f60cd33449b in ?? () from /usr/lib64/libglib-2.0.so.0 No symbol table info available. #2 0x7f60cd334693 in g_main_context_iteration () from /usr/lib64/libglib-2.0.so.0 No symbol table info available. #3 0x7f60d047676a in g_application_run () from /usr/lib64/libgio-2.0.so.0 No symbol table info available. #4 0x563890d41d59 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?
Re: [gentoo-user] segfault in gedit / glib
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 ", substituting a > > text file for . 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 > 7f7c2550ba74 sp 7fff66834850 error 4 in libglib- > 2.0.so.0.5200.3[7f7c254c+114000] > > the gedit 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
> > The segfault message would exist in the dmesg/journalctl. Please open a > user shell in Gnome and type "gedit ", substituting a text file for > . 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 7f7c2550ba74 sp 7fff66834850 error 4 in libglib-2.0.so.0.5200.3[7f7c254c+114000] the gedit message is; Segmentation fault (core dumped)
Re: [gentoo-user] segfault in gedit / glib
On Fri, Dec 29, 2017 at 3:07 AM, Adam Carter wrote: > > > On Fri, Dec 29, 2017 at 4:59 PM, P Levine wrote: > >> On Thu, Dec 28, 2017 at 9:01 PM, Adam Carter >> 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 >>> 7f7c2550ba74 sp 7fff66834850 error 4 in >>> libglib-2.0.so.0.5200.3[7f7c254c+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 >>> >>> >> >> 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 ", substituting a text file for . Press enter. Does this segfault and if so is there anything else printed?
Re: [gentoo-user] segfault in gedit / glib
On Fri, Dec 29, 2017 at 4:59 PM, P Levine wrote: > On Thu, Dec 28, 2017 at 9:01 PM, Adam Carter > 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 >> 7f7c2550ba74 sp 7fff66834850 error 4 in >> libglib-2.0.so.0.5200.3[7f7c254c+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 >> >> > > 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?)
Re: [gentoo-user] segfault in gedit / glib
On Thu, Dec 28, 2017 at 9:01 PM, Adam Carter 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
> 7f7c2550ba74 sp 7fff66834850 error 4 in libglib-2.0.so.0.5200.3[
> 7f7c254c+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
>
> 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) = 0x7fbea802
> 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.
[gentoo-user] segfault in gedit / glib
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
7f7c2550ba74 sp 7fff66834850 error 4 in
libglib-2.0.so.0.5200.3[7f7c254c+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
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) = 0x7fbea802
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)
