[First Page] [Previous Page] [Next Page] [Last Page]
| GIT Hash | Branch | Date | Author | Log Message |
|---|---|---|---|---|
| 7f1b1186 [view] | master | 2011-10-26 14:32:11 -0500 | Timothy Pearson | [tde-packaging] Split basket kontact integration into separate package |
| 2b178a53 [view] | master | 2011-10-26 19:03:07 +0000 | tpearson | [tdebase] Fix kdesu breaking all DCOP communication in the current TDE session This closes Bug #394 |
| 9e1f287e [view] | master | 2011-10-26 18:00:36 +0000 | tpearson | [tdebase] Provide option to enable application autocompletion in the run dialog This fixes regression bug #557 |
| e7d3e8c4 [view] | master | 2011-10-26 17:52:24 +0000 | tpearson | [tdenetwork] Fix failure to launch Kopete when statistics module is enabled due to faulty SQLite linkage when Autotools is used to build kdenetwork |
| e5bbee9b [view] | master | 2011-10-26 17:21:55 +0000 | tpearson | [kdbusnotification] Second part of prior commit |
| e62b95a2 [view] | master | 2011-10-26 17:21:27 +0000 | tpearson | [kdbusnotification] Remove incorrect user visible kdbusnotification shortcut from Kicker |
| fdadce76 [view] | master | 2011-10-26 17:20:23 +0000 | tpearson | [tdesudo] Update license headers in kdesudo This should have been done before the freeze, but it does not really matter because no compilable code was altered |
| 3df7537a [view] | master | 2011-10-26 18:41:19 +0200 | Christian Beier | [libtdevnc] Fix deadlock in threaded mode when using nested rfbClientIteratorNext() calls. Lengthy explanation follows... First, the scenario before this patch: We have three clients 1,2,3 connected. The main thread loops through them using rfbClientIteratorNext() (loop L1) and is currently at client 2 i.e. client 2's cl_2->refCount is 1. At this point we need to loop again through the clients, with cl_2->refCount == 1, i.e. do a loop L2 nested within loop L1. BUT: Now client 2 disconnects, it's clientInput thread terminates its clientOutput thread and calls rfbClientConnectionGone(). This LOCKs clientListMutex and WAITs for cl_2->refCount to become 0. This means this thread waits for the main thread to release cl_2. Waiting, with clientListMutex LOCKed! Meanwhile, the main thread is about to begin the inner rfbClientIteratorNext() loop L2. The first call to rfbClientIteratorNext() LOCKs clientListMutex. BAAM. This mutex is locked by cl2's clientInput thread and is only released when cl_2->refCount becomes 0. The main thread would decrement cl_2->refCount when it would continue with loop L1. But it's waiting for cl2's clientInput thread to release clientListMutex. Which never happens since this one's waiting for the main thread to decrement cl_2->refCount. DEADLOCK. Now, situation with this patch: Same as above, but when client 2 disconnects it's clientInput thread rfbClientConnectionGone(). This again LOCKs clientListMutex, removes cl_2 from the linked list and UNLOCKS clientListMutex. The WAIT for cl_2->refCount to become 0 is _after_ that. Waiting, with clientListMutex UNLOCKed! Therefore, the main thread can continue, do the inner loop L2 (now only looping through 1,3 - 2 was removed from the linked list) and continue with loop L1, finally decrementing cl_2->refCount, allowing cl2's clientInput thread to continue and terminate. The resources held by cl2 are not free()'d by rfbClientConnectionGone until cl2->refCount becomes 0, i.e. loop L1 has released cl2. |
| 8310ddd1 [view] | master | 2011-10-26 06:15:09 +0000 | tpearson | [gtk-qt-engine] Fix highly visible incorrect mapping of GTK generic file icon to TDE unknown mimetype icon This is rammed throught the hard freeze only due to its high visibility in common GTK applications such as Firefox |
| cb717a24 [view] | master | 2011-10-25 23:22:23 +0000 | tpearson | [tdelibs] Rebrand version string to final 3.5.13 release Trinity is now in a hard code freeze |
[First Page] [Previous Page] [Next Page] [Last Page]
© 2010-2025 Trinity Desktop Project
