After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 100717 - Resizing window while using less causes a crash
Resizing window while using less causes a crash
Status: RESOLVED DUPLICATE of bug 94509
Product: gnome-terminal
Classification: Core
Component: general
2.0.x
Other Linux
: Normal critical
: ---
Assigned To: Havoc Pennington
GNOME Terminal Maintainers
Depends on:
Blocks:
 
 
Reported: 2002-12-09 05:06 UTC by Jeremy Frank
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: 2.0


Description Jeremy Frank 2002-12-09 05:06:05 UTC 
Description of Problem:
When resizing a window while using less to look at
a text file over a ssh connection, gnome-terminal
crashes with a fatal error. I am using
gnome-terminal 2.0.1. More specifically, it is the
one that shipped with Red Hat 8.0 (gnome-terminal
2.0.1-5).

Steps to reproduce the problem:
1. Start at least two gnome-terminal sessions
(i.e. two windows)

2. From the second gnome-terminal window, ssh to a
remote machine. I am using openssh 3.4p1-2. I am
using ssh2, and logging in as a non-root user
using standard name and password authentication.

3. Look at a file with less. It does not seem to
matter how big the file is.

4. Grab the corner of the window with the mouse
pointer and enlarge it by at least 30% (rough
estimate). When you let go of the mouse, you will
get the following error message: Application
"gnome-terminal" (process 11782) has crashed due
to a fatal error. (Aborted)

5. At this point, *all* gnome-terminal sessions
crash and disappear.


How often does this happen? 
Highly reproducible. You can sometimes get away
with the resize if you only enlarge the window a
little bit.

Additional Information:
Comment 1 David Kennedy 2002-12-09 05:17:24 UTC 
Unfortunately without a stack trace, this bug will be difficult to
fix. If you can capture a trace (using gdb or bug-buddy), please
attach it to this bug.

For information on how to capture stack traces, see
http://bugzilla.gnome.org/getting-traces.cgi - thanks.
Comment 2 Jeremy Frank 2002-12-09 06:02:49 UTC 
Here is a stack trace from gdb (which I ran from an xterm). I was able
to produce the exact same stack trace three times in a row. I'm also
including the output from before the stack trace, as it looks interesting.

(gdb) run
Starting program: /usr/bin/gnome-terminal 
[New Thread 8192 (LWP 14648)]

** ERROR **: NULL at 40(->0) delta 42, length 8, max 10 next 50 at 2376

aborting...

Program received signal SIGABRT, Aborted.

+ Trace 31475

Thread 8192 (LWP 14648)

  • #0 kill
    from /lib/i686/libc.so.6
  • #1 raise
    from /lib/i686/libpthread.so.0
  • #2 abort
    from /lib/i686/libc.so.6
  • #3 g_logv
    from /usr/lib/libglib-2.0.so.0
  • #4 g_log
    from /usr/lib/libglib-2.0.so.0
  • #5 vte_terminal_ensure_cursor
    from /usr/lib/libvte.so.2
  • #6 vte_sequence_handler_ce
    from /usr/lib/libvte.so.2
  • #7 vte_terminal_handle_sequence
    from /usr/lib/libvte.so.2
  • #8 vte_terminal_process_incoming
    from /usr/lib/libvte.so.2
  • #9 g_idle_dispatch
    from /usr/lib/libglib-2.0.so.0
  • #10 g_main_dispatch
    from /usr/lib/libglib-2.0.so.0
  • #11 g_main_context_dispatch
    from /usr/lib/libglib-2.0.so.0
  • #12 g_main_context_iterate
    from /usr/lib/libglib-2.0.so.0
  • #13 g_main_loop_run
    from /usr/lib/libglib-2.0.so.0
  • #14 gtk_main
    from /usr/lib/libgtk-x11-2.0.so.0
  • #15 main
  • #16 __libc_start_main
    from /lib/i686/libc.so.6
Comment 3 David Kennedy 2002-12-09 14:17:02 UTC 

*** This bug has been marked as a duplicate of 94509 ***
Comment 4 David Kennedy 2002-12-09 14:17:47 UTC 
Thanks for getting the trace - it's a duplicate of bug 94509, for
information on it, check out that report.