Re: double free or corruption in base Rev. 39909 2016-06-22 16:14:05

[Pirmin Braun]

On Thu, 23 Jun 2016 20:32:56 +0100
Richard Frith-Macdonald <address@hidden> wrote:

> 
> > On 23 Jun 2016, at 14:43, Pirmin Braun <address@hidden> wrote:
> > 
> > Hi, I've isolated a strange crash, see attached test program. It's 
> > perfectly reproducible.
> > When calling mysql_real_query(...) with a certain sql string this will 
> > happen:
> > 
> > *** Error in 
> > `/usr/GNUstep/Local/Projects/Test_MariaDB_ObjC/obj/Test_MariaDB_ObjC': 
> > double free or corruption (!prev): 0x00000000007d82d0 ***
> > 
> > Program received signal SIGABRT, Aborted.
> > 0x00007ffff66ba107 in __GI_raise (address@hidden) at 
> > ../nptl/sysdeps/unix/sysv/linux/raise.c:56
> > 56      ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
> > (gdb) bt
> > #0  0x00007ffff66ba107 in __GI_raise (address@hidden) at 
> > ../nptl/sysdeps/unix/sysv/linux/raise.c:56
> > #1  0x00007ffff66bb4e8 in __GI_abort () at abort.c:89
> > #2  0x00007ffff66f8204 in __libc_message (address@hidden, address@hidden 
> > "*** Error in `%s': %s: 0x%s ***\n")
> >    at ../sysdeps/posix/libc_fatal.c:175
> > #3  0x00007ffff66fd9de in malloc_printerr (action=1, str=0x7ffff67eb0e8 
> > "double free or corruption (!prev)", ptr=<optimized out>) at malloc.c:4996
> > #4  0x00007ffff66fe6e6 in _int_free (av=<optimized out>, p=<optimized out>, 
> > have_lock=0) at malloc.c:3840
> > #5  0x00007ffff73a5026 in ?? () from 
> > /usr/lib/x86_64-linux-gnu/libmariadb.so.2
> > #6  0x00007ffff73a2f1d in ?? () from 
> > /usr/lib/x86_64-linux-gnu/libmariadb.so.2
> > #7  0x00007ffff739b194 in ?? () from 
> > /usr/lib/x86_64-linux-gnu/libmariadb.so.2
> > #8  0x00007ffff739b62e in ?? () from 
> > /usr/lib/x86_64-linux-gnu/libmariadb.so.2
> > #9  0x00007ffff739c8bc in ?? () from 
> > /usr/lib/x86_64-linux-gnu/libmariadb.so.2
> > #10 0x00007ffff739cb97 in mysql_real_query () from 
> > /usr/lib/x86_64-linux-gnu/libmariadb.so.2
> > #11 0x0000000000400bac in executeSQL (sql=0x602460 <_OBJC_INSTANCE_5>, 
> > sock=0x64c780) at Test_MariaDB_ObjC_main.m:49
> > #12 0x0000000000400d06 in main (argc=1, argv=0x7fffffffe068) at 
> > Test_MariaDB_ObjC_main.m:86
> > 
> > 
> > I've debugged the -[NSString dataUsingEncoding:...] method but found 
> > nothing suspicious.
> > I think, it's not a MariaDB problem since I've implemented the same with 
> > plain C where it doesn't crash. The funny thing is, it depends on the sql 
> > string. Length doesn't matter. But the order of the fields does. And the 
> > table alias does. And when leaving out the "swift" field, it won't crash. 
> > I've included a slightly modified sql string which won't crash. 
> 
> I don't have the test environment or knowledge of mysql but I have looked at 
> the code and as far as I can see it contains very little ObjC stuff at all, 
> and no threading to confuse issues.
> Basically, it takes a few literal NSStrings, converts them to NSData objects 
> holding CString data, and passes a pointer to that data to the mysql API.  I 
> haven't missed anything have I?

yes, and I've debugged this and the NSData gets the correct length and the 
correct string and its retainCount is 1. Another retain didn't make a 
difference.

> 
> That being the case ... I tried building the code with the calls to mysql 
> stripped out ... so it does everything apart from calling the mysql libraries 
> (which I don't have on my machine).
> Then I checked what was happening under gdb.
> The string literals are plain ascii strings ... so the 
> -dataUsingEncoding:allowLossyConversion method doesn't actually do any 
> conversion, it just creates data objects pointing to the C strings provided 
> by the compiler.

right.

> That means there's very, very little to go wrong, and for sure the data being 
> passed into the mysql library can't be corrupted (because it's a constant 
> string provided by the compiler, rather than something generated at runtime).

exactly.

> Yes there's always some potential for problems (bug in NSObject or NSData and 
> in system initialisation), but it doesn't really look very likely ... I would 
> say there's no particular reason to think the problem is ObjC related rather 
> than in the mysql, library, because memory corruption issues can hide/appear 
> simply because you change the memory layout of the program slightly.
> In fact, the crash occurs in the mysql library, it's a problem with a free() 
> (and the library must therefore have malloced some memory).  If the heap was 
> corrupted by the objc code before the mysql code was called, why didn't the 
> malloc() inside the mysql code trigger an abort?  While not conclusive, I 
> think the balance of evidence points towards the mysql library as the problem
> 

but then I did the same in plain C (see Test_MariaDB_main.c) and there it 
works. Or in other words: when I remove the ObjC runtime and the very little 
ObjC stuff, the crash doesn't occur.

> You could try calling mcheck_pendantic() as the first thing in main() ... 
> that should check before/after every memory allocation function. You could 
> also call mcheck_check_all() after each objc method to check that the method 
> did not corrupt the heap after the last memory allocation function was called.
> You could try running under valgrind ... which will pick up some memory 
> management problems.

ok, will try that.
> 
> 
> 


-- 
Pirmin Braun - IntarS Unternehmenssoftware GmbH - Creidlitzer Straße 106, 96450 
Coburg
+49 2642 40526292 +49 174 9747584 - skype:pirminb www.intars.de  address@hidden
Geschäftsführer: Pirmin Braun, Ralf Engelhardt Registergericht: Amtsgericht 
Coburg HRB3136