Comment 1 Henrik Andersson 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 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 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 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 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 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 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 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 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 2015-02-12 09:13:34 CET

A hotfix is now available at:

https://www.cendio.com/downloads/updates/b5366/.

Comment 13 Karl Mikaelsson 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.