| Summary: | Segmentation fault while calling drakconf as root in KDE4 | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | Bjarne Thomsen <bjarne.thomsen> |
| Component: | RPM Packages | Assignee: | Thierry Vignaud <thierry.vignaud> |
| Status: | RESOLVED WORKSFORME | QA Contact: | |
| Severity: | normal | ||
| Priority: | Normal | CC: | bjarne.thomsen, zen25000 |
| Version: | Cauldron | Keywords: | NEEDINFO |
| Target Milestone: | --- | ||
| Hardware: | i586 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Source RPM: | drakconf | CVE: | |
| Status comment: | |||
| Attachments: |
Output fro gdb
Output from gdb Output from gdb pasted to this logfile List of debug packages complete output from gdb with a segfault Full gdb output |
||
|
Description
Bjarne Thomsen
2013-10-21 20:20:55 CEST
I should have mentioned that mageia cauldron is running in virtual box on mageia3. Also, the "Software Management" screen appears for a second before the crash. The problem could be virtualbox in combination with KDE4. Source RPM:
drakconf-12.43-2.mga4 =>
(none) I have now updated 1282 packages from cauldron, but drakconf still segfaults in KDE4. I now reinstalled java-1.7.0.60-openjdk, and called drakconf in the MATE DE. It segfaulted the first time, but the next many times it worked! I have now also obtained a segmentation fault while calling drakconf in xfce4, but this has so far only happened once. It never reached java, so it is doubtful that the problem has anything to do with java. The above looks like a memory leak, so I tried valgrind. valgrind -v --leak-check=full --show-reachable=yes /usr/bin/drakconf .. ==4270== LEAK SUMMARY: ==4270== definitely lost: 356 bytes in 1 blocks ==4270== indirectly lost: 4,173 bytes in 87 blocks ==4270== possibly lost: 1,484,584 bytes in 4,091 blocks ==4270== still reachable: 1,263,078 bytes in 15,972 blocks ==4270== suppressed: 0 bytes in 0 blocks ==4270== ==4270== ERROR SUMMARY: 161 errors from 161 contexts (suppressed: 0 from 0) ==4270== ERROR SUMMARY: 161 errors from 161 contexts (suppressed: 0 from 0) So, what is causing it.
Manuel Hiebel
2013-10-23 10:31:32 CEST
Assignee:
bugsquad =>
thierry.vignaud I do not understand valgrind! I had hoped that more than 0 errors meant that something was wrong. I have used valdgrind in Mageia3 on a real PC, and I obtain 4 errors with the identical command. Well, 4 is less than 161, but... The odds are high it's an issue with the qt/gtk/oxygen theme engine.
Could you try running drakconf from gdb?
1) install it: "urpmi gdb"
2) it would be nice to install debug packages:
- enable the "Core Release Debug" medium in the medium manager
(edit-urpm-sources.pl)
- run "urpmi {perl{,-Gtk2,-Glib},glib2.0,gtk+2.0}-debuginfo"
3) run gdb: "gdb -q --args perl /usr/sbin/drakconf"
4) type "run" in order to tell gdb to actually start drakconf
5) type "bt" once it segfaults
6) copy the backtrace that is printed in some file you'll attach
to this bug report (please do not paste it as a comment)Keywords:
(none) =>
NEEDINFO Created attachment 4444 [details]
Output fro gdb
gdb -q --args perl /usr/bin/drakconf 2>&1 | tee logfile.txtCC:
(none) =>
bjarne.thomsen The problem with the output above is that it exited normally. Just running drakconf gives segmentation fault. I told you to use "sbin" in drakconf path, not "bin"
/\
Created attachment 4445 [details]
Output from gdb
gdb -q --args perl /usr/sbin/drakconf 2>&1 | tee logfile1.txt
No difference. It still exits normally.
I forgot to mention that gdb at the first run asked me to install debuginfo for 84 more packages that I could do by pasting the given long command to the command line. You mean that drakconf doesn't segfault when started from the debugger but only when run from the command line? How do you run it? Does running the "drakconf" command segfault? Terminal: # drakconf The "Software Management" screen comes up for about 1 s, and then # Segmentation fault From within gdb: (gdb) run The "Software Management" screen comes up permanently until I quit. (gdb) normal exit. Somehow the debug code prevents the segfault. Created attachment 4447 [details]
Output from gdb pasted to this logfile
New development. This time the output was not piped to a logfile. Instead the screen output was pasted to a file using vim. gdb was started by the command
gdb -q --args perl /usr/sbin/drakconf
(gdb) run
This time drakconf segfaulted inside gdb, and I could type bt.
The result is found in the attached file.
Didn't gdb complained about some missing debuginfo packages? What's the output of 'rpm -qa "*-debuginfo"' (In reply to Thierry Vignaud from comment #15) > Didn't gdb complained about some missing debuginfo packages? see comment #11 CC:
(none) =>
zen25000 I did saw but your trace is not complete. Again, what's the output of 'rpm -qa "*-debuginfo"' ? Created attachment 4448 [details]
List of debug packages
A few new debug packages were missing. I am quite sure they were not missing the first time. They are now installed. I did make an update to cauldron last night.
Created attachment 4449 [details]
complete output from gdb with a segfault
There is still something missing: a python module "backtrace".
How can I fix that?
And yet it's not usable yet. Try running directly: gdb -q --args perl /usr/libexec/drakconf Created attachment 4453 [details]
Full gdb output
This time it exited normally, but still
ImportError: No module named backtrace
Any news on this bug? I still get a segmentation fault when calling drakconf in KDE4. Mageia4 from cauldron is running in virtualbox on Mageia3. Actually, I have some news on this bug. I have installed mageia4-beta1 from scratch, and the bug went away. Since then, I have updated on a regular basis, and the bug has never re-appeared again. I do not know why. I should perhaps mention that I am running Mageia4 in virtualbox. So closing, there was some update too. If it come back feel free to reopen Status:
NEW =>
RESOLVED |