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 2437

Summary:	[Regression] Kdesktop hang on start
Product:	TDE	Reporter:	Slávek Banko <slavek.banko>
Component:	tdebase	Assignee:	Slávek Banko <slavek.banko>
Status:	RESOLVED FIXED
Severity:	blocker	CC:	ac586133, bugwatch, martinhodges479, slavek.banko
Priority:	P5
Version:	R14.0.0 [Trinity]
Hardware:	All
OS:	Linux
Compiler Version:		TDE Version String:
Application Version:		Application Name:
Bug Depends on:
Bug Blocks:	2246
Attachments:	Trace for main-process0 Trace for main-process1 Trace for child proces - kdesktop_lock Trace for main-process0 Trace for main-process1 Trace for child proces - kdesktop_lock tdelibs : Force to handle DCOP requests in KUniqueApplication (newInstance call)

Description Slávek Banko 2015-05-01 11:48:35 CDT

Apparently in connection with a series of patches dealt with the bug 2422 there was a new problem. When starting kdesktop happens probably race-condition when two processes kdesktop stop and wait for the lock.

For users, the problem manifests itself as a flashing fifth icon on splash screen and nothing else happens. When switching to a text console and kill the processes kdesktop remaining environment starts up - only missing kdesktop.

Normal state of running processes:

/opt/trinity/bin/kdesktop (main process)
 `- /opt/trinity/bin/kdesktop (thread)
 `- /opt/trinity/bin/kdesktop_lock --internal <pid> (child process)

When a problem occurs, there is one difference in running processes:

/opt/trinity/bin/kdesktop (main process0)
 `- /opt/trinity/bin/kdesktop (main process1)
     `- /opt/trinity/bin/kdesktop (thread)
     `- /opt/trinity/bin/kdesktop_lock --internal <pid> (child process)

The problem seems to be dead-lock between the main-process0 a main-process1.

Comment 1 Slávek Banko 2015-05-01 11:49:31 CDT

Created attachment 2495 [details]
Trace for main-process0

Comment 2 Slávek Banko 2015-05-01 11:49:57 CDT

Created attachment 2496 [details]
Trace for main-process1

Comment 3 Slávek Banko 2015-05-01 11:50:41 CDT

Created attachment 2497 [details]
Trace for child proces - kdesktop_lock

Comment 4 Alex Couture 2015-05-01 17:55:33 CDT

Hi,

I have this problem too on Ubuntu 14.10 with latest R14 nightly buildà
I tought that I have messed my TDE setup, so I crated another user to try it it would work, and the new user works, but not my old one.

By the way, my Asus EEE X101ch seems to be very prone to have thread lock issues. I can provide debug output if needed.

Alexandre

Comment 5 Slávek Banko 2015-05-02 13:41:44 CDT

During the analysis, I noticed that I had not installed the package tdebase-trinity-dbg. New traces will follow.

Comment 6 Slávek Banko 2015-05-02 13:43:36 CDT

Created attachment 2498 [details]
Trace for main-process0

Comment 7 Slávek Banko 2015-05-02 13:44:13 CDT

Created attachment 2499 [details]
Trace for main-process1

Comment 8 Slávek Banko 2015-05-02 13:44:49 CDT

Created attachment 2500 [details]
Trace for child proces - kdesktop_lock

Comment 9 Slávek Banko 2015-05-19 10:57:45 CDT

Created attachment 2508 [details]
tdelibs : Force to handle DCOP requests in KUniqueApplication (newInstance call)

The proposed patch adds enforcement to handle DCOP requests immediately upon instantiation KUniqueApplication. In my testing this successfully prevents dead-lock in kdestkop. Before pushing into the GIT I leave time for more testing.

Tim, please, you can review this patch?

Comment 10 Slávek Banko 2015-05-24 11:49:14 CDT

From the testing were all positive messages and no regressions. The patch was pushed to GIT in hash c6c1d781 (master) and a4f6021a (r14.0.x).

Comment 11 Slávek Banko 2015-08-30 10:58:51 CDT

*** Bug 2427 has been marked as a duplicate of this bug. ***