Crash diagnostics

Andrew Turner andrewturner512 at googlemail.com
Fri Mar 20 14:28:49 CET 2009


There are a few things in that code that make me a little scared. It's
been a while since I've touched C-strings though, so I could be wrong,
but:

1) To free memory allocated by "strdup", you should use "free", not
"delete". This is because it uses "malloc" and not "new" to allocate
the memory.

2) There are assignments from string literals in the unicodeTest
function and yet later there will be a "delete" call in the
destructor. You shouldn't free/delete string literals. All you do when
you assign a string literal is copy the address of the literal. The
literal itself exists in the executable you're running - it is not
created separately on the heap - so if you try to delete it then bad
things happen. Deleting your own executable (or parts of it) is
probably a good reason to crash.

3) You're right about the potential memory leak by doing the strdup
and not bothering to free it before it's overwritten with a new value,
Jeff.

Is there any reason why this code would not work just as well if the
original strdup is removed so that it is just set to point to an empty
string literal ( "" ). Then you could remove the call to delete in the
destructor; with just string literals, nothing ever needs freeing.

-andrewt512


2009/3/20 Ian Monroe <ian.monroe at gmail.com>:
> 2009/3/20 Jeff Mitchell <mitchell at kde.org>:
>> If any of you guys can see what might be going wrong here, please let me
>> know.  The crash takes place in the destructor of a KEncodingProber
>> object allocated on the stack, in the line "delete encoding".  Here are
>> the places "encoding" is used:
>>
>>
>> In declaration of KEncodingProberPrivate:
>> const char * encoding;
>>
>> In constructor:
>> KEncodingProberPrivate(): encoding(strdup("")) ......
>>
>> In destructor of KEncodingProberPrivate:
>> delete encoding;  <- crash
>>
>> In function KEncodingProberPrivate::unicodeTest:
>> encoding = "UTF-8";
>> encoding = "ISO-10646-UCS-4";
>> (a few other similar assignments...these all depend on the cases in a
>> switch)
>> ...(then, later in the same function)...
>> if (encoding && strlen(encoding))
>> //stuff
>>
>>
>> I've gone through the code and ensured that encoding is only ever
>> deleted in the private class destructor, so it's not a double free.  One
>> thing I noticed is that it's a const char pointer, and most of those
>> assignments it is being assigned to pre-defined character strings,
>> except for the initialization which is setting it to a strdup.  If
>> nothing else, that could end up being a memory leak if it eventually is
>> assigned to a different string and that original strdup-provided string
>> goes into the ether.  But that shouldn't cause a crash.
>>
>> Anyone have ideas?
>> --Jeff
>
> Have you been able to replicate the crash?
>
> Ian
> _______________________________________________
> Amarok-devel mailing list
> Amarok-devel at kde.org
> https://mail.kde.org/mailman/listinfo/amarok-devel
>


More information about the Amarok-devel mailing list