On Thu, 23 Jun 2016 20:32:56 +0100 Richard Frith-Macdonald <[email protected]> wrote:
> > > On 23 Jun 2016, at 14:43, Pirmin Braun <[email protected]> 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 (sig=sig@entry=6) 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 (sig=sig@entry=6) at > > ../nptl/sysdeps/unix/sysv/linux/raise.c:56 > > #1 0x00007ffff66bb4e8 in __GI_abort () at abort.c:89 > > #2 0x00007ffff66f8204 in __libc_message (do_abort=do_abort@entry=1, > > fmt=fmt@entry=0x7ffff67eafe0 "*** 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 [email protected] Geschäftsführer: Pirmin Braun, Ralf Engelhardt Registergericht: Amtsgericht Coburg HRB3136 _______________________________________________ Gnustep-dev mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnustep-dev
