Summary: | VLC core dump in libtag - free(): invalid pointer | ||
---|---|---|---|
Product: | [Frameworks and Libraries] phonon-backend-vlc | Reporter: | Kerry N <mothlight> |
Component: | general | Assignee: | Scott Wheeler <wheeler> |
Status: | RESOLVED DOWNSTREAM | ||
Severity: | normal | CC: | bcooksley, fabo, jb, lalinsky, martin.sandsmark, me, myriam, simon.lewis, wcancino, wheeler |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Fedora RPMs | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Attachments: |
log start vlc with valgrind and debuginfo packages
log start vlc with strace |
Description
Kerry N
2010-09-03 02:27:12 UTC
Created attachment 51554 [details]
log start vlc with valgrind and debuginfo packages
I'm confirming this bug. This bug reproduced randomly. Bug present on Fedora 12/13 and architectures i386 and x86_64. And I'm attaching my strace and valgrind with debug info.
Created attachment 51555 [details]
log start vlc with strace
taglib 1.6.3-1.fc13
libstdc++ 4.4.4-10.fc13
kde 4.4.5
vlc 1.1.3-1.fc13
I would be *very* surprised if this turns out to be a TagLib bug since the line that's crashing is just attempting to instantiate a string, which is naturally extensively tested (and valgrind-clean). The crash actually happens inside of the STL. Unfortunately without some file that this can be reproduced on or some simple case that just involves TagLib and not VLC, the chances of this getting tracked down are slim. I'm not sure that this bug in taglib or STL. But if I moving vlc-plugin for taglib from library directory, vlc executed without bugs. With other side - k3b, kdemultimedia depends on taglib and not having this bug. Maybe I'm stupid, but not understand this bug. *** Bug 251913 has been marked as a duplicate of this bug. *** I'm pretty certain this is a bug in the VLC / TagLib connector since we've seen a number of crashes coming across from that combo. All of the crashes are in really well traversed paths within TagLib's code (mostly creating or destroying strings, or doing simple things to them like converting them to C strings). From that pattern I'd be very surprised if this is not some memory corruption inside of VLC where it's either got dangling pointers to TagLib objects that are being dereferenced or is passing in invalid data to the TagLib::String constructor. Since there's no component for VLC itself, it was suggested on IRC that I bump this over to the Phonon-VLC component for now. I'm adding myself to the CC list to see what comes of it. This free() issue happens in VLC/Taglib Only on Fedora systems, so far, as far as VLC upstream is concerned. The bug which I just marked as a duplicate came from Debian. Then, those two bugs are different. I'll reopen the other one. This one is a packaging bug from Fedora. Just tried VLC in Fedora 14 $ rpm -q kdebase taglib vlc kdebase-4.5.2-2.fc14.i686 taglib-1.6.3-1.fc13.i686 vlc-1.1.4-4.fc14.i686 It seems to work now without the core dump. *** Bug 260346 has been marked as a duplicate of this bug. *** This problem is not resovled - it causings a lot of users headaches - and neither kde, vlc, fedora or rpmfusion are taking any responsibility for it... Hello: In my case, upgrading to vlc 1.5.1 solves all my problems. I read somewhere that libtag is not thread-safe, so vlc fixed its interaction with libtag. I am no longer able to reproduce the problem on my machine. For me, whatever changed in upgrading to Fedora 14 seems to have fixed it. Sorry, I mean vlc 1.1.5 (debian sid) Oh well.. I did make the effort of installing Fedora 14 on my laptop and found that it kept feezing. As I needed a working system I went back to Fedora 13 which is rock-solid (as was the previous Fedora 12 installation). The downside is that rpmfusion does not backport the current applications that they support to fc13. Especially the multi-media apps well behind the times. Shame really as the support from red hat and planetccrma has been exemplary. Why is it that openSUSE don't need any patchs for taglib yet every other rpm based distro needs to workaroung with multilib and utf8 compatibility? I am not a programm but could this problem be the result of lines 201 and 202 in tstring.cpp? String::~String() { if(d->deref()) delete d; } deleting the StringPrivate of String::null Reassigning to the new bugzilla product for better bug tracing of the various backends. Sorry for the noise. |