XFTE crashes on switching buffer to certain file

Binary package hint: fte

FTE that is distributed with UBUNTU 7.04 has a bug.

Here is the FTE package identication:

$ cat fte_0.50.0-1.4.dsc
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.0
Source: fte
Version: 0.50.0-1.4
Binary: fte-console, fte-xwindow, fte, fte-terminal, fte-docs
Maintainer: Zdenek Kabelac <email address hidden>
Architecture: any
Standards-Version: 3.1.1.1
Build-Depends: debhelper, perl5, libx11-dev, libxt-dev, x-dev, libgpmg1-dev, libncurses5-dev, libslang2-dev, patch
Files:
 2337f876f5382a94dc1a63616f508ab8 567290 fte_0.50.0-1.4.tar.gz

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQFEg7ilxBYivKllgY8RAs3EAJ9LhS4LMSQdYqmrW0kWVenpBMYHbACfSgb9
TljZHncdNn+GwhWzCXOhWG8=
=OcP+
-----END PGP SIGNATURE-----

In order to reproduce the bug, create file /tmp/crash.desktop, like this:

$ cat > /tmp/crash.desktop <<EOF
FTE Desktop 2
F|2|/etc/fstab
F|101|/tmp/xxxx/yyyy.pl
EOF

(See that the buffer ID in yyyy.pl is large? It is what triggers the bug,
I believe. Keep going on...)

Now follow strictly the instructions below, do not add or remove. I am
assuming UBUNTU 7.04 standard locations such as /usr/bin/xfte and
/etc/fte/system.fterc .

STEP 1: invoke xfte,

$ xfte -D/tmp/crash.desktop -C/etc/fte/system.fterc

STEP 2: Press Alt+0, Down arrow, Down arrow again (i.e. choose buffer /tmp/xxxx/yyyy.pl).

STEP 3: Press Alt+F .

Now xfte will crash with the following message:

*** stack smashing detected ***: xfte terminated
Aborted (core dumped)

This kind error is MISERABLE to debug, since the stack is damaged severely
(potentially).

Here is the (rough look of the initial) GDB log that led me to the
conclusion below. Please disregard slight variation in the invocation and
extra printing:

----------------begin GDB log----------------
/home/deleted/xfte-crash $ gdb xfte-build
...
(gdb) run -Dc2.fte-desktop -Hc2.fte-history
Starting program: /home/deleted/xfte-crash/xfte-build -Dc2.fte-desktop -Hc2.fte-history
EBuffer::Redraw() sprintf(s...) e_redraw.cpp:469 len(s) = 20
EBuffer::Redraw() sprintf(num...) e_redraw.cpp:479 len(num) = 11
*** stack smashing detected ***: /home/deleted/xfte-crash/xfte-build terminated

Program received signal SIGABRT, Aborted.
0xffffe410 in __kernel_vsyscall ()
(gdb) where
#0 0xffffe410 in __kernel_vsyscall ()
#1 0xb7ca3df0 in raise () from /lib/tls/i686/cmov/libc.so.6
#2 0xb7ca5641 in abort () from /lib/tls/i686/cmov/libc.so.6
#3 0xb7cda11b in ?? () from /lib/tls/i686/cmov/libc.so.6
#4 0x082004a1 in ?? ()
#5 0xbfffe918 in ?? ()
#6 0x08099f3f in EModel::UpdateTitle (this=0x206) at o_model.cpp:172
#7 0xb7d60431 in __stack_chk_fail () from /lib/tls/i686/cmov/libc.so.6
#8 0x08069625 in EBuffer::Redraw (this=0x81ff598) at e_redraw.cpp:566
#9 0x080a01ec in EEditPort::UpdateView (this=0x8188bc0) at o_buffer.cpp:341
#10 0x080a898c in EView::UpdateView (this=0x8172b70) at view.cpp:253
#11 0x08093d6c in ExModelView::UpdateView (this=0x8173328) at i_modelview.cpp:53
#12 0x08093c4a in ExView::Update (this=0x8173328) at i_oview.h:43
#13 0x08092ff0 in GxView::Update (this=0x8172b48) at i_view.cpp:142
#14 0x080b47b7 in GFrame::Update (this=0x8172ca0) at g_text.cpp:682
#15 0x080aecd4 in EFrame::Update (this=0x8172ca0) at egui.cpp:37
#16 0x080b316a in GUI::ProcessEvent (this=0x8160e50) at g_text.cpp:1171
#17 0x080b3352 in GUI::Run (this=0x8160e50) at g_text.cpp:1216
#18 0x080affa3 in main (argc=3, argv=0xbffff584) at fte.cpp:309
----------------end GDB log----------------

Note that __stack_chk_fail was called at the end of EBuffer::Redraw
routine, so there is where we should begin hunting for the bug.

Now what's wroing? I believe that the error is due to the following lines
in file e_redraw.cpp:

473 char num[10];
474
475 MoveStr(B, 0, W->Cols, s, SColor, W->Cols);
476 sprintf(num, " %s %d", CCharStr, ModelNo);

We only have TEN characters available in the num array. Is this enough,
though? NO!

I noticed in line 424--431 of the same file, that CCharStr contains
exactly six characters (not counting the terminating NULL). As a consequence,
for buffer /tmp/xxxx/yyyy.pl above, whose ModelNo == 101, we have 1+6+1+3
= 11 non-null characters plus one NULL terminating character. This is just
FATAL!

So to solve the problem, just allocate a larger buffer for num. In my
case, I'd rather be wasteful and safe, so I will replace line 473 to:

473 char num[32];

That should be large enough for any integer value of ModelNo and string of
CCharStr.

Notes-created: 20070711
Notes-updated: 20070711
Wirawan