www.cendio.com
Bug 5366 - Multiple spawns of print job when using ThinLinc client version >= 4.2.0 on windows platform
: Multiple spawns of print job when using ThinLinc client version >= 4.2.0 on w...
Status: CLOSED FIXED
: ThinLinc
Client
: 4.2.0
: PC Unknown
: P2 Normal
: 4.4.0
Assigned To:
:
:
:
:
  Show dependency treegraph
 
Reported: 2014-11-21 16:56 by
Modified: 2015-05-06 12:48 (History)
Acceptance Criteria:


Attachments


Note

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


Description From cendio 2014-11-21 16:56:49
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 From cendio 2014-11-21 16:58:39 -------
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 From cendio 2014-11-21 17:00:06 -------
(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 From cendio 2014-11-25 09:54:03 -------
We've got reports of similar problems with the 4.3.0 client too.
------- Comment #5 From cendio 2014-12-08 14:02:31 -------
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 From cendio 2014-12-08 14:13:51 -------
(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 From cendio 2014-12-08 14:13:51 -------
(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 From cendio 2014-12-15 09:51:33 -------
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 From cendio 2014-12-15 10:44:21 -------
(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 From cendio 2014-12-15 10:46:18 -------
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 From cendio 2015-02-12 09:13:34 -------
A hotfix is now available at:

https://www.cendio.com/downloads/updates/b5366/.
------- Comment #13 From cendio 2015-05-06 12:48:47 -------
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.