[PATCH] weird filename corruption

View: New views
3 Messages — Rating Filter:   Alert me  

[PATCH] weird filename corruption

by Bugzilla from huntedhacker@tiscali.co.uk :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Some parts of this message have been removed. Learn more about Nabble's security policy.

I've been having a bizarre problem where I'd get errors like this:

TagLib: Could not open file /home/music/A/Hi-Fi_Serious/11_W.D.y.C.A.I..¡p3

Note that the 'm' of 'mp3' has been replaced, with an i in this case. The

character it is replaced with is not consistent, and sometimes it disappears

altogether or the string cuts off at that point. Occasionally, it just turns

into

TagLib: Could not open file o

or some other character. This is not consistent - about 70% of the time,

there's no problem.

I traced it down to the name(fileName) assignment in the constructor

File::FilePrivate::FilePrivate in toolkit/tfile.cpp, which seems to sometimes

corrupt both fileName and name. I have no idea why this would cause this

problem, given that it's basically the constructor of std::string (I'm on

Linux).

I noticed that the fact that name is a std::string is never used, so I ditched

it. The attached patch fixes the issue.

Can I commit this?

Alex

--

KDE: http://www.kde.org

Ubuntu/Kubuntu: http://www.ubuntu.org http://www.kubuntu.org


[taglib_filename_corruption_fix.patch]

Index: tfile.cpp
===================================================================
--- tfile.cpp (revision 799428)
+++ tfile.cpp (working copy)
@@ -51,20 +51,6 @@
 
 using namespace TagLib;
 
-#ifdef _WIN32
-
-typedef FileName FileNameHandle;
-
-#else
-
-struct FileNameHandle : public std::string
-{
-  FileNameHandle(FileName name) : std::string(name) {}
-  operator FileName () const { return c_str(); }
-};
-
-#endif
-
 class File::FilePrivate
 {
 public:
@@ -72,7 +58,7 @@ public:
 
   FILE *file;
 
-  FileNameHandle name;
+  FileName name;
 
   bool readOnly;
   bool valid;


_______________________________________________
taglib-devel mailing list
taglib-devel@...
https://mail.kde.org/mailman/listinfo/taglib-devel

Re: [PATCH] weird filename corruption

by Bugzilla from wheeler@kde.org :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Alex Merry wrote:

>
> I've been having a bizarre problem where I'd get errors like this:
>
> TagLib: Could not open file
> /home/music/A/Hi-Fi_Serious/11_W.D.y.C.A.I..¡p3
>
> Note that the 'm' of 'mp3' has been replaced, with an i in this case. The
>
> character it is replaced with is not consistent, and sometimes it
> disappears
>
> altogether or the string cuts off at that point.
>

Usually an error like that comes from keeping a pointer to the output of
c_str() for longer than the lifetime of the std::string it came from.  I
can't be certain that it's not a TagLib bug, but I suspect the bug is in
the calling code.  Can you paste it in?  Here's what you're looking for:

std::string foo()
{
    return "foo.mp3";
}

void bar()
{
    const char *s = foo().c_str();
    TagLib::File file(s); // <-- memory corruption, the std::string
returned in the last function has passed out of scope taking the c_str()
with it.
}


-Scott
_______________________________________________
taglib-devel mailing list
taglib-devel@...
https://mail.kde.org/mailman/listinfo/taglib-devel

Re: [PATCH] weird filename corruption

by Bugzilla from huntedhacker@tiscali.co.uk :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Some parts of this message have been removed. Learn more about Nabble's security policy.

On Tuesday 22 April 2008 14:48:47 Scott Wheeler wrote:

> Alex Merry wrote:

> > I've been having a bizarre problem where I'd get errors like this:

> >

> > TagLib: Could not open file

> > /home/music/A/Hi-Fi_Serious/11_W.D.y.C.A.I..¡p3

>

> Usually an error like that comes from keeping a pointer to the output of

> c_str() for longer than the lifetime of the std::string it came from. I

> can't be certain that it's not a TagLib bug, but I suspect the bug is in

> the calling code. Can you paste it in? Here's what you're looking for:

Bang on. Sorry for bothering you with it, and thanks for the pointer.

FYI, it was the Amarok collection scanner (http://websvn.kde.org/trunk/extragear/multimedia/amarok/src/collectionscanner/) which was using the constData() of a QByteArray after the QByteArray had been discarded.

Alex

--

KDE: http://www.kde.org

Ubuntu/Kubuntu: http://www.ubuntu.org http://www.kubuntu.org


_______________________________________________
taglib-devel mailing list
taglib-devel@...
https://mail.kde.org/mailman/listinfo/taglib-devel
LightInTheBox - Buy quality products at wholesale price!