-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 24/01/13 17:37, abbood wrote: > Btw I'm curious how did you find out about this auto release thing? Can > you add more detail about that?
I used a debugger to set a breakpoint in malloc_error_debug as the message says. That gave a stack trace of an autorelease pool being drained. Since most frees happen in the autorelease pool drain it doesn't particularly help with telling you which item is the problem. I asked on the valgrind list and got a way of keeping the allocation stack trace instead of the free one. (The next valgrind release will allow you to print both.) http://article.gmane.org/gmane.comp.debugging.valgrind/12755 The cause of that original issue in my code was NSInvocation and dealing with returned objects. The cause of the most recent issue was because NSData was owning a buffer passed to it that I didn't want it to. > Ie I put a break point in malloc_error_break.. But then I just jump to > the internals of sqlite.. And basically within the salite internals > it's freeing an operation that doesn't exist.. Using valgrind will narrow down the problem. What you are seeing is the consequence of earlier memory errors. > But im not sure if it's a good idea to modify the guts of sqlite.. Is > it? SQLite is *extremely* unlikely to have a bug. Some other piece of code has the bug, and SQLite is the victim. Remember that virtually every web browser on virtually every platform is using SQLite - an error would show up for someone. http://www.sqlite.org/testing.html > And then I made the second part use in line variables as opposed to > bindings.. Ie NSString stringwithformat.. Do remember sqlite3_mprintf for that sort of thing, especially if strings are involved to avoid sql injection attacks/bugs: http://www.sqlite.org/c3ref/mprintf.html > So I deleted that row from the dbase and it works fine.. I couldn't > find anything different on that row.. Memory allocators typically have buckets for different sized allocations often in powers of two. It could be that row had a string needing 33 bytes while others needed less which then caused memory to come out of a different bucket which then changes where the victim of the actual bug shows up. Roger -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAlEC2o8ACgkQmOOfHg372QQQgACg2u97/wfBys3ryf/EZphv0R43 hjUAoLh2/anUjqGWa+GxC+7GO5tt3D0L =X0kB -----END PGP SIGNATURE----- _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
