Commit History

GIT Hash	Branch	Date	Author	Log Message
f1bfe53f [view]	master	2007-03-24 23:23:25 +0000	runge	[libtdevnc] reverse (listening) VNC connections.
d013b876 [view]	master	2007-03-20 23:35:08 +0000	runge	[libtdevnc] ssvnc: sync to 1.0.13 release.
5e454662 [view]	master	2007-03-20 23:33:04 +0000	runge	[libtdevnc] x11vnc: -httpsredir, x11cursor fix, nc=N login opt, no -ncache betatest for java viewer.
f57eb874 [view]	master	2007-03-20 23:26:33 +0000	runge	[libtdevnc] Add "Connection: close" to HTTP replies.
61cd498f [view]	master	2007-03-17 00:13:12 +0000	dscho	[libtdevnc] Fix a locking problem in libvncserver There seems to be a locking problem in libvncserver, with respect to how condition variables are used. On certain machines in our lab, when using a vncviewer to view a display that has a very high rate of updates, we will occasionally see the VNC server process crash. In one stack trace that was obtained, an assertion had tripped in glibc's pthread_cond_wait, which was called from clientOutput. Inspection of clientOutput suggests that WAIT is being called incorrectly. The mutex that protects a condition variable should always be locked when calling wait, and on return from the wait will still be locked. The attached patch fixes the locking around this condition variable, and one other that I found by grepping the source for similar occurrences. Signed-off-by: Charles Coffing
9e1230c7 [view]	master	2007-03-13 23:12:06 +0000	runge	[libtdevnc] ssvnc: sync src/patches/tight-vncviewer-full.patch
15f792bc [view]	master	2007-03-13 23:06:38 +0000	runge	[libtdevnc] x11vnc: fix crash for kde dcop. limit ncache beta tester to 96MB viewers.
0d4870c0 [view]	master	2007-02-19 23:00:42 +0000	runge	[libtdevnc] ssvnc: more fixes for painting problems.
23f6dc3d [view]	master	2007-02-19 22:57:44 +0000	runge	[libtdevnc] x11vnc: fix -users bob= in -inetd mode.
23178cd1 [view]	master	2007-02-19 03:11:25 +0000	runge	[libtdevnc] store 1.0.12 snapshot.

GIT Hash

Branch

Date

Author

Log Message

f1bfe53f [view]

master

2007-03-24 23:23:25 +0000

runge

[libtdevnc] reverse (listening) VNC connections.

d013b876 [view]

master

2007-03-20 23:35:08 +0000

runge

[libtdevnc] ssvnc: sync to 1.0.13 release.

5e454662 [view]

master

2007-03-20 23:33:04 +0000

runge

[libtdevnc] x11vnc: -httpsredir, x11cursor fix, nc=N login opt, no -ncache betatest for java viewer.

f57eb874 [view]

master

2007-03-20 23:26:33 +0000

runge

[libtdevnc] Add "Connection: close" to HTTP replies.

61cd498f [view]

master

2007-03-17 00:13:12 +0000

dscho

[libtdevnc] Fix a locking problem in libvncserver
There seems to be a locking problem in libvncserver, with respect to how
condition variables are used.
On certain machines in our lab, when using a vncviewer to view a display
that has a very high rate of updates, we will occasionally see the VNC
server process crash. In one stack trace that was obtained, an assertion
had tripped in glibc's pthread_cond_wait, which was called from
clientOutput.
Inspection of clientOutput suggests that WAIT is being called incorrectly.
The mutex that protects a condition variable should always be locked when
calling wait, and on return from the wait will still be locked. The
attached patch fixes the locking around this condition variable, and one
other that I found by grepping the source for similar occurrences.
Signed-off-by: Charles Coffing

9e1230c7 [view]

master

2007-03-13 23:12:06 +0000

runge

[libtdevnc] ssvnc: sync src/patches/tight-vncviewer-full.patch

15f792bc [view]

master

2007-03-13 23:06:38 +0000

runge

[libtdevnc] x11vnc: fix crash for kde dcop. limit ncache beta tester to 96MB viewers.

0d4870c0 [view]

master