Bug 5366 - Multiple spawns of print job when using ThinLinc client version >= 4.2.0 on windows platform
Summary: Multiple spawns of print job when using ThinLinc client version >= 4.2.0 on w...
Status: CLOSED FIXED
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: Client (show other bugs)
Version: 4.2.0
Hardware: PC Unknown
: P2 Normal
Target Milestone: 4.4.0
Assignee: Henrik Andersson
URL:
Keywords: derfian_tester, relnotes
Depends on:
Blocks:
 
Reported: 2014-11-21 16:56 CET by Henrik Andersson
Modified: 2015-05-06 12:48 CEST (History)
1 user (show)

See Also:
Acceptance Criteria:


Attachments

Description Henrik Andersson cendio 2014-11-21 16:56:49 CET
As reported by issue 15645, ThinLinc client version 4.2.0 spawns hundreds of print jobs when printing to thinlocal.

After some testing, the issue is reproduced using ThinLinc 4.2.0 server on RHEL6 and 4.2.0 client on win7.

The issue was only reproduced once and I failed to reproduce a second time when i wanted the debug log file from the client. I cleaned up %temp%/lpdX stray file and after that i could reproduce the issue.
Comment 1 Henrik Andersson cendio 2014-11-21 16:58:39 CET
Here is a copy from debug log file from the client:

2014-11-21T16:24:09: ssh[E]: debug1: client_input_channel_open: ctype forwarded-tcpip rchan 14 win 2097152 max 32768
2014-11-21T16:24:09: ssh[E]: debug1: client_request_forwarded_tcpip: listen localhost port 4913, originator 127.0.0.1 port 38237
2014-11-21T16:24:09: ssh[E]: debug1: connect_next: host 127.0.0.1 ([127.0.0.1]:49495) in progress, fd=488
2014-11-21T16:24:09: ssh[E]: debug1: channel 6: new [127.0.0.1]
2014-11-21T16:24:09: ssh[E]: debug1: confirm forwarded-tcpip
2014-11-21T16:24:09: ssh[E]: debug1: channel 6: connected to 127.0.0.1 port 49495
2014-11-21T16:24:09: New thinlocal printer job, receiving to: C:\Users\admin\AppData\Local\Temp\lpd11
2014-11-21T16:24:09: Finished receiving printer job
2014-11-21T16:24:09: Printing job with title "Unsaved Document 1" and type "application/pdf" (1 copies).
2014-11-21T16:24:09: Print command: C:\Users\admin\Desktop\tl-4.2.0-client-windows\sumatrapdf.exe -exit-on-print -print-to-default C:\Users\admin\AppData\Local\Temp\lpd11
2014-11-21T16:24:09: WinProcess: Started process 1928 (sumatrapdf.exe)
2014-11-21T16:24:10: WinProcess: Terminating process 1928 (sumatrapdf.exe)...
2014-11-21T16:24:10: Recieved EOF on fd 800
2014-11-21T16:24:10: WinProcess: Process 1928 (sumatrapdf.exe) has already terminated
2014-11-21T16:24:10: WinProcess: Started process 2908 (sumatrapdf.exe)
2014-11-21T16:24:10: WinProcess: Terminating process 2908 (sumatrapdf.exe)...
2014-11-21T16:24:10: ssh[E]: debug1: channel 6: free: 127.0.0.1, nchannels 7
2014-11-21T16:24:10: WinProcess: Process 2908 (sumatrapdf.exe) has already terminated
2014-11-21T16:24:10: WinProcess: Started process 3212 (sumatrapdf.exe)
2014-11-21T16:24:10: WinProcess: Terminating process 3212 (sumatrapdf.exe)...
2014-11-21T16:24:10: WinProcess: Process 3212 (sumatrapdf.exe) has already terminated
2014-11-21T16:24:10: WinProcess: Started process 2040 (sumatrapdf.exe)
2014-11-21T16:24:11: WinProcess: Terminating process 2040 (sumatrapdf.exe)...
2014-11-21T16:24:11: WinProcess: Process 2040 (sumatrapdf.exe) has already terminated
Comment 2 Henrik Andersson cendio 2014-11-21 17:00:06 CET
(In reply to comment #0)
> As reported by issue 15645, ThinLinc client version 4.2.0 spawns hundreds of
> print jobs when printing to thinlocal.
> 
> After some testing, the issue is reproduced using ThinLinc 4.2.0 server on
> RHEL6 and 4.2.0 client on win7.
> 
> The issue was only reproduced once and I failed to reproduce a second time when
> i wanted the debug log file from the client. I cleaned up %temp%/lpdX stray
> file and after that i could reproduce the issue.

Each print job pushed on queue is the same as the original job file.

As mentioned on the issue from customer, using ThinLinc client 4.1.1 does not produces this issue.
Comment 3 Karl Mikaelsson cendio 2014-11-25 09:54:03 CET
We've got reports of similar problems with the 4.3.0 client too.
Comment 5 Henrik Andersson cendio 2014-12-08 14:02:31 CET
When commenting out the fl:check() introduced in commit r28245 part of bug #4886, the problem is not reproducible.

After a discussion with Pierre the reason can be that the connection object is deleted which also deletes the WinProcess further down the stack. Needs to be verified.
Comment 6 Henrik Andersson cendio 2014-12-08 14:13:51 CET
(In reply to comment #5)
> When commenting out the fl:check() introduced in commit r28245 part of bug
> #4886, the problem is not reproducible.
> 
> After a discussion with Pierre the reason can be that the connection object is
> deleted which also deletes the WinProcess further down the stack. Needs to be
> verified.

Commented out the delete of the connection object in Service::removeConnection()
and tried to reproduce the printing issue 8 times which failed.
This is most probably the cause for the issue.

The call flow is:

WinProcess::KillProcess() -> fl::check() -> 
( data is available to be read on socket) -> ServConnection::readData() (EOF is return) -> ServiceTCP::readData() calls removeConnection() when EOF is triggered...
Comment 7 Henrik Andersson cendio 2014-12-08 14:13:51 CET
(In reply to comment #5)
> When commenting out the fl:check() introduced in commit r28245 part of bug
> #4886, the problem is not reproducible.
> 
> After a discussion with Pierre the reason can be that the connection object is
> deleted which also deletes the WinProcess further down the stack. Needs to be
> verified.

Commented out the delete of the connection object in Service::removeConnection()
and tried to reproduce the printing issue 8 times which failed.
This is most probably the cause for the issue.

The call flow is:

WinProcess::KillProcess() -> fl::check() -> 
( data is available to be read on socket) -> ServConnection::readData() (EOF is return) -> ServiceTCP::readData() calls removeConnection() when EOF is triggered...
Comment 8 Henrik Andersson cendio 2014-12-15 09:51:33 CET
The solution would be to add a recursive lock to prevent each service connection to recursively process data on socket. However this requires some refactory to realize, due to restraints in current design.
Comment 9 Henrik Andersson cendio 2014-12-15 10:44:21 CET
(In reply to comment #8)
> The solution would be to add a recursive lock to prevent each service
> connection to recursively process data on socket. However this requires some
> refactory to realize, due to restraints in current design.

Fixed in commit 29729.
Comment 10 Henrik Andersson cendio 2014-12-15 10:46:18 CET
This change(In reply to comment #9)
> (In reply to comment #8)
> > The solution would be to add a recursive lock to prevent each service
> > connection to recursively process data on socket. However this requires some
> > refactory to realize, due to restraints in current design.
> 
> Fixed in commit 29729.

This change affects socket based services and needs to be tested, printing (LPD service) / smartcard authentication (unix socket) on both linux and windows platform to trig affected code paths/implementations.
Comment 12 Peter Åstrand cendio 2015-02-12 09:13:34 CET
A hotfix is now available at:

https://www.cendio.com/downloads/updates/b5366/.
Comment 13 Karl Mikaelsson cendio 2015-05-06 12:48:47 CEST
This seems to work just fine (apart from me finding bug 5518). I haven't yet been able to reproduce the multiple-print-jobs bug, and both printing and smart card authentication still work on Linux and Windows.

Note You need to log in before you can comment on or make changes to this bug.