Summary: | Frequent Crashes scrolling through collection list | ||
---|---|---|---|
Product: | [Applications] juk | Reporter: | Steven P. Ulrick <spu> |
Component: | general | Assignee: | Scott Wheeler <wheeler> |
Status: | RESOLVED FIXED | ||
Severity: | crash | CC: | spu |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | RedHat Enterprise Linux | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Attachments: | Tarball of backtraces from juk-1.95 |
Description
Steven P. Ulrick
2003-10-25 09:09:59 UTC
Forgot to add, that of course, the expected behaviour would be that Juk wouldn't crash so frequently. Other than that, I really love Juk :) In fact, that's why I'm persuing this bug. Created attachment 2884 [details]
Tarball of backtraces from juk-1.95
The attatched files are from five of my six most recent juk-1.95 crashes. They
all took place within a matter of an hour or two. If you want me to stop
sending backtraces, let me know, and I'll be glad to oblige :)
The above attatched tarball seems to be defective. I don't understand this, as it works fine on my machine. I have therefore uploaded it to the following location: http://www.faith4miracle.org/juk-backtraces.tar.bz2 I apologize for any inconvenience :) Steven P. Ulrick Hi Steven, If you've compiled from source it will make the backtraces more useful if you use --enabled-debug=full in your configure line. That gives me the line number in addition to the function name that it has by default. Otherwise I'll have a look at this based on the information that you gave in the next few days. Hello, Scott :) As requested, I recompiled Juk 1.95 with "--enabled-debug=full" I have uploaded backtraces of the last four times Juk 1.95 has crashed to the following location: http://www.faith4miracle.org/juk-backtraces2.tar.bz2 Unless you say different, any future backtraces I will upload to a web-server instead of attatching to this comment. Please refer to "Additional Comment #3" above :) Ok, from the looks of it, this is only happening when the tag editor is visible, correct? I'll mess around with it this weekend and see if I can reproduce it. Hello, Scott I apologize for my lateness in responding to your last comment. To answer your question, to the best of my knowledge, all of the crashes I've had have been with the editor visible. If I can be of any further assistance to you, feel free to let me know. Hello, Scott :) If you need them, I have more backtraces that I have saved since I enabled full debugging on Juk 1.95. If they are of any relevance to you, you will find them at the following location: http://www.faith4miracle.org/JukBacktraces-11052003.tar.bz2 Yep -- just been busy the last few days with other code. There's hopefully enough information here for me to figure out what's going on. I'll let you know if I need more in the next short while... Finally getting back to looking a bit more into this -- and sadly while I see the line where it's crashing I don't really see why. Actually most of the related code has been rewritten in CVS, but since I can't reproduce it I can't be sure that it's fixed. (Though I'm considering making a new JuK beta -- we'll see if time allows such.) It seems to be some sort of memory coruption, but I'm still not exactly sure how. Do you happen to have valgrind installed on your system? If so just running "valgrind juk --nofork" might give some more information. (Valgrind is a memory debugging tool.) If you have any luck with that posting the full output up to and including the crash would be helpful. I installed Valgrind after I read your last comment. At the following location, you will find a tarball that contains the output from Valgrind from a recent session of Juk, and two backtraces from the KDE crash handler. http://www.faith4miracle.org/juk-valgrind.tar.bz2 I recently reinstalled Fedora Core 1 (I put my two harddrives on separate IDE controllers) and ever since then, I think something went wrong with the KDE crash handler. Please get back to me if, after looking at the output contained in the two backtraces that are in the tarball referenced above, you think something might be wrong. If you know how I can fix it, cool. If not, please refer me to whoever would have that information :) Ok, still can't reproduce this, but I *might* have an idea what's going on. Does this usually happen after you remove items from the list? Subject: kdemultimedia/juk CVS commit by wheeler: Finally was able to reproduce this one. Add lots of paranoia to check for null items before dereferencing them and make sure that item deletion signals are propogated to various places even when items are being removed in lists other than the current one. CCMAIL:66540-done@bugs.kde.org M +4 -5 playlist.cpp 1.166 M +2 -2 playlist.h 1.98 M +7 -0 playlistitem.cpp 1.71 M +6 -0 playlistitem.h 1.46 M +85 -58 tageditor.cpp 1.42 M +3 -0 tageditor.h 1.19 Hello, Scott :) In response to your first comment yesterday, the crashes occured not so much when thing were removed from a list, but more so when things were changed: ie - I'd change a tag to the way I wanted it, click on another song, album or artist to work on, and Juk would crash. In reference to your second comment, I would love to try out whatever fix you have come up with, but I can't compile the CVS because I only have qt 3.1x I've had disastrous experiences with qt when attempting to upgrade versions of KDE (I've since given up on trying that :)) I understand I should be able to configure it and run it in my home directory? I believe I tried that before, but I'll try it again, just to see. If you have any advice, or a link where I could download a build that I COULD compile with qt 3.1, I'd love to hear from you :) Steven P. Ulrick It's certainly possible to have multiple Qt versions installed, but it in fact also requires the KDE libraries from CVS at this point. I think Konstruct (an automated build system) supports building KDE from CVS -- if not I know it supports our betas, one of which should be out in a few days. As for another beta -- that's still up in the air. I haven't tried to compile JuK against KDE 3.1 for a while, so I don't know how much porting would be needed at this point. However, even if I do another beta I will probably require KDE 3.1.4 / Qt 3.2 just so that there's less that I have to backport. I really don't want to spend that much time on it since KDE 3.2 is just a couple months out. |