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

[Richard Frith-Macdonald]

> 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?

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.
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).
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

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.