Printing a large file disconnects the client

[totaam]

Issue migrated from trac ticket # 955

component: server | priority: blocker | resolution: fixed | keywords: print, printing, file size, file-size-limit

2015-08-20 00:05:47: pvenkateswaralu created the issue

---

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.

[totaam]

2015-08-20 00:27:25: pvenkateswaralu commented

---

Details:

Xpra: 0.15.4
Revision: 10209
OS: Client-Mac OSX (10.10.4), Server-Fedora 21

[totaam]

2015-08-20 09:38:49: antoine changed owner from antoine to pvenkateswaralu

[totaam]

2015-08-20 09:38:49: antoine commented

---

I also tried going into the xpra.conf file and set the file-size-limit = 30 MB. But that also gave the same result.
[[BR]]
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:

• remove or at least hide the unused file-size-limit option
• hardcode a higher (configurable via env var?) value for the maximum packet size
• cherry pick some of the more self-contained and obvious changes from r10360 - at the very least so that we don't disconnect the client!

@pvenkateswaralu: please confirm in trunk:

• that printing works
• that the limits are honoured and do not cause disconnection when they're hit, this is what I see now when I set the limit artificially lower (1MB):

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:

• chunking, etc (see file channel for upload/download from server #494)
• avoiding the unnecessary conversion to postscript when we get a pdf (see html5 printing #913)

[totaam]

2015-08-20 10:36:07: antoine changed title from Printing a file of size > 16384000 bytes disconnects the client to Printing a large file disconnects the client

[totaam]

2015-08-20 10:36:07: antoine commented

---

(editing the ticket title to remove a numeric value which is not relevant)

[totaam]

2015-08-21 03:15:11: antoine changed priority from major to blocker

[totaam]

2015-08-21 03:15:11: antoine commented

---

(blocker for 0.15.x)

[totaam]

2015-08-21 19:13:21: pvenkateswaralu changed owner from pvenkateswaralu to antoine

[totaam]

2015-08-21 19:13:21: pvenkateswaralu commented

---

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

[totaam]

2015-08-21 19:17:13: pvenkateswaralu commented

---

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. [[BR]]
[[BR]]

OS: Client - Mac OSX 10.10.4 Server: Fedora 21
Xpra: 0.16.0
revision: Client: r10380 Server: r10259

[totaam]

2015-08-22 03:33:15: antoine changed owner from antoine to pvenkateswaralu

[totaam]

2015-08-22 03:33:15: antoine commented

---

This is a different error, can you please provide simple steps so that I can reproduce? (command lines, xpra info..)

[totaam]

2015-08-27 21:18:33: pvenkateswaralu uploaded file ticket955-print_image-just-before-client-crashes-due-to-printing..png (811.6 KiB)

[totaam]

2015-08-27 21:19:04: pvenkateswaralu uploaded file ticket955-printing-logs.txt (16.5 KiB)

[totaam]

2015-08-27 21:29:41: pvenkateswaralu changed owner from pvenkateswaralu to antoine

[totaam]

2015-08-27 21:29:41: pvenkateswaralu commented

---

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. [[BR]][[BR]]

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 [[BR]]
[[Image(ticket955-print_image-just-before-client-crashes-due-to-printing.png)]] [[BR]]
[[BR]][[BR]]

And, I have attached the server side and client side debug logs ----> File named ---> ticket955-printing-logs.txt [[BR]]
[[BR]]
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

[totaam]

2015-08-27 21:56:57: pvenkateswaralu uploaded file ticket955-before-crash.png (306.2 KiB)

[totaam]

2015-08-27 21:57:14: pvenkateswaralu uploaded file ticket955-after-crash.png (482.9 KiB)

[totaam]

2015-08-27 21:58:18: pvenkateswaralu commented

---

Replying to [comment:7 antoine]:

This is a different error, can you please provide simple steps so that I can reproduce? (command lines, xpra info..)
[[BR]]
[[BR]]

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.
[[BR]]
[[BR]]

Here are some simple steps for you to reproduce the same:[[BR]]
[[BR]]

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

9. Now check the size of the start_terminal window and the size of the browser.

[[BR]]
[[BR]]
Here are the screenshots of the images.

1. [[Image(ticket955-before-crash.png)]][[BR]]
   [[BR]]
2. [[Image(ticket955-after-crash.png)]][[BR]]
   [[BR]]

[[BR]]
Details:[[BR]]
[[BR]]

1. Xpra [[BR]]
   client: 0.16.0 r10380 -- MAC OSX 10.10.4[[BR]]
   Server 0.16.0 r10306 -- Fedora 21

[totaam]

2015-08-27 22:32:34: pvenkateswaralu uploaded file ticket_955_info.txt (108.8 KiB)

[totaam]

2015-08-29 15:18:43: antoine changed owner from antoine to pvenkateswaralu

[totaam]

2015-08-29 15:18:43: antoine changed component from android to server

[totaam]

2015-08-29 15:18:43: antoine commented

---

• you're running a server older than the attempt at a fix
• if there are window positioning or size issues, please file a separate ticket (this one is a blocker about printing and disconnections)
• please try to keep the logs in separate attachments (rather than combining client and server in one file)

FWIW: I've tried it and it worked fine here.

[totaam]

2015-09-03 17:43:02: pvenkateswaralu uploaded file ticket955_16.0-10512_16.0-10513.png (517.0 KiB)

[totaam]

2015-09-03 18:01:56: pvenkateswaralu commented

---

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 -----

[[Image(ticket955_16.0-10512_16.0-10513.png)]]

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

[totaam]

2015-09-03 18:02:17: pvenkateswaralu uploaded file ticket955-print-info_16.0-fedora21-r10513---16.0-osx-10.10.3-r10512.txt (111.4 KiB)

[totaam]

2015-09-03 18:33:07: antoine commented

---

@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?
[[BR]]

This time, the client did not crash.
[[BR]]
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.

[[BR]]

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.
[[BR]]
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)

[totaam]

2015-09-11 22:59:54: pvenkateswaralu changed owner from pvenkateswaralu to antoine

[totaam]

2015-09-11 22:59:54: pvenkateswaralu commented

---

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.

[totaam]

2015-09-12 17:46:39: antoine changed owner from antoine to pvenkateswaralu

[totaam]

2015-09-12 17:46:39: antoine commented

---

Since the crash is gone, please close this bug and:

• create a new ticket for landscape printing (including the logs for each case, and maybe the relevant extract from the cups logs / journal) - FWIW: works fine here with 0.16.0
• create new tickets for the issues from comment:9 / comment:11 / comment:12 - if these bugs are still present

PS: backport to v0.15.x in 10631

[totaam]

2015-09-14 17:52:42: pvenkateswaralu changed status from new to closed

[totaam]

2015-09-14 17:52:42: pvenkateswaralu set resolution to fixed

[totaam]

2015-09-15 13:55:01: antoine commented

---

Apparently, all the unrelated issues mentioned in this ticket are resolved... (no idea how / why since I didn't fix any)