Message: previous - next
Month: September 2017

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

From: Slávek Banko <slavek.banko@...>
Date: Mon, 11 Sep 2017 23:18:51 +0200
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/".
> 0x00007fd6177fd7f0 in __nanosleep_nocancel () at
> ../sysdeps/unix/syscall-template.S:84
> ==== (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...