| Summary: | Crash in phonon when changing language with kdesu systemsettings [@ streamToByteArray<QHash<QByteArray, QVariant> >] | ||
|---|---|---|---|
| Product: | [Frameworks and Libraries] Phonon | Reporter: | Richard Llom <richard.llom> |
| Component: | kded module for audio device listing | Assignee: | Harald Sitter <sitter> |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | crash | CC: | b.buschinski, germano.massullo, martin.sandsmark, myriam, richard.llom |
| Priority: | NOR | Keywords: | triaged |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Chakra | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: | New crash information added by DrKonqi | ||
|
Description
Richard Llom
2013-04-16 14:31:25 UTC
Is this crash reproducible? very weird crash, seems like our custom data type isn't registered with Qt before we try to save it. Yet another race condition in the kded module, maybe. Created attachment 78981 [details]
New crash information added by DrKonqi
kded4 ($Id$) on KDE Platform 4.10.2 using Qt 4.8.4
- What I was doing when the application crashed:
Yes, I can reproduce this.
Although a little correction:
First time systemsettings actually did not crash, but was just in an endless loop "Updating Settings..." (or such a like), I could cancel it and everything went along.
This time there was no error at all in systemsettings.
I can try to do a valgrind trace if needed.
-- Backtrace (Reduced):
#11 0x00007ff34e7c8b74 in QVariant::save (this=0x18d7f58, s=...) at kernel/qvariant.cpp:2049
#12 0x00007ff34e7c8c9f in operator<< (s=..., p=...) at kernel/qvariant.cpp:2076
#13 0x00007ff33e72f76b in operator<< <QByteArray, QVariant> (out=..., hash=...) at /usr/include/QtCore/qdatastream.h:383
#14 0x00007ff33e728154 in streamToByteArray<QHash<QByteArray, QVariant> > (data=...) at /chakra/desktop-testing/kde-runtime/src/kde-runtime-4.10.2/phonon/kded-module/phononserver.cpp:956
#15 PhononServer::updateDevicesCache (this=0x18259e0) at /chakra/desktop-testing/kde-runtime/src/kde-runtime-4.10.2/phonon/kded-module/phononserver.cpp:1017
If you can reproduce it, please add exact steps to reproduce with a freshly created user account. (In reply to comment #4) > If you can reproduce it, please add exact steps to reproduce with a freshly > created user account. Since I'm running with kdesu does the user actually matters? (I think it is always running in root environment). Anyways, I did (steps to reproduce): - Create new user - Login as new user - Open Krunner enter kdesu systemsettings - produce a sound, (e.g. change a setting in one modul, hit overview -> query (do you want to save...) with sound comes). - Sound plays, but dr. konqi opens with already attached backtraces. - systemsettings is stable. == end == I didn't dare to create a new root, but I checked the roots home for pulse configs/files. There was only one cookie, I renamed and tried again -> still crash. Also I noticed that this crash happens only once per session, if I want to reproduce it several times I need to restart. *** Bug 321758 has been marked as a duplicate of this bug. *** Martin suspects a race condition and I kind of agree even though that really really really should not happen. Which phonon version and distribution are you all using? I'll also need some additional info as I absolutely cannot reproduce this... Someone who can reproduce the problem please make sure that phonon and phononserver debug symbols are installed then run kded4 in gdb > gdb --args kded4 --nofork and set breakpoints on registerPhononMetaTypes and PhononServer::updateDevicesCache > b registerPhononMetaTypes > b PhononServer::updateDevicesCache then run > r and try to trigger the crash, but first both breakpoints should be hit so in gdb do for each breakpoint (note that for the first command you may have to hit enter a couple of times to get the entire output) > thread apply all bt > c once it crashes simply quit > q copy your entire terminal backlog into a file and attach it. alternatively just attach the backtrace and tell me which breakpoint is hit first Notes for further investigation: type registration is done by using [1] (phonnnamespace.cpp) which in application cases should always be executed before main. however phononserver is a kded module i.e. plugin, so order may be messed up, weird but possible. There is probalby nothing that can be done if the execution order is wrong other than manually registering the types in phononserver to be on the safe side. [1] https://qt-project.org/wiki/QtResources#9ffdb95250e26c7a6b468126ac7c75b0 *** Bug 322618 has been marked as a duplicate of this bug. *** (In reply to comment #7) > Martin suspects a race condition and I kind of agree even though that really > really really should not happen. > > Which phonon version and distribution are you all using? > phonon-4.6.0-7.fc19.x86_64 on Fedora 19 Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days, the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please set the bug status as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone! Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone! |