Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1688178 - gnome-terminal abort
Summary: gnome-terminal abort
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Fedora
Classification: Fedora
Component: gnome-terminal
Version: 30
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Matthias Clasen
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-03-13 10:42 UTC by Zbigniew Jędrzejewski-Szmek
Modified: 2019-03-14 19:20 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-03-13 16:51:34 UTC


Attachments (Terms of Use)

Description Zbigniew Jędrzejewski-Szmek 2019-03-13 10:42:30 UTC
Description of problem:
I just had gnome-terminal die on me.
$  coredumpctl gdb
           PID: 9542 (gnome-terminal-)
           UID: 1000 (zbyszek)
           GID: 1000 (zbyszek)
        Signal: 6 (ABRT)
     Timestamp: Wed 2019-03-13 11:28:53 CET (8min ago)
  Command Line: /usr/libexec/gnome-terminal-server
    Executable: /usr/libexec/gnome-terminal-server
 Control Group: /user.slice/user-1000.slice/user@1000.service/gnome-terminal-server.service
          Unit: user@1000.service
     User Unit: gnome-terminal-server.service

#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50        return ret;
[Current thread is 1 (Thread 0x7f77da6bfcc0 (LWP 9542))]
(gdb) bt
#0  0x00007f77dbdb80f5 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x00007f77dbda2895 in __GI_abort () at abort.c:79
#2  0x00007f77dcbb5455 in vte::terminal::Terminal::DECALN(vte::parser::Sequence const&) (this=0x55d44116c380, seq=...) at vteseq.cc:2570
#3  0x00007f77dcb9ef17 in vte::terminal::Terminal::process_incoming() () at parser-cmd.hh:46
#4  0x00007f77dcb9fb35 in vte::terminal::Terminal::time_process_incoming() (this=this@entry=0x55d44116c380) at vte.cc:10332
#5  0x00007f77dcb9fc2f in vte::terminal::Terminal::process(bool) (this=this@entry=0x55d44116c380, emit_adj_changed=emit_adj_changed@entry=true) at vte.cc:10355
#6  0x00007f77dcb9fd59 in vte::terminal::update_repeat_timeout(gpointer) (data=<optimized out>) at vte.cc:10490
#7  0x00007f77dbfdda41 in g_timeout_dispatch (source=0x2, callback=0x7ffda769c840, user_data=0x0) at ../glib/gmain.c:4671
#8  0x00007f77dbfdcf90 in g_main_dispatch (context=0x55d43e3156a0) at ../glib/gmain.c:3189
#9  0x00007f77dbfdcf90 in g_main_context_dispatch (context=0x55d43e3156a0) at ../glib/gmain.c:3854
#10 0x00007f77dbfdd328 in g_main_context_iterate (context=0x55d43e3156a0, block=7, dispatch=1, self=<optimized out>) at ../glib/gmain.c:3899
#11 0x00007f77dbfdd3d3 in g_main_context_iteration (context=context@entry=0x55d43e3156a0, may_block=may_block@entry=1) at ../glib/gmain.c:3988
#12 0x00007f77dc1e81ed in g_application_run (application=application@entry=0x55d43e417150 [TerminalApp], argc=argc@entry=0, argv=argv@entry=0x0) at ../gio/gapplication.c:2516
#13 0x000055d43c6f90e2 in main (argc=<optimized out>, argv=<optimized out>) at server.c:187

(gdb) bt full
#0  0x00007f77dbdb80f5 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
        set = {__val = {0, 140727412181136, 140727412181552, 140152769743629, 0, 0, 0, 0, 0, 0, 94370065171088, 140152769742639, 140727412181232, 140727412181224, 140727412181408, 140152772986128}}
        pid = <optimized out>
        tid = <optimized out>
#1  0x00007f77dbda2895 in __GI_abort () at abort.c:79
        save_stage = 1
        act = 
          {__sigaction_handler = {sa_handler = 0xe79, sa_sigaction = 0xe79}, sa_mask = {__val = {140152781199008, 140152781172396, 39, 94370078921104, 146, 147, 140152780950350, 0, 94370065090192, 94370065090192, 94370113438592, 146, 94370113438592, 94370112698432, 146, 94370112698432}}, sa_flags = -591849923, sa_restorer = 0x2000000001}
        sigs = {__val = {32, 0 <repeats 15 times>}}
#2  0x00007f77dcbb5455 in vte::terminal::Terminal::DECALN(vte::parser::Sequence const&) (this=0x55d44116c380, seq=...) at vteseq.cc:2570
        __PRETTY_FUNCTION__ = "void vte::terminal::Terminal::DECALN(const vte::parser::Sequence&)"
#3  0x00007f77dcb9ef17 in vte::terminal::Terminal::process_incoming() () at parser-cmd.hh:46
#4  0x00007f77dcb9fb35 in vte::terminal::Terminal::time_process_incoming() (this=this@entry=0x55d44116c380) at vte.cc:10332
        elapsed = <optimized out>
        target = <optimized out>
#5  0x00007f77dcb9fc2f in vte::terminal::Terminal::process(bool) (this=this@entry=0x55d44116c380, emit_adj_changed=emit_adj_changed@entry=true) at vte.cc:10355
        is_active = true
#6  0x00007f77dcb9fd59 in vte::terminal::update_repeat_timeout(gpointer) (data=<optimized out>) at vte.cc:10490
        that = 0x55d44116c380
        l = <optimized out>
        next = 0x0
        again = <optimized out>
#7  0x00007f77dbfdda41 in g_timeout_dispatch (source=0x2, callback=0x7ffda769c840, user_data=0x0) at ../glib/gmain.c:4671
        timeout_source = 0x2
        again = <optimized out>
#8  0x00007f77dbfdcf90 in g_main_dispatch (context=0x55d43e3156a0) at ../glib/gmain.c:3189
        dispatch = 0x7f77dbfdda20 <g_source_get_time+128>
        prev_source = 0x0
        was_in_call = 0
        user_data = 0x0
        callback = 0x7f77dcb9fd10 <vte::terminal::update_repeat_timeout(gpointer)>
        cb_funcs = 0x7f77dc0af280 <g_source_callback_funcs>
        cb_data = 0x55d4402e9e70
        need_destroy = <optimized out>
        source = 0x55d43ed700c0
        current = 0x55d43e2e6640
        i = 0
        __FUNCTION__ = "g_main_dispatch"
#9  0x00007f77dbfdcf90 in g_main_context_dispatch (context=0x55d43e3156a0) at ../glib/gmain.c:3854
#10 0x00007f77dbfdd328 in g_main_context_iterate (context=0x55d43e3156a0, block=7, dispatch=1, self=<optimized out>) at ../glib/gmain.c:3899
        max_priority = 2147483647
        timeout = 7
        some_ready = <optimized out>
        nfds = <optimized out>
        allocated_nfds = <optimized out>
        fds = 0x0
#11 0x00007f77dbfdd3d3 in g_main_context_iteration (context=context@entry=0x55d43e3156a0, may_block=may_block@entry=1) at ../glib/gmain.c:3988
        retval = <optimized out>
#12 0x00007f77dc1e81ed in g_application_run (application=application@entry=0x55d43e417150 [TerminalApp], argc=argc@entry=0, argv=argv@entry=0x0) at ../gio/gapplication.c:2516
        arguments = 0x55d43e3acb30
        status = 0
        context = 0x55d43e3156a0
        acquired_context = 1
        __FUNCTION__ = "g_application_run"
#13 0x000055d43c6f90e2 in main (argc=<optimized out>, argv=<optimized out>) at server.c:187
        app = 0x55d43e417150 [TerminalApp]
        r = 0

I *just* upgraded glib2 in the background, not sure if this is relevant. It shouldn't influence a running executable.

Version-Release number of selected component (if applicable):
gnome-terminal-3.31.90-2.fc30.x86_64
glib2-2.60.0-3.fc30.x86_64
glib2-2.60.0-3.fc30.i686
vte291-0.55.92-1.fc30.x86_64

How reproducible:
Happened first time since the upgrade to F30.

Comment 1 Christian Persch (GNOME) 2019-03-13 15:07:58 UTC
> I *just* upgraded glib2 in the background, not sure if this is relevant.
> It shouldn't influence a running executable.

I also don't think that {c,sh}ould have influenced this.

After applying the fedora vte patches, the line 2570 referenced here:

#2  0x00007f77dcbb5455 in vte::terminal::Terminal::DECALN(vte::parser::Sequence const&) (this=0x55d44116c380, seq=...) at vteseq.cc:2570
        __PRETTY_FUNCTION__ = "void vte::terminal::Terminal::DECALN(const vte::parser::Sequence&)"
#3  0x00007f77dcb9ef17 in vte::terminal::Terminal::process_incoming() () at parser-cmd.hh:46

appears to be the invalidate_all() call in DECALN(). I don't see how that could cause this abort... Can you check if was there a message in the journal from gnome-terminal-server's stdout/stderr, maybe an assertion failure message? Could be libc memory allocator corruption.  (The line number in #3 is 1 off, DECALN is line 47 in parser-cmd.hh ... weird.)

Comment 2 Christian Persch (GNOME) 2019-03-13 15:14:25 UTC
Line 46 is DCH, a much more likely function to actually have been used (unless you were running vttest in g-t at the time?).

Comment 3 Zbigniew Jędrzejewski-Szmek 2019-03-13 15:29:00 UTC
I don't see anything interesting in the logs, except for the fact that /usr/lib64/libvte-2.91.so.0.5590.0 is linked.
vte291-0.55.92-1.fc30.x86_64 has /usr/lib64/libvte-2.91.so.0.5592.0. I guess the process
was running from before a previous upgrade.

Mar 08 15:19:20 systemd[1625]: Starting GNOME Terminal Server...
Mar 08 15:19:20 gnome-terminal-server[9542]: Display does not support owner-change; copy/paste will be broken!
Mar 08 15:19:20 systemd[1625]: Started GNOME Terminal Server.
...
Mar 13 11:28:53 audit[9542]: ANOM_ABEND auid=1000 uid=1000 gid=1000 ses=1 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=9542 comm="gnome-terminal-" exe="/usr/libexec/gnome-terminal-server" sig=6 res=1
Mar 13 11:28:53 kernel: audit: type=1701 audit(1552472933.282:10061): auid=1000 uid=1000 gid=1000 ses=1 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=9542 comm="gnome-terminal-" exe="/usr/libexec/gnome-terminal-server" sig=6 res=1
Mar 13 11:28:53 systemd[1]: /usr/lib/systemd/system/systemd-coredump@.service:22: Unknown lvalue 'ProtectHostname' in section 'Service', ignoring
Mar 13 11:28:53 systemd[1]: Started Process Core Dump (PID 7601/UID 0).
Mar 13 11:28:53 audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-coredump@8-7601-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Mar 13 11:28:53 kernel: audit: type=1130 audit(1552472933.344:10062): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-coredump@8-7601-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Mar 13 11:28:53 systemd[1625]: gnome-terminal-server.service: Main process exited, code=dumped, status=6/ABRT
Mar 13 11:28:53 systemd[1625]: gnome-terminal-server.service: Failed with result 'core-dump'.
Mar 13 11:28:53 systemd[1625]: gnome-terminal-server.service: Consumed 1d 19h 5min 36.693s CPU time.
Mar 13 11:28:53 systemd-coredump[7602]: Process 9542 (gnome-terminal-) of user 1000 dumped core.
                                        
                                        Stack trace of thread 9542:
                                        #0  0x00007f77dbdb80f5 raise (libc.so.6)
                                        #1  0x00007f77dbda2895 abort (libc.so.6)
                                        #2  0x00007f77dcbb5455 n/a (/usr/lib64/libvte-2.91.so.0.5590.0 (deleted))
Mar 13 11:28:53 systemd[1]: systemd-coredump@8-7601-0.service: Succeeded.
Mar 13 11:28:53 kernel: audit: type=1131 audit(1552472933.966:10063): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-coredump@8-7601-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Mar 13 11:28:53 audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-coredump@8-7601-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Mar 13 11:28:53 systemd[1]: systemd-coredump@8-7601-0.service: Consumed 488ms CPU time.

(Both before and after the crash there is a gap of >10 s in the logs.)

If the backtrace doesn't make sense, please just close it. I use this machine for development, so various packages are not entirely standard.
  
> unless you were running vttest in g-t at the time?

I don't even know what that is ;)

Comment 4 Christian Persch (GNOME) 2019-03-13 16:30:44 UTC
I'd love to track this down, but there really isn't enough info. So I agree to just close it and not let this bug linger (I can't close myself, no bz privs).

Comment 5 Debarshi Ray 2019-03-13 16:51:34 UTC
Ok, closing.

Comment 6 Egmont Koblinger 2019-03-14 13:47:21 UTC
> I don't see anything interesting in the logs, except for the fact that /usr/lib64/libvte-2.91.so.0.5590.0 is linked.
> vte291-0.55.92-1.fc30.x86_64 has /usr/lib64/libvte-2.91.so.0.5592.0. I guess the process
> was running from before a previous upgrade.

Line numbers in parser-cmd.hh and vteseq.cc didn't change between mainstream 0.55.90 and 0.55.92 releases. Not sure if Fedora's patch changed (although probably not, since 92's patch applies on 90). Is there a way to dig up older rawhide srpms?

> Line 46 is DCH, a much more likely function to actually have been used (unless you were running vttest in g-t at the time?).

Yeah, but then it'd be an off-by-a-lot (and in the wrong method) in vteseq.cc.

I can much more easily imagine gcc (or clang?) going off-by-one with the line number, especially when a macro is involved.

Or maybe the corruption started earlier, corrupting the escape sequence lookup table??? This could explain how such a rare, testing escape sequence is "encountered". Maybe indeed related to the glib update???

How come it's the call to invalidate_all() without taking any arguments that's the last in the stack trace, rather than a particular line of that method? Maybe "this" is corrupted, not a valid Terminal object anymore (along the lines of recent vte bugs 77 & 89), thus the method can't be called???

Really weird. I'm also clueless.

Comment 7 Christian Persch (GNOME) 2019-03-14 19:20:28 UTC
(Just for future reference: I took the fedora patch from their repo [https://src.fedoraproject.org/rpms/vte291.git] and applied it to the vte upstream repo to get the line numbers to align.)


Note You need to log in before you can comment on or make changes to this bug.