roxterm sometimes changes geometry when tabs closed

[realh]

When tabs are closed using ctrl+shift+w, there is a small chance of maybe 10% that the roxterm window becomes smaller by one character in each direction (i.e 100x24 => 99x23). Observed on openbox and icewm with roxterm since version 1.19.1. Version 1.18.5 on sourceforge is not affected. However, the Debian versions are affected since 1.18.5-2.

Reported by: nignag

Original Ticket: roxterm/bugs/44

[realh]

This is depressing news. Interaction between vte and gtk for window sizing is a nightmare and I thought I'd found a solution that was simpler and more reliable than before.

Have you tried 1.19.x? I made further changes to the tab management code which I hope have laid this to rest, and I can't reproduce the problem with 1.19.4.

Does it only happen when closing the last tab but one, leaving just one terminal in the window? Or when there are so many tabs or their titles are so long they don't all fit? Do you have "Always show tab bar" and/or the menu bar enabled?

I'll probably have to leave this as far as 1.18.5's freeze for Debian goes, because it doesn't seem serious enough compared to the likely size of a diff to fix it.

Original comment by: realh

[realh]

This is depressing news.
Sorry.

Have you tried 1.19.x?
Yes, 1.19.[1-4] is affected.

Does it only happen when closing the last tab but one, leaving just one
terminal in the window? Or when there are so many tabs or their titles are
so long they don't all fit?
I've tried to find a way to make the problem more easily reproducable and this is what I've found so far:
I resize a roxterm window to 260x40. Then I create 25 tabs. All of them fit into the roxterm window including their full titles. Then I press ctrl+shift+w and hold these keys down for a moment so that approximately 50% to 80% of the tabs disappear. During that the roxterm window becomes smaller. The problem is easily reproduceable with icewm (1.3.7pre2), a little harder to reproduce with openbox (3.4.11.1) and much harder to reproduce with metacity (2.30.1) and fluxbox (1.11.1). My keyboard autorepeat delay is 250 and the repeat rate is 30 (xset r rate 250 30).

Do you have "Always show tab bar"
yes.

and/or the menu bar enabled?
no.

I'll probably have to leave this as far as 1.18.5's freeze for Debian
goes, because it doesn't seem serious enough compared to the likely size of
a diff to fix it.
I'm fine with that. I just wrote about Debian to point out that the problem has been introduced between 1.18.5-1 and 1.18.5-2.

Original comment by: nignag

[realh]

That's a big monitor and/or small fonts you're using! This sounds like a race condition. I couldn't reproduce the problem, but I must admit I didn't try very hard. I've added a stage to the close tab handler which might fix it, but then again it might well not! It shouldn't do any harm, although it could slow down the closing process so that when you hold down the close keys the closing lags badly behind the keyboard repeat rate.

Can you pull and build from git? There are instructions for fetching roxterm with git in the HTML documentation and how to then build a debian package in the INSTALL..Debian file. It's quite easy as long as you don't mind downloading the files from git and a lot of -dev packages you might not have installed otherwise.

Original comment by: realh

[realh]

That's a big monitor and/or small fonts you're using!
screen dimensions: 1600x1200 pixels
fonts dimensions: 6x10 pixels

Can you pull and build from git?
I've just checked out the latest roxterm from git and I'm sorry to say that the problem still persists. Don't hesitate to throw further patches/commits at me!

Original comment by: nignag

[realh]

Two small things I've noticed while building roxterm using a clean git checkout:

Beside running "apt-get build-dep roxterm" I've also had to install autopoint and po4a. Maybe it's worth mentioning this in INSTALL.Debian in the "Use of git" section.

And now some nitpicking (also in INSTALL.Debian): s/boostrap.sh/bootstrap.sh/

Original comment by: nignag

[realh]

I've just noticed that I can also make the problem appear by a simple single click on a Close button of a tab when I use openbox or icewm. With icewm the problem appears nearly every time when I click on a close button of a tab. With openbox the probability for the problem to appear is much smaller.

Original comment by: nignag

[realh]

When I do s.th. like this

--- roxterm-1.19.4-3-g260f1c4.orig/src/multitab.c 2010-10-24 02:13:28.504183726 +0200
+++ roxterm-1.19.4-3-g260f1c4/src/multitab.c 2010-10-24 04:04:40.216815286 +0200
@@ -1049,6 +1049,7 @@ static void multi_win_new_tab_action(Mul

static gboolean multi_tab_deferred_close_action(gpointer handle)
{

• sleep(3);
  multi_tab_delete(handle);
  return FALSE;
  }

and click ctrl+shift+w three times within three seconds I get

(gdb) bt
#0 0x00007ffff3cef165 in raise (sig=)
at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1 0x00007ffff3cf1f70 in abort () at abort.c:92
#2 0x00007ffff3d2527b in __libc_message (do_abort=,
fmt=) at ../sysdeps/unix/sysv/linux/libc_fatal.c:189
#3 0x00007ffff3d2ead6 in malloc_printerr (action=3,
str=0x7ffff3de5ac8 "double free or corruption (!prev)",
ptr=) at malloc.c:6267
#4 0x00007ffff3d3384c in __libc_free (mem=)
at malloc.c:3739
#5 0x000000000040bc34 in multi_tab_delete_without_notifying_parent (
tab=0x7d9120, destroy_widgets=1) at multitab.c:258
#6 0x000000000040bc69 in multi_tab_delete (tab=0x7d9120) at multitab.c:266
#7 0x000000000040db2c in multi_tab_deferred_close_action (handle=0x7d9120)
at multitab.c:1053
#8 0x00007ffff405c6f2 in g_main_context_dispatch () from /lib/libglib-2.0.so.0
#9 0x00007ffff4060568 in ?? () from /lib/libglib-2.0.so.0
#10 0x00007ffff4060a75 in g_main_loop_run () from /lib/libglib-2.0.so.0
#11 0x00007ffff6efc657 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0
#12 0x000000000040b5c1 in main (argc=1, argv=0x7fffffffe3c8) at main.c:306

Original comment by: nignag

[realh]

Updated comment: s/tab/active tab/
I've just noticed that I can also make the problem appear by a simple single click on a Close button of an active tab when I use openbox or icewm. With icewm the problem appears nearly every time when I click on a close button of an active tab. With openbox the probability for the problem to appear is much smaller.

Original comment by: nignag

[realh]

The problem never occurs when closing an inactive tab. Maybe in case of a close tab request of the active tab by the user, a solution is to first switch to another tab and then to close the previously active tab. Or another solution:
Set the program specified resize increment to 1x1, then close the tab and then set it back to the previous value. But I don't really know.

Original comment by: nignag

[realh]

Small consolation, but it looks like you're not alone: https://bugs.launchpad.net/ubuntu/+source/roxterm/+bug/665730.

The crash is because the sleep() gives you a chance to queue up multiple attempts to close the same window. I'm not sure whether that could happen with the idle alone, but I'll revert that change anyway seeing as it doesn't fix the problem.

Changing the selected tab before closing the old one might be a good way to fix this, thanks for noticing that.

I've noted your points about INSTALL.Debian too. I did add po4a to the dependencies for 1.19.x but of course apt-get build-dep is still working against 1.18.x for most people, so I'd better point that out in INSTALL.Debian too.

Original comment by: realh

[realh]

https://bugs.launchpad.net/ubuntu/+source/roxterm/+bug/665730
This ctrl+d shortcut is really comfortable but also really dangerous as it could easily be hit by accident. Who the hell did come up with that? ;-)

My guess is that the crash isn't caused by the sleep() function but by a lack of locking (It shouldn't be possible to call a tab destructor twice). The sleep() function just makes it really easy to trigger this crash. But as I've just said it's just a guess and I might be totally wrong.

When using the roxterm-version.tar.gz archives, roxterm builds fine without po4a and autopoint, so the Build-Depends section in debian/control doesn't have to include them. However, po4a and autopoint are both necessary when starting with a git checkout.

Original comment by: nignag

[realh]

This ctrl+d shortcut is really comfortable but also really dangerous as it
could easily be hit by accident. Who the hell did come up with that? ;-)

It's the standard EOF character for the shell (where the F is stdin), it
probably dates back at least to the 1970s. It would be possible to make
roxterm prevent Ctrl-D key presses from being received by the shell, but
Ctrl-D doubles as delete forwards if the command line isn't empty.

My guess is that the crash isn't caused by the sleep() function but by a
lack of locking (It shouldn't be possible to call a tab destructor twice).
The sleep() function just makes it really easy to trigger this crash. But
as I've just said it's just a guess and I might be totally wrong.

Under normal circumstances, ie closing the tab in response to the
key/mouse signal without deferring it to g_idle_add(), X won't allow
further events to be sent to that widget. So g_idle_add() makes the
crash possible in theory, the sleep() on top of that makes it really
easy in practice.

When using the roxterm-version.tar.gz archives, roxterm builds fine
without po4a and autopoint, so the Build-Depends section in debian/control
doesn't have to include them. However, po4a and autopoint are both
necessary when starting with a git checkout.

OK, thanks, I guess I can remove those deps and mention them in
INSTALL.Debian instead.

Original comment by: realh

[realh]

I managed to reproduce this with icewm, it seems to cause more size-allocate events compared to metacity. I've found a way to deal with that which fixes it for me, so please try updating from git.

Original comment by: realh

[realh]

Now it's doing unwanted resizing on some other events :-(. I've got a theory why, so hang on until I have another bash at it...

Original comment by: realh

[realh]

I've been using roxterm-1.19.4-6-g1b8a3dd-1 (the previous git checkout) for the last few days and haven't noticed any unwanted resize issues yet. I've been using a private build of IceWM which contains several fixes and modifications.

Original comment by: nignag

[realh]

I've got it working correctly for me now. I'm not entirely happy with it,
because setting a window's initial size kind of works by accident, and the more
I try to make sure it's doing it correctly, the worse the code spaghetti gets
and the size goes haywire! I'm kind of stuck with this unless I do some major
re-engineering, because the terminals and tab systems would have to be more
tightly integrated and generally do some things differently. See also
http://www.mail-archive.com/debian-mentors@lists.debian.org/msg70574.html. So
I might not be able to fix this 100% until GTK+3 is available.

Please could everyone try the latest git snapshot:

git clone git://roxterm.git.sourceforge.net/gitroot/roxterm/roxterm

Instructions for building a Debian package from this are in the file
INSTALL.Debian.

Original comment by: realh

[realh]

After a first short round of testing the latest snapshot from the git repository I've found that continously pressing icewm's toggle fullscreen key (Alt+F11) for a few seconds leads to resize problems. When switching back from fullscreen the size of the roxterm window approximately equals the size of the whole screen. I've also found fluxbox to behave the same here. Roxterm might interfere with icewm saving/restoring size hints when switching to/from fullscreen (YFrameClient::saveSizeHints and YFrameClient::restoreSizeHints in src/wmclient.cc).

Original comment by: nignag

[realh]

Running

sh -c 'roxterm & roxterm --tab'

from an rxvt now shows this nice popup error message

Unable to send/get reply to D-BUS message: Method "NewTerminal" with signature "sssss" on interface "net.sf.roxterm" doesn't exist

and also segfaults sometimes.

Original comment by: nignag

[realh]

Correction: The command line in my previous comment should've been:

sh -c 'roxterm & sleep 5; roxterm --tab'

This leads to a popup containing an error message but not to a segfault.

Original comment by: nignag

[realh]

I noticed the error message too. I think I know what's causing it, but to fix it I either have to regress one of two minor bugs/feature requests or add a lot of complication to the code.

Original comment by: realh

[realh]

I usually invoke roxterm by pressing Super+t which runs 'roxterm --tab' here, so it would be really nice if this error message could be avoided somehow. But I also could stick with roxterm 1.19.4-6-g1b8a3dd-1 or 1.18.5-1. Both of these versions work well enough for me.

Original comment by: nignag

[realh]

I decided to regress the old feature for now so the latest git should work better for you.

I'll try to fix the fullscreen problem later.

Original comment by: realh

[realh]

I can reproduce the fullscreen problem with gnome-terminal and compiz so I've reported a similar bug against gnome-terminal: https://bugzilla.gnome.org/show_bug.cgi?id=634240. TBH I don't think it's worth trying very hard to fix this, because holding down the fullscreen key isn't a normal thing to do.

Original comment by: realh