Package: fvwm
Version: 1:2.6.5.ds-3
Followup-For: Bug #726530
This bug also occurs on my system, probably since quite some time.
Today's fvwm segfault shows some similarity to OP's fvwm segfault:
--------- ~/.xsession-errors ----------
[fvwm][convert_charsets]: WARNING -
Invalid byte sequence during conversion from UTF-8 to ISO-8859-1
[fvwm][convert_charsets]: WARNING -
Invalid byte sequence during conversion from UTF-8 to ISO-8859-1
/home/mjk/.xsession: line 206: 5097 Segmentation fault fvwm
---------------------------------------
So the bug (or at least non-robust behavior) might simply be in fvwm's
charset conversion routines. I'm running a LANG=en_US.ISO-8859-15
system, while a web page (see item 2 below) can of course have a UTF-8
title.
What I can contribute to this report:
1) I have a quite simple setup: xdm + single-head X11 + fvwm. No xrdp etc.
2) It seems to be related to browsers. For months, I thought X11 or
something on a lower level had a bug, because when my browser (both
Firefox and Chromium affected (both using different rendering
engines, Gecko vs. WebKit), both ATI and nvidia systems affected)
opened a new page, my X session would sometimes crash -- or so I
thought. Since I have put a while loop around fvwm in my
~/.xinitrc, these "crashes" seem to not occur any longer, I only
see fvwm segfaulting (and restarting due to the loop).
I *might* be able to provide a half-way reproducible error-setup
(Chromium with 3 tabs open), if I can still find that backed up
chromium directory. If so, I'll report it here.
3) As a temporary mitigation for all affected users, incl. the original
poster (lkcl <l...@lkcl.net>), try this (and adapt to your needs):
---[ ~/.xinitrc ]------
REALQUITFILE="/tmp/fvwm-really-quit"
LOGFILE="/tmp/fvwm-xinitrc.log"
{ your usual startup commands here }
while true; do
fvwm
echo "$(date): EXIT CODE FVWM: $?" >> "$LOGFILE"
if [ -e "$REALQUITFILE" ]; then
echo "$(date): file '$REALQUITFILE' exists" >> "$LOGFILE"
rm -f "$REALQUITFILE"
break
fi
done
------------------------
---[ ~/.fvwm/config ]---
# If we use the menu for quitting, we REALLY wanna quit; we
# do NOT want any "while true; do fvwm; done" loop to catch
# a supposedly crashing fvwm.
DestroyFunc FuncTouchAndQuit
AddToFunc FuncTouchAndQuit
+ I Exec touch /tmp/fvwm-really-quit
+ I Quit
DestroyMenu MenuFvwmQuitVerify
AddToMenu MenuFvwmQuitVerify
+ "&Z. $[gt.Quit]" FuncTouchAndQuit
+ "" Nop
+ "&R. $[gt.Restart]" Restart
+ "&N. $[gt.Restart] w/o config" Restart fvwm -f /dev/null
------------------------
This way, data-loss should not occur anymore. Just window positions
might be slightly off (at least that happens on my system), but
that's far better than data loss.
Marc-Jano
-- System Information:
Debian Release: jessie/sid
APT prefers testing
APT policy: (501, 'testing'), (50, 'unstable'), (25, 'experimental'), (12,
'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.13-1-amd64 (SMP w/6 CPU cores)
Locale: LANG=en_US.ISO-8859-15, LC_CTYPE=en_US.ISO-8859-15 (charmap=ISO-8859-15)
Shell: /bin/sh linked to /bin/bash
Versions of packages fvwm depends on:
ii libc6 2.18-4
ii libcairo2 1.12.16-2
ii libfontconfig1 2.11.0-2
ii libfreetype6 2.5.2-1
ii libfribidi0 0.19.6-1
ii libgdk-pixbuf2.0-0 2.30.6-1
ii libglib2.0-0 2.40.0-2
ii libice6 2:1.0.8-2
ii libperl4-corelibs-perl 0.003-1
ii libpng12-0 1.2.50-1
ii libreadline6 6.3-6
ii librplay3 3.3.2-14
ii librsvg2-2 2.40.2-1
ii libsm6 2:1.2.1-2
ii libstroke0 0.5.1-6
ii libtinfo5 5.9+20140118-1
ii libx11-6 2:1.6.2-1
ii libxcursor1 1:1.1.14-1
ii libxext6 2:1.3.2-1
ii libxft2 2.3.1-2
ii libxinerama1 2:1.1.3-1
ii libxpm4 1:3.5.10-1
ii libxrender1 1:0.9.8-1
ii perl 5.18.2-2+b1
ii zlib1g 1:1.2.8.dfsg-1
Versions of packages fvwm recommends:
ii fvwm-icons 20070101-2
ii libx11-protocol-perl 0.56-4
ii perl-tk 1:804.032-2
Versions of packages fvwm suggests:
ii cpp 4:4.8.2-3
pn fvwm-themes <none>
ii m4 1.4.17-3
ii menu 2.1.46
pn wm-icons <none>
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
