6 Aug
2017
6 Aug
'17
4:11 p.m.
Hi all,
I'm having a trouble getting Trinity working on Mageia 6. I've installed
via the official URPMI repositories, using the trinity-desktop package
to ensure all dependencies are present.
Note, I've got Trinity running OK on my laptop with Mageia 6, but on my
desktop system it's badly broken for reasons I can't trace. My desktop
uses an NFS mounted home directory and and is a dual-monitor system.
If I use TDM as the login manager, the I get dropped out of X back to
the terminal, TDM seems to be unable to start at all. I've switched to
LightDM, which fixed this but TDE isn't listed as an available desktop
in the relevant menu. Fixing this required a symbolic link from
/opt/trinity/share/apps/tdm/sessions/tde.desktop to /usr/share/xsessions.
If I login the initial splash screen appears, but I then get a crash
message which closes before I can read the details, I then get dumped
back at the login manager. 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.
Note, I'm not sure why this is complaining about
/home/timw/.DCOPserver_baa.sheep__0, I've checked prior to start up and
this dir does not exist, nor is it left behind after the crash.
I've tried using a clean user account and also running this as root, but
there is no difference, the start up just crashes.
I've audited my system and have removed all the left behind Mageia 5
packages, so the installation is clean as far as I can tell. TDE
programmes such as konqueror, kate etc start up OK running on XFCE.
Any help much appreciated, I'm somewhat lost without my Trinity desktop
and this is my primary work computer.
Thanks in advance,
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.
6 Aug
6 Aug
5:18 p.m.
Tim Williams wrote:
I'm having a trouble getting Trinity working on
Mageia 6. I've installed
via the official URPMI repositories, using the trinity-desktop package
to ensure all dependencies are present.
I have never heard of Mageia - was it working in the older 5 version?
if it is based on RH (as you mentioned URPMI) perhaps some of the people
using such systems may help.
In my opinion it could be anything that causes your trouble. Most of all the
TDE team provides integration into couple of distributions. Using not such
a distribution very likely leads to such situations.
You could try providing such integration for Mageia.
From what you are describing it looks like the installation of the packages
did not work well - but I don't know how URPMI works.
Let us know which repo and TDE version you used.
regards
6:21 p.m.
New subject: [trinity-users] Mageia 6 crash on login, can't start desktop
On 08/06/2017 06:11 PM, Tim Williams wrote:
Hi all,
I'm having a trouble getting Trinity working on Mageia 6. I've installed
via the official URPMI repositories, using the trinity-desktop package
to ensure all dependencies are present.
Note, I've got Trinity running OK on my laptop with Mageia 6, but on my
desktop system it's badly broken for reasons I can't trace. My desktop
uses an NFS mounted home directory and and is a dual-monitor system.
If I use TDM as the login manager, the I get dropped out of X back to
the terminal, TDM seems to be unable to start at all. I've switched to
LightDM, which fixed this but TDE isn't listed as an available desktop
in the relevant menu. Fixing this required a symbolic link from
/opt/trinity/share/apps/tdm/sessions/tde.desktop to /usr/share/xsessions.
If I login the initial splash screen appears, but I then get a crash
message which closes before I can read the details, I then get dumped
back at the login manager. 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.
Note, I'm not sure why this is complaining about
/home/timw/.DCOPserver_baa.sheep__0, I've checked prior to start up and
this dir does not exist, nor is it left behind after the crash.
I've tried using a clean user account and also running this as root, but
there is no difference, the start up just crashes.
I've audited my system and have removed all the left behind Mageia 5
packages, so the installation is clean as far as I can tell. TDE
programmes such as konqueror, kate etc start up OK running on XFCE.
Any help much appreciated, I'm somewhat lost without my Trinity desktop
and this is my primary work computer.
Thanks in advance,
Tim W
make an other user, change tty and log in as that user.
you can use "starttde" from there (this is for convenience)
try editing "/opt/trinity/bin/starttde" so that it launches
or narrow down the problem....
6:29 p.m.
New subject: [trinity-users] Mageia 6 crash on login, can't start desktop
On 06/08/17 19:21, wofgdkncxojef wrote:
make an other user, change tty and log in as that user.
you can use "starttde" from there (this is for convenience)
try editing "/opt/trinity/bin/starttde" so that it launches
or narrow down the problem....
I should have put this in my first post but forgot... I tried logging in
using a clean alternative user account, but the result was the same, a
crash message which vanished almost as soon as it appeared, followed by
a return to the login prompt.
What would I edit in starttde ? There's a lot going on in this file!
For reference, in case it wasn't clear from my first post, the bit that
actually crashes (I think) is ksmserver, if the command output is correct.
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.
6:52 p.m.
New subject: [trinity-users] Mageia 6 crash on login, can't start desktop
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:Documentation>date 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>
--
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata *** http://fm.no-ip.com/
7:14 p.m.
New subject: [trinity-users] Mageia 6 crash on login, can't start desktop
Tim Williams composed on 2017-08-06 17:11 (UTC+0100):
I'm having a trouble getting Trinity working on
Mageia 6. I've installed
via the official URPMI repositories, using the trinity-desktop package
to ensure all dependencies are present....
Installed in what context? Upgrade from 5 to 6, or fresh 6? I saw a lot of
trouble on Mageia dev and user mailing lists in pre-release testing of upgrades.
If upgrade, fresh might turn out to be your expedient solution.
I have 4 TDE on Mageia PCs, but ATM I have no recollection which have upgrades
from 5 to 6 or even have TDE instead of KDE5. What I can say for sure ATM is:
1-I don't have gdm, sddm or lightdm installed on any of them. All have either
TDM or KDM4.
2-None of my PCs have or ever had an NVidia proprietary Linux driver installed.
Maybe a search for NVidia in the Mageia mailing list archives would turn up a clue?
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.
--
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata *** http://fm.no-ip.com/
7:57 p.m.
New subject: [trinity-users] Mageia 6 crash on login, can't start desktop
On 06/08/17 20:14, Felix Miata wrote:
Tim Williams composed on 2017-08-06 17:11 (UTC+0100):
Installed in what context? Upgrade from 5 to 6, or fresh 6? I saw a lot of
trouble on Mageia dev and user mailing lists in pre-release testing of upgrades.
If upgrade, fresh might turn out to be your expedient solution.
In all cases upgraded from 5. I removed Trinity during the upgrade to
make dependency resolution easier and re-installed it later. All the
upgrades were done using the command line method from the installation
instructions. After the upgrade was finished I manually scanned for any
remaining mga5 packages and removed or upgraded as appropriate, so there
shouldn't be any mga5 hangovers on the system in terms of code, although
that doesn't exclude the possibility of an issue with a config file.
If no other suggestions are forthcoming I'll try a clean install on a
spare hard disk with the same hardware, I'll also use this to check it
isn't the NFS mounted home causing an issue.
I have 4 TDE on Mageia PCs, but ATM I have no
recollection which have upgrades
from 5 to 6 or even have TDE instead of KDE5. What I can say for sure ATM is:
1-I don't have gdm, sddm or lightdm installed on any of them. All have either
TDM or KDM4.
I was using TDM on 2 of my 3 systems, I only switched when it crashed!
2-None of my PCs have or ever had an NVidia
proprietary Linux driver installed.
Maybe a search for NVidia in the Mageia mailing list archives would turn up a clue?
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.
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
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.
10:58 p.m.
New subject: [trinity-users] Mageia 6 crash on login, can't start desktop
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.
--
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata *** http://fm.no-ip.com/
2:04 p.m.
New subject: [trinity-users] Re: Mageia 6 crash on login, can't start desktop
On Monday 07 August 2017 04:50:59 wofgdkncxojef wrote:
On 08/07/2017 07:54 AM, deloptes wrote:
The Matrix has been renamed? :)
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
Felix Miata wrote:
It doesn't matter, soon, we'll all be one with systemD :P I'll bet you had (before today):
may be not because I don't use RH or alike
5:34 p.m.
New subject: [trinity-users] Mageia 6 crash on login, can't start desktop
On 06/08/17 23:58, Felix Miata wrote:
working TDE session.
The boot options do include 'nokmsboot', which I suspect achieves the
same result.
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.
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.
7:52 p.m.
New subject: [trinity-users] Mageia 6 crash on login, can't start desktop
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
--
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.
9:45 p.m.
New subject: [trinity-users] Mageia 6 crash on login, can't start desktop
Tim Williams composed on 2017-08-07 15:52 (UTC-0400):
Any thoughts, much appreciated.
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 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.
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?
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.
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.
--
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata *** http://fm.no-ip.com/
10:27 p.m.
New subject: [trinity-users] Mageia 6 crash on login, can't start desktop
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
--
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.
8 Aug
8 Aug
6:34 a.m.
New subject: compiz problems
Hi, i installed trinity on linux mint 18.2 mate
Any one managed to use compiz with trinity?
I think i installed all packages that seamed relevant.
compiz seam to crash when i try to launch it
and i can't run the config application
$ ccsm
Traceback (most recent call last):
File "/usr/bin/ccsm", line 93, in <module>
import compizconfig
ImportError: /opt/trinity/lib/libcompizconfig.so.0: undefined symbol:
_Z14ccsFreeSettingP11_CCSSetting
7 Sep
7 Sep
7:09 p.m.
New subject: [trinity-users] Mageia 6 crash on login, can't start desktop
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
--
Tim Williams BSc MSc MBCS
AutoTrain
58 Jacoby Place
Priory Road
Edgbaston
Birmingham
B5 7UW
United Kingdom
Web : http://www.autotrain.org
Tel : +44 (0)844 487 4117
AutoTrain is a trading name of EuroMotor-AutoTrain LLP
Registered in the United Kingdom, number: OC317070.
8 Sep
8 Sep
1:13 a.m.
New subject: [trinity-users] Mageia 6 crash on login, can't start desktop
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....
9 Sep
9 Sep
6:22 a.m.
New subject: [trinity-users] Mageia 6 crash on login, can't start desktop
On Friday 08 September 2017 03:13:07 wofgdkncxojef(a)gmail.com wrote:
On Thursday 07 September 2017 21:09:00 Tim Williams
wrote:
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.....
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....
11 Sep
11 Sep
10:40 a.m.
New subject: [trinity-users] Mageia 6 crash on login, can't start desktop
On 08/09/17 02:13, wofgdkncxojef(a)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: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.
12:33 p.m.
New subject: [trinity-users] Mageia 6 crash on login, can't start desktop
On Monday 11 September 2017 12:40:05 Tim Williams wrote:
On 08/09/17 02:13, wofgdkncxojef(a)gmail.com wrote:
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....
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 
9:18 p.m.
New subject: [trinity-users] Mageia 6 crash on login, can't start desktop
On Monday 11 of September 2017 12:40:05 Tim Williams wrote:
On 08/09/17 02:13, wofgdkncxojef(a)gmail.com wrote:
Tim, thank you for a very good backtrace! Once I find free time, I'll look
at this problem...
Cheers
--
Slávek
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
10:02 p.m.
New subject: [trinity-users] Mageia 6 crash on login, can't start desktop
On Monday 11 September 2017 14:33:03 wofgdkncxojef(a)gmail.com wrote:
On Monday 11 September 2017 12:40:05 Tim Williams
wrote:
also, comment out line 773
$TDEDIR/bin/tdeinit_phase1
so that you don't see the crash manager every time you boot.
On 08/09/17 02:13, wofgdkncxojef(a)gmail.com
wrote:
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.... 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.cp
p: 863 #9 0x00007fd615889c12 in TDEHardwareDevices::addCoreSystemDevices
(this=this@entry=0x1d35890) at
/usr/src/debug/trinity-tdelibs-14.0.4/tdecore/tdehw/tdehardwaredevices.cp
p: 3601 #10 0x00007fd61589077a in
TDEHardwareDevices::queryHardwareInformation (this=this@entry=0x1d35890)
at
/usr/src/debug/trinity-tdelibs-14.0.4/tdecore/tdehw/tdehardwaredevices.cp
p: 3457 #11 0x00007fd615890e3e in TDEHardwareDevices::TDEHardwareDevices
(this=0x1d35890) at
/usr/src/debug/trinity-tdelibs-14.0.4/tdecore/tdehw/tdehardwaredevices.cp
p: 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
12 Sep
12 Sep
5:18 p.m.
New subject: [trinity-users] Mageia 6 crash on login, can't start desktop
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.cpp: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\000kded\000--signal\000\061\061\000--pid\000\061\071\063\067\060\000--appversion\000$Id$\000--programname\000TDE
Daemon\000--bugaddress\000http://bugs.trinitydesktop.org\000--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.cpp: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
--
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.
24 Sep
24 Sep
11:14 p.m.
New subject: [trinity-users] Mageia 6 crash on login, can't start desktop
On Tuesday 12 of September 2017 19:18:03 Tim Williams wrote:
On 11/09/17 22:18, Slávek Banko wrote:
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
--
Slávek
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\000--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
5 Nov
5 Nov
3:13 p.m.
New subject: [trinity-users] Mageia 6 crash on login, can't start desktop
On 25/09/17 00:14, Slávek Banko wrote:
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
Picking this up again after a hectic month... Thanks for the fixes,
these haven't yet worked there way through to the Mageia packages, but
the crash also seems to be have been solved by one of the most recent
Mageia updates (I think one was a kernel update), which presumably
corrected the underlying problem. After being away for a week for a
conference I ran all the latest updates and after the reboot the login
crash, which still occurred but no longer caused Trinity to exit thanks
to the previously suggested edits to starttde had gone away, so I tried
reverting starttde to the original version and that now works as well.
For reference, this is what I'm currently getting from sysfs, however
that may have been different prior to the kernel update.
[timw@baa ~]$ ll /sys/devices/system/cpu/
total 0
drwxr-xr-x 8 root root 0 Nov 5 14:38 cpu0/
drwxr-xr-x 8 root root 0 Nov 5 14:38 cpu1/
drwxr-xr-x 8 root root 0 Nov 5 14:38 cpu2/
drwxr-xr-x 8 root root 0 Nov 5 14:38 cpu3/
drwxr-xr-x 6 root root 0 Nov 5 14:39 cpufreq/
drwxr-xr-x 2 root root 0 Nov 5 14:41 cpuidle/
drwxr-xr-x 2 root root 0 Nov 5 14:41 hotplug/
-r--r--r-- 1 root root 4096 Nov 5 14:46 isolated
-r--r--r-- 1 root root 4096 Nov 5 14:46 kernel_max
drwxr-xr-x 2 root root 0 Nov 5 14:41 microcode/
-r--r--r-- 1 root root 4096 Nov 5 14:46 modalias
-r--r--r-- 1 root root 4096 Nov 5 14:46 offline
-r--r--r-- 1 root root 4096 Nov 5 14:46 online
-r--r--r-- 1 root root 4096 Nov 5 14:46 possible
drwxr-xr-x 2 root root 0 Nov 5 14:41 power/
-r--r--r-- 1 root root 4096 Nov 5 14:46 present
-rw-r--r-- 1 root root 4096 Nov 5 14:46 uevent
[timw@baa ~]$ ll /sys/devices/system/cpu/cpu0
total 0
drwxr-xr-x 7 root root 0 Nov 5 14:44 cache/
lrwxrwxrwx 1 root root 0 Nov 5 14:39 cpufreq -> ../cpufreq/policy0/
drwxr-xr-x 5 root root 0 Nov 5 14:47 cpuidle/
-r-------- 1 root root 4096 Nov 5 14:47 crash_notes
-r-------- 1 root root 4096 Nov 5 14:47 crash_notes_size
lrwxrwxrwx 1 root root 0 Nov 5 14:41 driver ->
../../../../bus/cpu/drivers/processor/
lrwxrwxrwx 1 root root 0 Nov 5 14:47 firmware_node ->
../../../LNXSYSTM:00/LNXCPU:00/
drwxr-xr-x 2 root root 0 Nov 5 14:47 hotplug/
drwxr-xr-x 2 root root 0 Nov 5 14:47 microcode/
lrwxrwxrwx 1 root root 0 Nov 5 14:47 node0 -> ../../node/node0/
drwxr-xr-x 2 root root 0 Nov 5 14:47 power/
lrwxrwxrwx 1 root root 0 Nov 5 14:38 subsystem -> ../../../../bus/cpu/
drwxr-xr-x 2 root root 0 Nov 5 14:47 topology/
-rw-r--r-- 1 root root 4096 Nov 5 14:47 uevent
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.
2376
days inactive
2467
days old
26 comments
8 participants
participants (8)
-
Dave Lers -
deloptes -
Felix Miata -
Gene Heskett -
Slávek Banko -
Tim Williams -
wofgdkncxojef -
wofgdkncxojef＠gmail.com