On Monday 11 of September 2017 12:40:05 Tim Williams wrote: > On 08/09/17 02:13, wofgdkncxojef@... wrote: > > in /opt/trinity/bin/starttde > > at line 787, put a large number. > > when it crashes, you'll see what it does > > and what drkonqi has to say about it. > > Maybe it even works properly.... > > 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.cp >p: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, thank you for a very good backtrace! Once I find free time, I'll look at this problem... Cheers -- Sl�vek