> > Recently David shared some issues with starting > Trinity. In his case the probable cause seemed to be stale > profile cache file or profile cache files using the old > prefix names. > > > > Today I stumbled across a way to stall the session > startup. I changed some settings in KControl. > > > > What caught my eye with this bug is the xsession log > error, which David saw as well: > > > > ksmserver: '<wm>' missing. > > ksmserver: Use --help to get a list of available > command line options. > > > > I traced the cause to these lines in my profile > twinrc: > > > > [ThirdPartyWM] > > WMAdditionalArguments= > > WMExecutable=twin > > > > Those lines and group do not exist in a twinrc backup > file and is the only difference between the files. > > > > This is not a hard freeze. Trinity exits gracefully > back to the command line, which is how I start X/Trinity. > > > > The problem is with tdeinit_phase1. I commented out > that command in starttde. I successfully substituted all of > the following: > > > > kwrapper ksmserver --windowmanager twin > --windowmanageraddargs "" > > > > kwrapper ksmserver --windowmanager twin > > > > kwrapper ksmserver > > > > Looking at the tdeinit_phase1 source code, I see that > when WMExecutable is undefined/empty then tdeinit_phase1 > defaults to "kwrapper ksmserver." As my previous twinrc > contained no ThirdPartyWM group in twinrc, that is how > tdeinit_phase1 always started. > > > > When I changed some settings in KControl to cause > twinrc to update with including the ThirdPartyWM group, > tdeinit_phase1 instead starts with "kwrapper ksmserver > --windowmanager %1 --windowmanageraddargs %2." > > > > Changing the twinrc WMAdditionalArguments to > WMAdditionalArguments=--lock allowed Trinity to start using > tdeinit_phase1. > > > > I think the solution then is to add the following > condition test to tdeinit_phase1: > > > > else if (wmArguments == "") { > > return_code = > system((TQString("kwrapper ksmserver --windowmanager > %1").arg(wmToLaunch)).ascii()); > > > > Comments? > > > > Darrell > > > > > This is starting to make sense. On the session before I > started experiencing crashes with starttde, I had updated the background to be > displayed in kcontrol -> login manager. I suspect what you were able to > traceback more thoroughly that I was the root cause of the crashes I experienced as well. > Good catch! I have a patch that I ask somebody either test or provide a peer review signoff. I added new code, albeit only a single "else if" test. I have tested the patch in both a VM and physical machine. No more halts in the session startup. Here is the patch: http://humanreadable.nfshost.com/trinity/patches/tdebase/tdebase-tdeinit_phase1.diff If testing the patch then do so like this: * Before patching and updating tdebase, start a Trinity session. * Open KControl, Appearance & Themes, Window Decorations. * Toggle any nominal setting and select the Apply button. * Exit the session. * Login to start a new session. * Verify the session stalls and won't start. * Restore twinrc: edit twinrc config file and delete the group section "ThirdPartyWM." * Login to verify that once again Trinity starts. * Log out. * Install the patched tdebase. * Start the session and repeat the KControl exercise. * Exit the session. * Start the session. * Verify Trinity now starts without stalling. Thanks! Darrell