Re: [trinity-users] Mageia 6 crash on login, can't start desktop

On 08/09/17 02:13, wofgdkncxojef(a)gmail.com wrote: I increased the number to 500, but that didn't seem to have any effect, drkonqi still vanished at the exact moment the debugging symbols appear in the backtrace tab. However making the following edit at that point as per your instructions: $TDEDIR/bin/kdesktop $TDEDIR/bin/kicker $TDEDIR/bin/twin # Wait if there's any crashhandler shown. #while $TDEDIR/bin/dcop | grep -q ^drkonqi- ; do while true sleep 5 done Has got me to a point where Trinity is running, with the following minor caveats: - The splash screen doesn't close automatically, but does go away when I click on it. - Nothing in the system tray starts, I'm guessing there's another scripts I need to call manually. Individually loading the relevant programmes works just fine. There's only 2 I care about, so not that big a deal. So at least I'm back on Trinity. Phew and thank you! In the interests of experimentation, I've now tried starting ksmserver manually after starting Trinity. drkonqi appears as before. The general tab is selected by default, if I don't click on anything, the window stays open indefinitely, but doesn't tell me much. If I click the backtrace tab, then the backtrace starts to load, but the window closes the instant that something useful starts to appear. I've tried clicking the report crash button, I get the wait icon on the mouse for a moment, after which the window closes with no further messages. I've also tried running ksmserver using gdb with all the recommended debuginfo stuff installed and got the following: Program received signal SIGSEGV, Segmentation fault. TQString::TQString (this=0x7fffffffc8b8, s=...) at tools/qstring.cpp:1516 1516 d(s.d) Which is at least giving me a line number now. After installing the full debuginfo, I also tried running ksmserver normally again, drkonqi pops up and upon clicking on the backtrace tab, the trace starts to populate, this time the window didn't close immediately, it seems that drkonqui closes the instant the backtrace is complete, unfortunately trying to copy and paste the backtrace out while it was running in order to grab some of it proved to be almost impossible, the selection keeps cancelling itself before I can get it into the clipboard, the following is all I could get from a much longer trace: [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". 0x00007fd6177fd7f0 in __nanosleep_nocancel () at ../sysdeps/unix/syscall-template.S:84 84 T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS) ==== (gdb) bt ==== #0 0x00007fd6177fd7f0 in __nanosleep_nocancel () at ../sysdeps/unix/syscall-template.S:84 #1 0x00007fd6177fd6ac in __sleep (seconds=0, seconds@entry=1) at ../sysdeps/unix/sysv/linux/sleep.c:138 #2 0x00007fd6157cef5a in TDECrash::startDrKonqi (argv=argv@entry=0x7ffe672c4eb0, argc=argc@entry=17) at /usr/src/debug/trinity-tdelibs-14.0.4/tdecore/kcrash.cpp:312 #3 0x00007fd6157cf3a9 in TDECrash::defaultCrashHandler (sig=<optimized out>) at /usr/src/debug/trinity-tdelibs-14.0.4/tdecore/kcrash.cpp:229 #4 <signal handler called> #5 TQString::TQString (this=0x7ffe672c5558, s=...) at tools/qstring.cpp:1516 #6 0x00007fd61589c7bf in operator+ (s2=..., s1=...) at /usr/include/tqt3/ntqstring.h:1016 #7 TDEGenericDevice::uniqueID (this=this@entry=0x0) at /usr/src/debug/trinity-tdelibs-14.0.4/tdecore/tdehw/tdegenericdevice.cpp:107 #8 0x00007fd61587db2f in TDEHardwareDevices::processModifiedCPUs (this=this@entry=0x1d35890) at /usr/src/debug/trinity-tdelibs-14.0.4/tdecore/tdehw/tdehardwaredevices.cpp:863 #9 0x00007fd615889c12 in TDEHardwareDevices::addCoreSystemDevices (this=this@entry=0x1d35890) at /usr/src/debug/trinity-tdelibs-14.0.4/tdecore/tdehw/tdehardwaredevices.cpp:3601 #10 0x00007fd61589077a in TDEHardwareDevices::queryHardwareInformation (this=this@entry=0x1d35890) at /usr/src/debug/trinity-tdelibs-14.0.4/tdecore/tdehw/tdehardwaredevices.cpp:3457 #11 0x00007fd615890e3e in TDEHardwareDevices::TDEHardwareDevices (this=0x1d35890) at /usr/src/debug/trinity-tdelibs-14.0.4/tdecore/tdehw/tdehardwaredevices.cpp:217 #12 0x00007fd6157e137e in TDEInstance::hardwareDevices (this=0x7ffe672c65b8) at /usr/src/debug/trinity-tdelibs-14.0.4/tdecore/kinstance.cpp:290 #13 0x00007fd6157da0ff in TDEGlobal::hardwareDevices () at /usr/src/debug/trinity-tdelibs-14.0.4/tdecore/tdeglobal.cpp:91 This appears to be coming from gdb as well, but I can't fathom out the magic incantation to get gdb to give this full output when run directly. When running with gdb at the command prompt I do get this cryptic comment: TQt: gdb: -nograb added to command-line options. Use the -dograb option to enforce grabbing. However, the "-dograb" option isn't recognised by either gdb or ksmserver, so quite how I'm supposed to use it is a mystery to me. I'm thinking this now at the point where I ought to be putting this into bugzilla unless their are any further thoughts here. Thanks again, Tim W -- Tim Williams BSc MSc MBCS AutoTrain 58 Jacoby Place Priory Road Edgbaston Birmingham B5 7UW United Kingdom Web : http://www.autotrain.org, http://www.utrain.info Tel : +44 (0)844 487 4117 AutoTrain is a trading name of EuroMotor-AutoTrain LLP Registered in the United Kingdom, number: OC317070.