search

Boomaga / boomaga

Boomaga provides a virtual printer for CUPS. This can be used for print preview or for print booklets.
Other
182 stars 34 forks source link

/usr/bin/boomaga crashed on SIGSEGV when running from remote connected session #66

Open fhanzlik opened 6 years ago

fhanzlik commented 6 years ago

I run boomaga on Fedora 25/x86_64 LTSP server and it works fine when I start it from console or from 'ssh -X' remote connection. But boomaga crashed on SIGSEGV when I try run it from session initiated from diskless client.

Attached is gdb backtrace, strace output and boomaga cups backend status report printscreen as is after trying print to boomaga virtual printer.

boomaga-segfault.tar.gz

fhanzlik commented 6 years ago

I forgot to mention - files attached in previous report are for boomaga-0.9.1. I also tried version 1.0.0, and it crashes as well

SokoloffA commented 6 years ago

I try run it from session initiated from diskless client

Please explain how you run the program. Where the program is installed, and where the CUPS is running? If the program and CUPS server running on different hosts, unfortunately this won't work. How boomaga works:

  1. You print a document from your X-session, which is started from normal user.
  2. The CUPS server run boomaga backend (/usr/lib/cups/backend/boomaga). The backend gets the user name who sent the print job.
  3. The backend is looking for active X-session and D-Bus address for a user from step 2, and using D-Bus runs boobaga GUI program in the found X-Session.

If a user session running on another computer, backend will not be able to find it.

fhanzlik commented 6 years ago

I roughly know how boomaga works, and IMO in this case things should work well. User session, cups and boomaga are installed and run on terminalserver, thin client act only as X server for terminalserver applications. In addition, it seems as boomaga GUI program (/usr/bin/boomaga) is able to run as stand-alone program, independently on cups backend - what is how i run it now, for simplicity. Not sure, when in this case program also does any works with D-Bus (maybe no) - but it crashes on SIGSEGV. No matter, when I run it without parameters or with existing PDF file name as parameter - what are cases, where boomaga GUI run right, when I run it from console or from remote connection (e.g. 'ssh -X terminalserver /usr/bin/boomaga my.pdf' works well).

Is there something else, what I could / should try?

SokoloffA commented 6 years ago

Try to run 

dbus-send --session --type=method_call --print-reply --dest=org.boomaga /boomaga org.boomaga.add string:'/home/sokoloff/myPrograms/boomaga/tests/01-pages.pdf' string:'title' boolean:false string:'options' uint32:1

Where /home/sokoloff/myPrograms/boomaga/tests/01-pages.pdf is full path to valid PDF file. You can download PDF files from https://github.com/Boomaga/rendertest

fhanzlik commented 6 years ago

I just try it with Boomaga-1.0.0 and with following PDF files from https://github.com/Boomaga/rendertest/: 01-pages.pdf, 02-pages.pdf, Urpmi.pdf, issue_60.pdf. Result: 1) On terminals from console MATE session and 'ssh -X' connection 'dbus-send' command correctly start /usr/bin/boomaga (FYI: files 01-pages.pdf and 02-pages.pdf are reported as damaged, see attached screenshot. Other two files are displayed correctly). 2) on terminal from remote diskless station session 'dbus-send' ends with message "Error org.freedesktop.DBus.Error.NoReply: Message recipient disconnected from message bus without replying" , and in terminalserver audit log is message "type=ANOM_ABEND msg=audit(1513181391.611:11997): auid=1014 uid=1014 gid=1014 ses=8 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=17547 comm="boomaga" exe="/usr/bin/boomaga" sig=11 res=1"

From this it seems, IMO, that CUPS backend and d-bus are all right, and problem is somewhere in boomaga GUI binary.

fhanzlik commented 6 years ago

forgotten attachment: boomaga_w_01-pages pdf

fhanzlik commented 6 years ago

Still a vague memory; I do not know if it could be somehow related to this problem: when I install this terminalserver (sometime in February), there was problem with some MATE desktop component (mate-panel? now I do not know), which crashed on thin client session, but was working on terminalserver console. I think, at the time it was problem in Mesa os some OpenGL library, where was called non-existent procedure. Problem was solved (IMO) by installing nVidia proprietary graphics drivers, where was this procedure defined (although terminalserver and thin client did not have nVidia graphics card).

SokoloffA commented 6 years ago

What is the easiest way to run a LTSP server and client in the Virtualbox?

fhanzlik commented 6 years ago

Hi Alexander, my LTSP implementation is far from optimal. The original idea of the LTSP5 project was that system booted on diskless stations would be installed from the same packages as the LTSP server (at LTSP server was at some point - e.g. /opt/ltsp/i386/ - via chroot installed system, which was then used on diskless stations via NFS or NBD as their root FS). But as LTSP was disclaimed in Fedora 15+ (maybe also because ingoing systemd crap was not able work on NFS root filesystem), my implementation is a bit clumsy - on LTSP server is installed Fedora 25, but the diskless stations are still booting/using the original old Fedora 14 system (with six years old xorg-x11-server-Xorg-1.9.5). For this reason, it is also possible that although everything else works seamlessly, boomaga requires some newer SW on the client side - X server. When I have a little spare time, I'll try to simulate access from a disk-based station to a newer distribution. Or if you can advise what I could/should try more, I'd love to go into it.

PS: not sure, when Boomaga GUI is considered to run also standalone, without its cups backend - it seems as yes; I can run it, in File -> Open dialog open some file and then view/print it. But in this case, however, I encountered a problem - when Boomaga GUI finds the ~/.cache/boomaga.env file (from previous cups backend run?), then use it - which IMO is not good because the values in it may not be up to date. Specifically, cases where the value of the DISPLAY variable has changed are fatal ;)

SokoloffA commented 6 years ago

I think you're right. The problem may be related to the variable DISPLAY in the boomaga.env file. Try to run a new version from master branch. I made some fixies. Now I don't save DISPLAY and DBUS_SESSION_BUS_ADDRESS variables to a file.

I also added 2 scripts for testing.

  1. scripts/testDBUS.sh - launches boomaga via D-Bus, it's not created and not updated the boomaga.env file, so you can play with values in the boomaga.env file.

  2. scripts/testBackend.sh - launches boomagabackend, looks an active X session and launches boomaga. Create the boomaga.env file.