By default, Bugzilla does not search the list of RESOLVED bugs.
You can force it to do so by putting the upper-case word ALL in front of your search query, e.g.: ALL tdelibs
We recommend searching for bugs this way, as you may discover that your bug has already been resolved and fixed in a later release.

Bug 1403

Summary:	[Regression] krfb/krdc broken
Product:	TDE	Reporter:	Darrell <darrella>
Component:	tdenetwork	Assignee:	Timothy Pearson <kb9vqf>
Status:	RESOLVED FIXED
Severity:	critical	CC:	bugwatch, darrella, kb9vqf
Priority:	P5
Version:	R14.0.0 [Trinity]
Hardware:	Other
OS:	Linux
Compiler Version:		TDE Version String:
Application Version:		Application Name:

Description Darrell 2013-02-04 22:46:30 CST

krfb/krdc was broken sometime after 3.5.13.0. From my GIT Trinity desktop I can connect to a 3.5.10 and a 3.5.13.0 desktop but not to a GIT desktop.

I'm using the following krfbrc settings:

allowDesktopControl=true
allowUninvited=true
confirmUninvitedConnection=false
disableBackground=true
disableXShm=false
enableSLP=true
preferredPort=-1
uninvitedPasswordCrypted=

[invitations]
invitation_num=0


When run from konsole, a successful connection looks like this:

TQWidget::setMaximumSize: (unnamed/KRDC) Negative sizes (-1,28) are not possible
VNC server supports protocol version 3.3 (viewer 3.3)
No authentication needed
...
ShmCleanup called

The failed connections look like this:

TQWidget::setMaximumSize: (unnamed/KRDC) Negative sizes (-1,28) are not possible
VNC server supports protocol version 3.3 (viewer 3.3)
krdc: read: Connection reset by peer
ShmCleanup called

Despite allowing uninvited connections, seems the GIT version is nonetheless requiring authentication.

The only relevant places in the GIT sources I find the "Connection reset by peer" string are kvirc, which I do not have installed, and kopete/protocols/jabber/jingle/libjingle/talk/third_party/ortp/port_fct.c, which would seem unrelated to krfb/krdc.

Comment 1 Darrell 2013-02-05 17:27:29 CST

I narrowed the regression introduction to between approximately Nov. 29 and Dec. 21. My package set from Nov. 29 (git short log version 8953) allows connections. My package set from Dec. 21, (git short log version 24) does not allow connections. Note: the odd reduction in the short log numbers is due to the GIT history cleanup performed approximately Dec. 8 (http://trinity-devel.pearsoncomputing.net/?0::10744).

Comment 2 Darrell 2013-02-05 17:34:45 CST

Note: The receiving machine (krfb end) I'm using for testing uses HAL and not TDEHWLIB.

Comment 3 Darrell 2013-03-05 00:05:19 CST

This remains broken with the latest GIT of late March 3.

Comment 4 Timothy Pearson 2013-04-08 00:26:03 CDT

(In reply to comment #1)
> I narrowed the regression introduction to between approximately Nov. 29 and
> Dec. 21. My package set from Nov. 29 (git short log version 8953) allows
> connections. My package set from Dec. 21, (git short log version 24) does not
> allow connections. Note: the odd reduction in the short log numbers is due to
> the GIT history cleanup performed approximately Dec. 8
> (http://trinity-devel.pearsoncomputing.net/?0::10744).

Weird; nothing changed in krfb during that time.  krdc is similarly unaffected.

FYI, "Connection reset by peer" is a system error string and is not generated by TDE code (but may be "channelled" from the underlying system error generator to the console by TDE code).

Comment 5 Timothy Pearson 2013-04-08 01:40:00 CDT

(In reply to comment #4)
> (In reply to comment #1)
> > I narrowed the regression introduction to between approximately Nov. 29 and
> > Dec. 21. My package set from Nov. 29 (git short log version 8953) allows
> > connections. My package set from Dec. 21, (git short log version 24) does not
> > allow connections. Note: the odd reduction in the short log numbers is due to
> > the GIT history cleanup performed approximately Dec. 8
> > (http://trinity-devel.pearsoncomputing.net/?0::10744).
> 
> Weird; nothing changed in krfb during that time.  krdc is similarly unaffected.
> 
> FYI, "Connection reset by peer" is a system error string and is not generated
> by TDE code (but may be "channelled" from the underlying system error generator
> to the console by TDE code).

The only thing that pops out at me from the master commit log is the inclusion of glib main loop integration in Qt3/TQt3 during that timeframe.  Do you know if your Dec. 21 package set was built with glib main loop integration enabled?

Thanks!

Comment 6 Timothy Pearson 2013-04-08 01:57:25 CDT

(In reply to comment #5)
> (In reply to comment #4)
> > (In reply to comment #1)
> > > I narrowed the regression introduction to between approximately Nov. 29 and
> > > Dec. 21. My package set from Nov. 29 (git short log version 8953) allows
> > > connections. My package set from Dec. 21, (git short log version 24) does not
> > > allow connections. Note: the odd reduction in the short log numbers is due to
> > > the GIT history cleanup performed approximately Dec. 8
> > > (http://trinity-devel.pearsoncomputing.net/?0::10744).
> > 
> > Weird; nothing changed in krfb during that time.  krdc is similarly unaffected.
> > 
> > FYI, "Connection reset by peer" is a system error string and is not generated
> > by TDE code (but may be "channelled" from the underlying system error generator
> > to the console by TDE code).
> 
> The only thing that pops out at me from the master commit log is the inclusion
> of glib main loop integration in Qt3/TQt3 during that timeframe.  Do you know
> if your Dec. 21 package set was built with glib main loop integration enabled?
> 
> Thanks!

Never mind, a glance through .xsession-errors indicates that this failure is due to Qt functions being called from a non-Qt thread.  This may have been why krfb has always been unstable; while older versions of Qt may have allowed this (with undefined results), TDE's Qt versions instead caught the invalid usage and aborted the program.  I will look into this further.

Comment 7 Timothy Pearson 2013-04-08 11:57:49 CDT

Fixed in GIT hash 339d5c5.

Thanks for reporting!

Comment 8 Darrell 2013-04-08 12:57:01 CDT

On my list of things to test. :)

Are you able to identify what between approximately Nov. 29 and Dec. 21. finally exposed the latent bug?

Comment 9 Timothy Pearson 2013-04-08 13:07:48 CDT

(In reply to comment #8)
> On my list of things to test. :)
> 
> Are you able to identify what between approximately Nov. 29 and Dec. 21.
> finally exposed the latent bug?

Yes, the changes in Qt3/TQt3 to properly support threading.

Tim

Comment 10 Darrell 2013-04-11 22:33:10 CDT

Just tested this. Working. Thanks!