deloptes composed on 2017-08-06 19:18 (UTC+0200):

I have never heard of Mageia

I'll bet you had (before today):

https://wiki.trinitydesktop.org/MageiaInstall and its addition to https://wiki.trinitydesktop.org/Category:Documentationdate back more than 3 years.

1998 - Mandrake forked off RedHat 5.1, featuring KDE instead of Gnome: https://web.archive.org/web/20040404122826/http://www.distrowatch.com:80/table.php?distribution=mandrake

(2004 - first Ubuntu release)

2005 - Conectiva Linux was merged into Mandrake and the name was changed to Mandriva. The Mandrake line makes up most of Mandriva's Distrowatch history, going all the way back to 1998: https://web.archive.org/web/20130925163717/http://distrowatch.com/table.php?distribution=mandriva

2010 - Mageia forked from Mandriva: http://distrowatch.com/table.php?distribution=mageia

On 08/07/2017 07:54 AM, deloptes wrote:

Felix Miata wrote:

...

I'll bet you had (before today):

may be not because I don't use RH or alike

It doesn't matter, soon, we'll all be one with systemD :P

Tim Williams composed on 2017-08-06 20:57 (UTC+0100):

Felix Miata wrote:

...

...

The mga6 Xorg server version has the modesetting driver incorporated, moved from being a separate driver package as of 1.17.x. Eradicating NVidia and x11-driver-video-nouveau (and remembering to get nomodeset off the kernel cmdline) to let it be used might be worth trying.

There's no sign of nomodeset in the boot parameters.

Maybe latest NVidia drivers have been updated to utilize KMS and I just haven't heard about it yet? AFAIK, NVidia's Xorg drivers require KMS be disabled.

I'll see if any clues turn up, although I'm tempted to try the spare HD first.

For reference, running ksmserver with gdb gives the following, which may or may not be relevant:

Program received signal SIGSEGV, Segmentation fault. 0x00007ffff4c196a0 in TQString::TQString(TQString const&) () from /lib64/libtqt-mt.so.3

On a 32bit mga6 installation on host gx27b with rv200 Radeon gfx (very old) and 14.0.4 from mga5 sources, last updated 19 June, during urpmi --autoselect I got this: ... 4/36 removing trinity-ksmserver-14.04-1.mga5 ################ Usage: chksession [OPTION] -F --first:... -t, --test:... -l, --list: List window managers -L: List window managers including the order number -d=DIR, --dir=DIR: Specifies a directory of w-m configuration files -x=ENTRY, --xsession=ENTRY: Produce windows-managers script of ENTRY. -h, --help:...

warning: %postun(trinity-ksmserver-14.0.4-1.mga5) scriptlet failed exit status 1 ERROR: 'script' failed for trinity-ksmserver-14.0.4-1.mga5 5/36: removing trinity-ksysguard...

Trying to run TDE session via startx in multi-user.target Xorg starts, but immediately exits with:

Closing log file.: line1: TDE: command not \ foundxinit: connection to X server lost.

xinit and xinitrc are installed.

Booted to graphical.target I can login in TDM (with UseTheme=no configured) and get a working TDE session.

So I have now tried the following:

- Clean installation of Mageia 6 X86_64 on a spare HD (with the normal drive removed). XFCE desktop selected as the default. - Proprietary Nvidia driver to be installed during setup. - Installed X86_64 Trinity packages using urpmi and all Mageia 6 updates. - Reboot. - Login to Trinity. This crashed as before. - Change to framebuffer driver, reboot. Login to trinity, again the same crash. - Removed 'nokmsboot' from the boot parameters. Rebooted. Trinity crashed on login. - Wipe HD, reinstall again, saying no when proprietary driver is offered, nouveau driver installed. - Install trinity. Once again, it crashed on login.

This seems to eliminate the possibility of the Nvidia driver or my NFS home directories causing the crash and leaves me with the conclusion that this is architecture related.

I'm tempted to see if the i586 packages do any better in the interests of experimentation.

Any thoughts, much appreciated.

Tim W

On 07/08/17 22:45, Felix Miata wrote:

Tim Williams composed on 2017-08-07 15:52 (UTC-0400):

Crashed, crashed, crashed. Exactly the same TQString::TQString(TQString const&) as from your 2017-08-06 20:57 (UTC+0100) thread post every time? Are there no logged clues in journalctl, dmesg, .xsession-errors, Xorg.0.log or elsewhere?

The error that shows on the login is from ksmserver, I haven't tried to run it with gdb again to see if the TQTString error shows up, but it's a fair bet it's the same.

The PC I mentioned 2017-08-06 18:58 -0400 is i586. TDM works to login and get a TDE session working, but if I try without TDM running via startx, startx gets Xorg running, but it immediately terminates.

Good to know, my 2 other computers are both running X86_64 and TDE is working perfectly on both, so this has got to be pretty hardware specific, but is a bit of a mystery. The software set up on my laptop is very similar.

Since I had the case open, I also tried pulling out my soundcard and video capture card, just in case there was some kind of hardware scan that was crashing things.

Which *tqt* packages are installed? Does anything among http://bugs.pearsoncomputing.net/buglist.cgi?chfieldfrom=22m&chfieldto=Now&f1=component&f2=component&f3=component&list_id=5218&o1=notequals&o2=notequals&o3=notequals&product=TDE&query_format=advanced&short_desc=tqt&short_desc_type=allwordssubstr&v1=fedora&v2=debian&v3=ubuntu look related?

None of them stands out.

If you log onto IRC irc://freenode/trinity-desktop maybe SlavekB could help more than mere users here? trinity-devel list likewise at this point seems likely better suited to actually solving your problem. Indicate exactly which NVidia device you have. Better help may result from keeping the NVidia driver uninstalled until the problem is resolved.

Thanks, I'll keep that as an emergency backup, IRC isn't really my thing.

Another thought, since you're apparently not averse to reinstalling on a separate HD: try a different TDE supported RPM distro, PCLinuxOS, CentOS, openSUSE or Fedora. If no crash there, probably not a(n unsolvable) hardware issue.

I might give CentOS 7 a go, I think I have an install image somewhere.

Thanks again.

Tim W

Work and other commitments have prevented me from following this up for the past month, but I still have this problem, I've been making do with XFCE for the past month.

To re-cap, I have 3 PC's (Desktop, Laptop and Media Centre) running Mageia Linux and Trinity. All three were upgraded from Mageia 5 to 6 in August. All 3 ran Trinity perfectly on Mageia 5. After the upgrade to 6, Trinity continues to run perfectly on my Laptop and Media Centre, but now crashes on login running on my desktop. The KSMserver crashes, but the desktop drops back to the login screen before I can get the full debug message out of it.

At the time of my last post, I'd done the following tests:

- Clean install of Magiea 6, using Nvidia driver, crashes. - Clean install of Magiea 6, using Nouveau driver, crashes. - Clean install of Magiea 6, using framebuffer driver, crashes.

If I login using XFCE and try to run starttde, then I get same behaviour and again, the crash handler vanishes before I can get at anything useful. I see the following at the command prompt:

[starttde] Starting starttde. [starttde] This script is /opt/trinity/bin/starttde [starttde] TDE version is R14.0.4 [starttde] TDE base directory is /opt/trinity [starttde] TDEHOME is not set. [starttde] Set TDEHOME to /home/timw/.trinity. [starttde] Setting TDEROOTHOME to /root/.trinity. [starttde] XDG_DATA_DIRS: /opt/trinity/share:/usr/local/share:/usr/share Start gpg-agent gpg-agent[18838]: /home/timw/.gnupg/gpg-agent.conf:4: obsolete option "use-standard-socket" - it has no effect gpg-agent: a gpg-agent is already running - not starting a new one End start gpg-agent [starttde] TDEDIR: /opt/trinity [starttde] TDEDIRS: [starttde] Starting Trinity... [starttde] Trinity hardware control dbus daemon running. [tdebuildsycoca] tdebuildsycoca running... [dcopserver] DCOP Cleaning up dead connections. [starttde] TDE_FULL_SESSION: true [starttde] TDE_SESSION_UID: 500 [tdeinit] Shutting down running client. --------------------------------- [dcopserver] It looks like dcopserver is already running. If you are sure that it is not already running, remove /home/timw/.DCOPserver_baa.sheep__0 and start dcopserver again. --------------------------------- [kded] Daemon (kded) is already running. [tdebuildsycoca] tdebuildsycoca running... [tdebuildsycoca] Reusing existing tdesycoca. tdeio (KService*): WARNING: Invalid Service : khtmlimage.desktop [dcopserver] DCOP Cleaning up dead connections. [starttde] tdeinit started successfully. [kcrash] TDECrash: Application 'ksmserver' crashing... [starttde] Shutting down Trinity... [tdelauncher] Exiting on signal 1 [starttde] Running Trinity shutdown scripts... [starttde] Running /home/timw/.trinity/shutdown/stop-gpg-agent.sh. Stop ssh-agent unset SSH_AUTH_SOCK; unset SSH_AGENT_PID; echo Agent pid 18843 killed; Finish stop ssh-agent [starttde] Trinity shutdown complete.

For reference, running ksmserver with gdb (having logged in with XFCE) gives the following, which may or may not be relevant:

Program received signal SIGSEGV, Segmentation fault. 0x00007ffff4c196a0 in TQString::TQString(TQString const&) () from /lib64/libtqt-mt.so.3

Since my last post, I have also done the following:

- a clean install of Fedorea 26, using Nvidia driver, Trinity runs OK on this set up - Unpluging all my add on cards and USB devices (except essentials), to no avail. - Recompiled the relevant rpm which contains the ksmserver just in case there was an issue on the build host.

Also, most Trinity programmes run just fine when started under XFCE.

So I'm now at a real loss to understand why Trinity crashes on one of my computers using one particular distro version and is OK in all other circumstances. My assumption is that it might be a combination of a library issue and the fact that it's the only one of my PC's with an AMD chip. However I'm now at a bit of an impasse if this can't be fixed soon, since it means that either I need to change distros (with no certainty that the offending library bug won't get incorporated into the next Fedora release) or switch to a new desktop.

Is there anyway I can get a more meaningful error message out of this? I am a software engineer by profession, but C/C++ isn't one of my many languages so I only have a basic understanding of it. However, I'd settle for a simple bodge which allows ksmserver to get past whatever is causing the crash so that the desktop starts up, even if there are some knock on effects (as long as they aren't too severe).

All help much appreciated!

Tim W

On Friday 08 September 2017 03:13:07 wofgdkncxojef@gmail.com wrote:

On Thursday 07 September 2017 21:09:00 Tim Williams wrote:

...

Work and other commitments have prevented me from following this up for the past month, but I still have this problem, I've been making do with XFCE for the past month.

To re-cap, I have 3 PC's (Desktop, Laptop and Media Centre) running Mageia Linux and Trinity. All three were upgraded from Mageia 5 to 6 in August. All 3 ran Trinity perfectly on Mageia 5. After the upgrade to 6, Trinity continues to run perfectly on my Laptop and Media Centre, but now crashes on login running on my desktop. The KSMserver crashes, but the desktop drops back to the login screen before I can get the full debug message out of it.

At the time of my last post, I'd done the following tests:

• Clean install of Magiea 6, using Nvidia driver, crashes.
• Clean install of Magiea 6, using Nouveau driver, crashes.
• Clean install of Magiea 6, using framebuffer driver, crashes.

If I login using XFCE and try to run starttde, then I get same behaviour and again, the crash handler vanishes before I can get at anything useful. I see the following at the command prompt:

[starttde] Starting starttde. [starttde] This script is /opt/trinity/bin/starttde [starttde] TDE version is R14.0.4 [starttde] TDE base directory is /opt/trinity [starttde] TDEHOME is not set. [starttde] Set TDEHOME to /home/timw/.trinity. [starttde] Setting TDEROOTHOME to /root/.trinity. [starttde] XDG_DATA_DIRS: /opt/trinity/share:/usr/local/share:/usr/share Start gpg-agent gpg-agent[18838]: /home/timw/.gnupg/gpg-agent.conf:4: obsolete option "use-standard-socket" - it has no effect gpg-agent: a gpg-agent is already running - not starting a new one End start gpg-agent [starttde] TDEDIR: /opt/trinity [starttde] TDEDIRS: [starttde] Starting Trinity... [starttde] Trinity hardware control dbus daemon running. [tdebuildsycoca] tdebuildsycoca running... [dcopserver] DCOP Cleaning up dead connections. [starttde] TDE_FULL_SESSION: true [starttde] TDE_SESSION_UID: 500 [tdeinit] Shutting down running client.

---

[dcopserver] It looks like dcopserver is already running. If you are sure that it is not already running, remove /home/timw/.DCOPserver_baa.sheep__0 and start dcopserver again.

---

[kded] Daemon (kded) is already running. [tdebuildsycoca] tdebuildsycoca running... [tdebuildsycoca] Reusing existing tdesycoca. tdeio (KService*): WARNING: Invalid Service : khtmlimage.desktop [dcopserver] DCOP Cleaning up dead connections. [starttde] tdeinit started successfully. [kcrash] TDECrash: Application 'ksmserver' crashing... [starttde] Shutting down Trinity... [tdelauncher] Exiting on signal 1 [starttde] Running Trinity shutdown scripts... [starttde] Running /home/timw/.trinity/shutdown/stop-gpg-agent.sh. Stop ssh-agent unset SSH_AUTH_SOCK; unset SSH_AGENT_PID; echo Agent pid 18843 killed; Finish stop ssh-agent [starttde] Trinity shutdown complete.

For reference, running ksmserver with gdb (having logged in with XFCE) gives the following, which may or may not be relevant:

Program received signal SIGSEGV, Segmentation fault. 0x00007ffff4c196a0 in TQString::TQString(TQString const&) () from /lib64/libtqt-mt.so.3

Since my last post, I have also done the following:

• a clean install of Fedorea 26, using Nvidia driver, Trinity runs OK on

this set up

• Unpluging all my add on cards and USB devices (except essentials), to

no avail.

• Recompiled the relevant rpm which contains the ksmserver just in case

there was an issue on the build host.

Also, most Trinity programmes run just fine when started under XFCE.

So I'm now at a real loss to understand why Trinity crashes on one of my computers using one particular distro version and is OK in all other circumstances. My assumption is that it might be a combination of a library issue and the fact that it's the only one of my PC's with an AMD chip. However I'm now at a bit of an impasse if this can't be fixed soon, since it means that either I need to change distros (with no certainty that the offending library bug won't get incorporated into the next Fedora release) or switch to a new desktop.

Is there anyway I can get a more meaningful error message out of this? I am a software engineer by profession, but C/C++ isn't one of my many languages so I only have a basic understanding of it. However, I'd settle for a simple bodge which allows ksmserver to get past whatever is causing the crash so that the desktop starts up, even if there are some knock on effects (as long as they aren't too severe).

All help much appreciated!

Tim W

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....

also, in the mean time, you can neutralize that "while" with a "true", and manually, put above it the stuff that don't launch, for example: kdesktop # the desktop kicker # the panel twin # the window manager i think you can live without ksmserver.....

On Monday 11 September 2017 12:40:05 Tim Williams wrote:

On 08/09/17 02:13, wofgdkncxojef@gmail.com 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.cpp:10 7 #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

yea, all that stuff are a bit over my head...

ksmserver is the session manager. With out it, you can't restore automatically previous sessions, or save a session manually, no autostart and starts some other stuff. More or less. Other things?

The easiest, would be to have starttde point at a script in your home that you can easily edit. It's possible that some stuff are missing, like some deamon. You'll have to add those too.

you can deactivate the splash screen, or do something like this? sleep 3 killall ksplash

It's not ideal, but it's still very usable....

On Monday 11 of September 2017 12:40:05 Tim Williams wrote:

On 08/09/17 02:13, wofgdkncxojef@gmail.com 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

On Tuesday 12 of September 2017 19:18:03 Tim Williams wrote:

On 11/09/17 22:18, Slávek Banko wrote:

...

Tim, thank you for a very good backtrace! Once I find free time, I'll look at this problem...

Thanks.

It looks like there is a second variation of this crash. kded crashes when using konqueror to open system:/media . The trace is below, however, drkonqi suffers from the same fault as before, it closes the instant the backtrace is complete, so this is what I could get!

Tim W

[Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". 0x00007fe0e1f7d7f0 in __nanosleep_nocancel () at ../sysdeps/unix/syscall-template.S:84 84 T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS)

==== (gdb) bt ==== #0 0x00007fe0e1f7d7f0 in __nanosleep_nocancel () at ../sysdeps/unix/syscall-template.S:84 #1 0x00007fe0e1f7d6ac in __sleep (seconds=0, seconds@entry=1) at ../sysdeps/unix/sysv/linux/sleep.c:138 #2 0x00007fe0e036ef5a in TDECrash::startDrKonqi (argv=argv@entry=0x7fffd646c770, argc=argc@entry=17) at /usr/src/debug/trinity-tdelibs-14.0.4/tdecore/kcrash.cpp:312 #3 0x00007fe0e036f3a9 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=0x7fffd646ce28, s=...) at tools/qstring.cpp:1516 #6 0x00007fe0e043c7bf 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 0x00007fe0e041db2f in TDEHardwareDevices::processModifiedCPUs (this=this@entry=0x1736bf0) at /usr/src/debug/trinity-tdelibs-14.0.4/tdecore/tdehw/tdehardwaredevices. cpp:863 #9 0x00007fe0e0429c12 in TDEHardwareDevices::addCoreSystemDevices (this=this@entry=0x1736bf0) at /usr/src/debug/trinity-tdelibs-14.0.4/tdecore/tdehw/tdehardwaredevices. cpp:3601 #10 0x00007fe0e043077a in TDEHardwareDevices::queryHardwareInformation (this=this@entry=0x1736bf0) at /usr/src/debug/trinity-tdelibs-14.0.4/tdecore/tdehw/tdehardwaredevices. cpp:3457 #11 0x00007fe0e0430e3e in TDEHardwareDevices::TDEHardwareDevices (this=0x1736bf0) at /usr/src/debug/trinity-tdelibs-14.0.4/tdecore/tdehw/tdehardwaredevices. cpp:217 #12 0x00007fe0e038137e in TDEInstance::hardwareDevices (this=0x161e740) at /usr/src/debug/trinity-tdelibs-14.0.4/tdecore/kinstance.cpp:290 #13 0x00007fe0d7682dd3 in TDEBackend::TDEBackend(MediaList&, TQObject*) () from /opt/trinity/lib64/trinity/kded_mediamanager.so #14 0x00007fe0d7667445 in MediaManager::loadBackends() () from /opt/trinity/lib64/trinity/kded_mediamanager.so #15 0x00007fe0d766831c in MediaManager::tqt_invoke(int, TQUObject*) () from /opt/trinity/lib64/trinity/kded_mediamanager.so #16 0x00007fe0df4c4b39 in TQObject::activate_signal (this=this@entry=0x1625ca0, clist=clist@entry=0x16ec810, o=o@entry=0x7fffd646dab0) at kernel/qobject.cpp:2813 #17 0x00007fe0df73ef01 in TQSignal::signal (this=this@entry=0x1625ca0, t0=...) at .moc/debug-shared-mt/moc_ntqsignal.cpp:110 #18 0x00007fe0df4d8720 in TQSignal::activate (this=this@entry=0x1625ca0) at kernel/qsignal.cpp:215 #19 0x00007fe0df4e2f50 in TQSingleShotTimer::event (this=0x1625c50) at kernel/qtimer.cpp:289 #20 0x00007fe0df47763f in TQApplication::internalNotify (this=<optimized out>, receiver=0x1625c50, e=0x7fffd646dd20) at kernel/qapplication.cpp:2883 #21 0x00007fe0df477b28 in TQApplication::notify (this=<optimized out>, receiver=receiver@entry=0x1625c50, e=e@entry=0x7fffd646dd20, this=<optimized out>, this=<optimized out>, this=<optimized out>, this=<optimized out>) at kernel/qapplication.cpp:2726 #22 0x00007fe0e02f09e8 in TDEApplication::notify (this=0x7fffd646e210, receiver=0x1625c50, event=0x7fffd646dd20) at /usr/src/debug/trinity-tdelibs-14.0.4/tdecore/tdeapplication.cpp:660 #23 0x00007fe0df46efdd in TQEventLoop::activateTimers (this=this@entry=0x1698060) at kernel/qeventloop_unix_glib.cpp:694 #24 0x00007fe0df45ca15 in TQEventLoop::gsourceDispatch (this=this@entry=0x1698060, gs=gs@entry=0x169dac0) at kernel/qeventloop_x11_glib.cpp:595 #25 0x00007fe0df45cac3 in qt_gsource_dispatch (source=0x169dac0, callback=<optimized out>, user_data=<optimized out>) at kernel/qeventloop_x11_glib.cpp:123 #26 0x00007fe0dab79ac7 in g_main_dispatch (context=0x169da00) at gmain.c:3230 #27 g_main_context_dispatch (context=context@entry=0x169da00) at gmain.c:3895 #28 0x00007fe0dab79cf8 in g_main_context_iterate (context=context@entry=0x169da00, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3968 #29 0x00007fe0dab79d9c in g_main_context_iteration (context=0x169da00, may_block=1) at gmain.c:4029 #30 0x00007fe0df45bf5b in TQEventLoop::processEvents (this=0x1698060, flags=<optimized out>) at kernel/qeventloop_x11_glib.cpp:279 #31 0x00007fe0df4895d1 in TQEventLoop::enterLoop (this=0x1698060) at kernel/qeventloop.cpp:227 #32 0x00007fe0df489569 in TQEventLoop::exec (this=0x1698060) at kernel/qeventloop.cpp:174 #33 0x00007fe0e228614c in kdemain (argc=<optimized out>, argv=<optimized out>) at /usr/src/debug/trinity-tdelibs-14.0.4/kded/kded.cpp:982 #34 0x00007fe0e1ee0600 in __libc_start_main (main=0x4006e0 <main(int, char**)>, argc=1, argv=0x7fffd646e548, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffd646e538) at libc-start.c:289 #35 0x0000000000400719 in _start () at ../sysdeps/x86_64/start.S:118

==== (gdb) bt full ==== #0 0x00007fe0e1f7d7f0 in __nanosleep_nocancel () at ../sysdeps/unix/syscall-template.S:84 No locals. #1 0x00007fe0e1f7d6ac in __sleep (seconds=0, seconds@entry=1) at ../sysdeps/unix/sysv/linux/sleep.c:138 ts = {tv_sec = 0, tv_nsec = 557007612} set = {__val = {65536, 0 <repeats 15 times>}} oset = {__val = {1024, 0, 3689624817846452224, 140603815506392, 140736788342384, 16, 3, 168, 0, 140603815516056, 140736788342384, 140736788350968, 3, 168, 0, 140603845929116}} result = <optimized out> #2 0x00007fe0e036ef5a in TDECrash::startDrKonqi (argv=argv@entry=0x7fffd646c770, argc=argc@entry=17) at /usr/src/debug/trinity-tdelibs-14.0.4/tdecore/kcrash.cpp:312 header = {cmd = 4, arg_length = 8} BUFSIZE = 8192 buffer = "\320K\000\000\000\000\000\000drkonqi\000-display\000:0\000--appname\00 0kded\000--signal\000\061\061\000--pid\000\061\071\063\067\060\000--appv ersion\000$Id$\000--programname\000TDE Daemon\000--bugaddress\000http://bugs.trinitydesktop.org%5C000--startupid \000\060", '\000' <repeats 18 times>, "\020\000\000\000\000\000\000\b\000\000\000\000\000\000\000"... pos = <optimized out> argcl = 17 env = 0 avoid_loops = 0 pid = 19408 #3 0x00007fe0e036f3a9 in TDECrash::defaultCrashHandler (sig=<optimized out>) at /usr/src/debug/trinity-tdelibs-14.0.4/tdecore/kcrash.cpp:229 argv = {0x7fe0e04d0994 "drkonqi", 0x7fe0e04c87e9 "-display", 0x162fa00 ":0", 0x7fe0e04d09b4 "--appname", 0x169d340 "kded", 0x7fe0e04d09d2 "--signal", 0x7fffd646c834 "11", 0x7fe0e04d09db "--pid", 0x7fffd646c83e "19370", 0x7fe0e04d09e1 "--appversion", 0x7fe0e228a72a "$Id$", 0x7fe0e04d09ee "--programname", 0x169bce0 "TDE Daemon", 0x7fe0e04d09fc "--bugaddress", 0x7fe0e04d2e70 "http://bugs.trinitydesktop.org", 0x7fe0e04d0a09 "--startupid", 0x169d6b0 "0", 0x0, 0x10 <error: Cannot access memory at address 0x10>, 0x7fe0e226db40 <main_arena> "", 0x7fe0e226db40 <main_arena> "", 0x1000 <error: Cannot access memory at address 0x1000>, 0x2000 <error: Cannot access memory at address 0x2000>, 0x4010 <error: Cannot access memory at address 0x4010>} i = 17 about = <optimized out> sigtxt = "11\000\000'\313\363\341\340\177" pidtxt = "19370\000\000\000\000" instance = <optimized out> crashRecursionCounter = 2 rlp = {rlim_cur = 1024, rlim_max = 4096} #4 <signal handler called> No locals. #5 TQString::TQString (this=0x7fffd646ce28, s=...) at tools/qstring.cpp:1516 No locals. #6 0x00007fe0e043c7bf in operator+ (s2=..., s1=...) at /usr/include/tqt3/ntqstring.h:1016 No locals. #7 TDEGenericDevice::uniqueID (this=this@entry=0x0) at /usr/src/debug/trinity-tdelibs-14.0.4/tdecore/tdehw/tdegenericdevice.cp p:107 No locals. #8 0x00007fe0e041db2f in TDEHardwareDevices::processModifiedCPUs (this=this@entry=0x1736bf0) at /usr/src/debug/trinity-tdelibs-14.0.4/tdecore/tdehw/tdehardwaredevices. cpp:863 hwdevice = 0x0 cpufile = {<TQIODevice> = {_vptr.TQIODevice = 0x7fe0dfb34608 <vtable for TQFile+16>, ioIndex = 0, ioMode = 256, ioSt = 0}, fn = {static null = {static null = <same as static member of an already seen type>, d = 0x160eb60, static shared_null = 0x160eb60}, d = 0x173cb50, static shared_null = 0x160eb60}, fh = 0x0, fd = 0, length = 0, ext_f = false, d = 0x173cc40, ungetchBuffer = {<TQMemArray<char>> = {<TQGArray> = {_vptr.TQGArray = 0x7fe0dfb34458 <vtable for TQCString+16>, shd = 0x173cbf0}, <No data fields>}, <No data fields>}} cpuinfo_format_x86 = <optimized out> cpuinfo_format_arm = <optimized out> curline1 = {static null = {static null = <same as static member of an already seen type>, d = 0x160eb60, static shared_null = 0x160eb60}, d = 0x160eb60, static shared_null = 0x160eb60} curline2 = {static null = {static null = <same as static member of an already seen type>, d = 0x160eb60, static shared_null = 0x160eb60}, d = 0x160eb60, static shared_null = 0x160eb60} blockNumber = <optimized out> blockBegin = <optimized out> cdevice = 0x1744fe0 modified = true have_frequency = true curline = {static null = {static null = <same as static member of an already seen type>, d = 0x160eb60, static shared_null = 0x160eb60}, d = 0x160eb60, static shared_null = 0x160eb60} processorNumber = 1 processorCount = 8 firstCPU = 0x1744340 #9 0x00007fe0e0429c12 in TDEHardwareDevices::addCoreSystemDevices (this=this@entry=0x1736bf0) at /usr/src/debug/trinity-tdelibs-14.0.4/tdecore/tdehw/tdehardwaredevices. cpp:3601 hwdevice = <optimized out> holdingDeviceNodes = {<TQValueList<TQString>> = {sh = 0x173e0b0}, <No data fields>} devicesnodename = {static null = {static null = <same as static member of an already seen type>, d = 0x160eb60, static shared_null = 0x160eb60}, d = 0x173e2f0, static shared_null = 0x160eb60} devicesdir = {_vptr.TQDir = 0x7fe0dfb344d0 <vtable for TQDir+16>, dPath = {static null = {static null = <same as static member of an already seen type>, d = 0x160eb60, static shared_null = 0x160eb60}, d = 0x173e650, static shared_null = 0x160eb60}, fList = 0x1747890, fiList = 0x173e320, nameFilt = {static null = {static null = <same as static member of an already seen type>, d = 0x160eb60, static shared_null = 0x160eb60}, d = 0x173e130, static shared_null = 0x160eb60}, filtS = TQDir::All, sortS = TQDir::IgnoreCase, dirty = 0, allDirs = 0} nodename = {static null = {static null = <same as static member of an already seen type>, d = 0x160eb60, static shared_null = 0x160eb60}, d = 0x173e2c0, static shared_null = 0x160eb60} dirlist = <optimized out> d = {_vptr.TQDir = 0x7fe0dfb344d0 <vtable for TQDir+16>, dPath = {static null = {static null = <same as static member of an already seen type>, d = 0x160eb60, static shared_null = 0x160eb60}, d = 0x1742ac0, static shared_null = 0x160eb60}, fList = 0x17429d0, fiList = 0x171c640, nameFilt = {static null = {static null = <same as static member of an already seen type>, d = 0x160eb60, static shared_null = 0x160eb60}, d = 0x1746ab0, static shared_null = 0x160eb60}, filtS = TQDir::Dirs, sortS = TQDir::IgnoreCase, dirty = 0, allDirs = 0} list = <optimized out> #10 0x00007fe0e043077a in TDEHardwareDevices::queryHardwareInformation (this=this@entry=0x1736bf0) at /usr/src/debug/trinity-tdelibs-14.0.4/tdecore/tdehw/tdehardwaredevices. cpp:3457 enumerate = <optimized out> devices = <optimized out> dev_list_entry = <optimized out> dev = <optimized out> #11 0x00007fe0e0430e3e in TDEHardwareDevices::TDEHardwareDevices (this=0x1736bf0) at /usr/src/debug/trinity-tdelibs-14.0.4/tdecore/tdehw/tdehardwaredevices. cpp:217 udevmonitorfd = <optimized out> file = {<TQIODevice> = {_vptr.TQIODevice = 0x7fe0dfb34608 <vtable for TQFile+16>, ioIndex = 0, ioMode = 256, ioSt = 0}, fn = {static null = {static null = <same as static member of an already seen type>, d = 0x160eb60, static shared_null = 0x160eb60}, d = 0x17216d0, static shared_null = 0x160eb60}, fh = 0x0, fd = 0, length = 0, ext_f = false, d = 0x1737ce0, ungetchBuffer = {<TQMemArray<char>> = {<TQGArray> = {_vptr.TQGArray = 0x7fe0dfb34458 <vtable for TQCString+16>, shd = 0x17377b0}, <No data fields>}, <No data fields>}} cpufile = {<TQIODevice> = {_vptr.TQIODevice = 0x7fe0dfb34608 <vtable for TQFile+16>, ioIndex = 0, ioMode = 256, ioSt = 0}, fn = {static null = {static null = <same as static member of an already seen type>, d = 0x160eb60, static shared_null = 0x160eb60}, d = 0x16bd100, static shared_null = 0x160eb60}, fh = 0x0, fd = 0, length = 0, ext_f = false, d = 0x1739a50, ungetchBuffer = {<TQMemArray<char>> = {<TQGArray> = {_vptr.TQGArray = 0x7fe0dfb34458 <vtable for TQCString+16>, shd = 0x1739a30}, <No data fields>}, <No data fields>}} #12 0x00007fe0e038137e in TDEInstance::hardwareDevices (this=0x161e740) at /usr/src/debug/trinity-tdelibs-14.0.4/tdecore/kinstance.cpp:290 No locals. #13 0x00007fe0d7682dd3 in TDEBackend::TDEBackend(MediaList&, TQObject*) () from /opt/trinity/lib64/trinity/kded_mediamanager.so No symbol table info available. #14 0x00007fe0d7667445 in MediaManager::loadBackends() () from /opt/trinity/lib64/trinity/kded_mediamanager.so No symbol table info available. #15 0x00007fe0d766831c in MediaManager::tqt_invoke(int, TQUObject*) () from /opt/trinity/lib64/trinity/kded_mediamanager.so

These crashes should be resolved in commit 051acc7d (master) and 7d83a0cb (r14.0.x branch). Thank you for your report of the problem!

By the way, what do you have the kernel - are files in sysfs folder /sys/devices/system/cpu/cpu available to a regular user?

Cheers