xpra icon
Bug tracker and wiki

Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#955 closed defect (fixed)

Printing a large file disconnects the client

Reported by: pvenkateswaralu Owned by: pvenkateswaralu
Priority: blocker Milestone: 0.16
Component: server Version: 0.15.x
Keywords: print, printing, file size, file-size-limit Cc: pvenkateswaralu@…

Description

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.

Attachments (7)

ticket955-print_image-just-before-client-crashes-due-to-printing..png (811.6 KB) - added by pvenkateswaralu 4 years ago.
ticket955-printing-logs.txt (16.5 KB) - added by pvenkateswaralu 4 years ago.
ticket955-before-crash.png (306.2 KB) - added by pvenkateswaralu 4 years ago.
ticket955-after-crash.png (482.9 KB) - added by pvenkateswaralu 4 years ago.
ticket_955_info.txt (108.8 KB) - added by pvenkateswaralu 4 years ago.
ticket955_16.0-10512_16.0-10513.png (517.0 KB) - added by pvenkateswaralu 4 years ago.
ticket955-print-info_16.0-fedora21-r10513---16.0-osx-10.10.3-r10512.txt (111.4 KB) - added by pvenkateswaralu 4 years ago.

Change History (23)

comment:1 Changed 4 years ago by pvenkateswaralu

Cc: pvenkateswaralu@… added

Details:

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

comment:2 Changed 4 years ago by Antoine Martin

Owner: changed from Antoine Martin to pvenkateswaralu

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:

  • 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 #494)
  • avoiding the unnecessary conversion to postscript when we get a pdf (see #913)
Last edited 4 years ago by Antoine Martin (previous) (diff)

comment:3 Changed 4 years ago by Antoine Martin

Summary: Printing a file of size > 16384000 bytes disconnects the clientPrinting a large file disconnects the client

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

comment:4 Changed 4 years ago by Antoine Martin

Priority: majorblocker

(blocker for 0.15.x)

comment:5 Changed 4 years ago by pvenkateswaralu

Owner: changed from pvenkateswaralu to Antoine Martin

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

comment:6 Changed 4 years ago by pvenkateswaralu

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

Last edited 4 years ago by Antoine Martin (previous) (diff)

comment:7 Changed 4 years ago by Antoine Martin

Owner: changed from Antoine Martin to pvenkateswaralu

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

Changed 4 years ago by pvenkateswaralu

Attachment: ticket955-printing-logs.txt added

comment:8 Changed 4 years ago by pvenkateswaralu

Owner: changed from pvenkateswaralu to Antoine Martin

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
No image "ticket955-print_image-just-before-client-crashes-due-to-printing.png" attached to Ticket #955


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

Last edited 4 years ago by pvenkateswaralu (previous) (diff)

Changed 4 years ago by pvenkateswaralu

Attachment: ticket955-before-crash.png added

Changed 4 years ago by pvenkateswaralu

Attachment: ticket955-after-crash.png added

comment:9 in reply to:  7 Changed 4 years ago by pvenkateswaralu

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

Changed 4 years ago by pvenkateswaralu

Attachment: ticket_955_info.txt added

comment:10 Changed 4 years ago by Antoine Martin

Component: androidserver
Owner: changed from Antoine Martin to pvenkateswaralu
  • 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.

Changed 4 years ago by pvenkateswaralu

comment:11 Changed 4 years ago by pvenkateswaralu

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

comment:12 Changed 4 years ago by Antoine Martin

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

comment:13 Changed 4 years ago by pvenkateswaralu

Owner: changed from pvenkateswaralu to Antoine Martin

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.

comment:14 Changed 4 years ago by Antoine Martin

Owner: changed from Antoine Martin to pvenkateswaralu

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 r10631

Last edited 4 years ago by Antoine Martin (previous) (diff)

comment:15 Changed 4 years ago by pvenkateswaralu

Resolution: fixed
Status: newclosed

comment:16 Changed 4 years ago by Antoine Martin

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

Note: See TracTickets for help on using tickets.