xvnc4viewer crashes with "couldn't find suitable pixmap format" in 24bpp

[Stéphane Graber]

Testing with a server and client in a VM, trying to do a demo shows "couldn't find suitable pixmap format" from xvnc4viewer and then shows the crash report window.

[Alkis Georgopoulos (alkisg)]

I think that's somehow related to the specific VM technology that you use, vagrantc also mentioned something about it but I could never reproduce it with VirtualBox.
What VM and which virtual graphics driver are you using? Is your color depth 24 or 32? Does it happen with other color depths?
If we find a quick way to reproduce it, we can then unassign the bug report from epoptes and subscribe x11vnc or xvnc4viewer instead.

[Stéphane Graber (stgraber)]

That was with a default kvm VM under libvirt, so the video card is a cirrus at 1024x768 and 24bit according to Xorg.log.

[Alkis Georgopoulos (alkisg)]

The problem is explained in http://www.karlrunge.com/x11vnc/faq.html#faq-24bpp

xvnc4viewer crashes when the client display is configured at 24 bpp.

A workaround for users is to use another color mode, e.g. X_COLOR_DEPTH=16 if using LTSP.
For KVM guests, -vga vmware could also be used.

A workaround for the epoptes package could be to use ssvncviewer on 24bpp color modes, but of course the real solution would be for xvnc4viewer to get fixed.

[Alkis Georgopoulos (alkisg)]

From the epoptes package side, we'll probably do the following:
 * If ssvncviewer is installed, and if 24bpp is detected, then ssvncviewer will be used instead.
 * Otherwise we'll just launch xvnc4viewer even if it crashes. We're not responsible for it crashing, it should be at least fixed so that it produces a warning instead of a segmentation fault.
 * We'll document the problem in the epoptes website.

[Alkis Georgopoulos (alkisg)]

For epoptes, fixed in http://bazaar.launchpad.net/~epoptes/epoptes/trunk/revision/234.

For xvnc4viewer the bug should remain open until at least the segmentation fault is fixed.

[Alkis Georgopoulos (alkisg)]

Fix released in Epoptes 0.5.0.

[penalvch (penalvch)]

Stéphane Graber, thank you for reporting this and helping make Ubuntu better. However, your crash report is missing. Please follow these instructions to have apport report a new bug about your crash that can be dealt with by the automatic retracer. First, execute at a terminal:
cd /var/crash && sudo rm * ; sudo apt-get update && sudo apt-get -y upgrade && sudo service apport start force_start=1

If you are running the Ubuntu Stable Release you might need to enable apport in /etc/default/apport and restart.

Now reproduce the crash, then open your file manager, navigate to your /var/crash directory and open the crash report you wish to submit.
If this fails you will have to open a terminal and file your report with 'ubuntu-bug /var/crash/_my_crash_report.crash' where _my_crash_report.crash is the crash you would like to report. If you get an error that you aren't allowed to access this report you will have to file it with 'sudo ubuntu-bug /var/crash/_my_crash_report.crash'. If you run the command against the crash report and a window pops up asking you to report this, but then never opens a new report, you would be affected by https://bugs.launchpad.net/ubuntu/+source/apport/+bug/994921 . In order to WORKAROUND this, one would need to open the following file via a command line:
sudo nano /etc/apport/crashdb.conf

and comment out the line:
'problem_types': ['Bug', 'Package'],

by changing it to:
# 'problem_types': ['Bug', 'Package'],

Save, close, and try to file the crash report again via:
ubuntu-bug /var/crash/_my_crash_report.crash

I'm closing this bug report since the process outlined above will automatically open a new bug report which can then dealt with more efficiently.

Please feel free to subscribe me to this new report.

Also, please do not attach your crash report manually to this report and reopen it.

Thank you for your understanding.

Helpful bug reporting tips:
https://wiki.ubuntu.com/ReportingBugs