xpra 0.15.4 successfully prints a file of size < 16384000 bytes (15.625 MB). Any file which is greater than the above mentioned size disconnects the client and gives the following error.
2015-08-19 15:56:28,487 Received invalid packet: packet size requested is 38544305 but maximum allowed is 16384000 2015-08-19 15:56:28,501 Connection lost Exception in thread parse (most likely raised during interpreter shutdown):
I also tried going into the xpra.conf file and set the file-size-limit = 30 MB. But that also gave the same result.
Details:
Xpra: 0.15.4 Revision: 10209 OS: Client-Mac OSX (10.10.4), Server-Fedora 21
I also tried going into the xpra.conf file and set the file-size-limit = 30 MB. But that also gave the same result.
That's because the file size you print is not the one that gets sent over the wire, though in the future maybe it will be (see #913).
Also, as per the log message, by the time it gets to the transport, the file size is 38544305 (~36MB). And even if you had increased above 36MB, it would not have worked because the file size limits were not honoured (a bug). And even if it had been honoured, the packet size limit might have been lower... and this is the one that caused the disconnection!
Now...
The correct changes (and much more) are in r10360 (+minor improvements in r10361 + r10362), please see the long commit message for details. Even if this commit is trimmed, it is too large for backports to 0.15.x. So, for that branch I am thinking of doing this instead:
@pvenkateswaralu: please confirm in trunk:
Warning: cannot print the file 'CgUsersManual.pdf.gz' this file is too large: 2MB the file size limit for ServerSource(Protocol(unix-domain socket:/home/antoine/.xpra/desktop-13)) is 1MB
To print more quickly during testing, I've used:
#xpra print :DISPLAY filename mimetype UUID Title PrinterName NoOfCopies PrinterOptions xpra print :10 /path/to/thefile/CgUsersManual.pdf.gz 'application/pdf' '*' 'Test Print' 'iP2700-series' 1 '' -d print
Make sure you include -d printing
logs if you have issues.
Some things that still need to be addressed:
(editing the ticket title to remove a numeric value which is not relevant)
(blocker for 0.15.x)
Printing a file on xpra 0.16.x (r10380) also crashes the client. I am not really sure if this is because of the file size or if there are any other limitations. But here is the error log I get when it happens:
2015-08-21 11:02:24,064 Received uninterpretable nonsense: invalid packet header: '50001506042a9bce' read buffer='P\x00\x15\x06\x04*\x9b\xce' 2015-08-21 11:02:24,064 packet no 9074 data: 'P\x00\x15\x06\x04*\x9b\xce' 2015-08-21 11:02:24,090 Connection lost
OS: Client - Mac OSX 10.10.4 Server: Fedora 21 Xpra: 0.16.0 revision: Client: 10380 Server: 10259
Also, when I relaunch xpra after the client crashes (due to printing defect), the default window size of the browser and the start terminal of the server are swapped.
OS: Client - Mac OSX 10.10.4 Server: Fedora 21 Xpra: 0.16.0 revision: Client: r10380 Server: r10259
This is a different error, can you please provide simple steps so that I can reproduce? (command lines, xpra info..)
I ran xpra 0.16.0--Mac OSX 10.10.4 (r10380) on the client side and 0.16.0--Fedora21-(r10306) on the server side to see if printing still crashes the client. And, it did crash the client.
Also, just before the client crashed, the image that was supposed to be printed was sectioned in the browser (I have attached the image for clear understanding) ---> File named ---> ticket955-print_image-just-before-client-crashes-due-to-printing.png
And, I have attached the server side and client side debug logs ----> File named ---> ticket955-printing-logs.txt
Also attached the xpra info logs I retrieved with the command xpra info :13 > ticket_955_info.txt 2>&1
---> Attahment ---> ticket_955_info.txt
Replying to antoine:
This is a different error, can you please provide simple steps so that I can reproduce? (command lines, xpra info..)
I couldn't reproduce "swapping the window size of browser and start_terminal" when I ran xpra 16.0. However, the sizes of both the windows differed from when the xpra was launched to when xpra was relaunched after the crash (due to printing) occured.
Here are some simple steps for you to reproduce the same:
1) Launch xpra on the server side with xpra start :13 --no-daemon --bind-tcp=0.0.0.0:2200 --start-new-commands=yes --start-child=xterm -d printing
2) Launch xpra on the client side with ./xpra attach tcp:10.0.32.148:2200 -d printing
3) Open google-chrome on xpra
4) Check the size of the start_terminal window and the size of the browser
5) Now browse for the image, http://s3images.coroflot.com/user_files/individual_files/original_295126_8JBnzGyjaSii0SmYlRiMimRDG.jpg
6) Print with the shortcut cmd+shift+p
7) xpra client crashes
8) Relaunch xpra on the client side with the same statement as above ./xpra attach tcp:10.0.32.148:2200 -d printing
8) Now check the size of the start_terminal window and the size of the browser.
Here are the screenshots of the images.
1)
2)
Details:
1) Xpra
client: 0.16.0 r10380 -- MAC OSX 10.10.4
Server 0.16.0 r10306 -- Fedora 21
FWIW: I've tried it and it worked fine here.
I tried printing the file --> http://s3images.coroflot.com/user_files/individual_files/original_295126_8JBnzGyjaSii0SmYlRiMimRDG.jpg to see if the client crashes on the latest xpra revisions avaialble.
Client---xpra-16.0-r10512---MacOSX-10.10.3 Server---xpra-16.0-r10513---Fedora21
This time, the client did not crash. However, the image that I was trying to print appeared like the one below after I hit the print
command -----
Neither did the file get printed, nor did the client/server crashed. Once I maximized the browser window and then minimized it, the double-window screen as shown in the above picture disappeared and appeared normal as just 1 image.
I launched xpra with -d printing
on both server and client sides, and here's what the logs look like ----
Server logs:
[8759:8759:0903/092608:ERROR:browser_main_loop.cc(237)] <unknown>: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.Avahi was not provided by any .service files [8759:8759:0903/092608:ERROR:browser_main_loop.cc(237)] <unknown>: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.Avahi was not provided by any .service files 2015-09-03 09:30:22,430 New unix-domain connection received on /home/jimador/.xpra/Fedora21-Server-288-13 2015-09-03 09:30:22,431 New unix-domain connection received on /home/jimador/.xpra/Fedora21-Server-288-13 2015-09-03 09:30:22,435 Connection lost 2015-09-03 09:30:22,450 processing info request from unix-domain socket:/home/jimador/.xpra/Fedora21-Server-288-13 2015-09-03 09:30:22,765 Connection lost
Client Logs:
2015-09-03 09:40:41,510 UI thread is now blocked 2015-09-03 09:40:41,511 UI thread is running again, resuming 2015-09-03 09:41:33,484 UI thread is now blocked 2015-09-03 09:41:33,484 UI thread is running again, resuming 2015-09-03 09:43:10,724 UI thread is now blocked 2015-09-03 09:43:11,253 UI thread is running again, resuming 2015-09-03 09:44:11,349 UI thread is now blocked 2015-09-03 09:44:11,349 UI thread is running again, resuming 2015-09-03 09:45:11,953 UI thread is now blocked
Also, attached is the xpra info ----> ticket955-print-info_16.0-fedora21-r10513---16.0-osx-10.10.3-r10512.txt
@pvenkateswaralu: there's nothing in these logs, are you certain that the server is configured properly? (selinux disabled, sys group membership, etc)
Does the print dialog work any better using other applications, like gedit?
On OSX, what does the ./Xpra.app/Contents/Helpers/Print
tool say? (and on the server run xpra/platform/printing.py
)
Does it work any better from a different client OS?
This time, the client did not crash.
Since printing is not working at all, not even getting to the point where the server tries to send something to the client, it is not exercising the problematic network code, so that does not tell us if the fix helped or not.
Once I maximized the browser window and then minimized it, the double-window screen as shown in the above picture disappeared and appeared normal as just 1 image.
If I understand this correctly, it sounds like a different bug to do with window dimensions.
Once you fix your printing issues, please verify that you cannot cause the client to disconnect and close this crash ticket as fixed, then open a new one for the chrome print dialog. (dialogs and windows have nothing to do with printing subsystem, even if they are in fact "print" dialogs)
I tried printing files of all possible sizes I could think of, and it worked successfully in all cases without causing any kind of crash.
Here are the versions: Client---xpra-16.0-r10624---MacOSX-10.10.3 Server---xpra-16.0-r10508---Fedora21
However, the printing did not support landscape orientation. And the client/server logs with -d printing
looked the same in case of portrait and landscape printing (Let me know if you want me to attach them).
Are there any debugging tools other than -d printing
that could be of use to check the landscape printing?
Also, please let me know if I should close the current ticket and file a new one for the landscape issue.
Since the crash is gone, please close this bug and:
PS: backport to v0.15.x in r10631
Apparently, all the unrelated issues mentioned in this ticket are resolved... (no idea how / why since I didn't fix any)
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/955