i fixed it!! you were right! it's not to do with the guts of sql.. rather it's to do with my incorrect sql statement..
i used MATCH instead of =.. for more details see the stack over flow response i made here http://stackoverflow.com/a/14534957/766570 A On Fri, Jan 25, 2013 at 9:18 PM, Roger Binns [via SQLite] < ml-node+s1065341n66718...@n5.nabble.com> wrote: > -----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 > [hidden email] <http://user/SendEmail.jtp?type=node&node=66718&i=0> > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > > > ------------------------------ > If you reply to this email, your message will be added to the discussion > below: > > http://sqlite.1065341.n5.nabble.com/using-the-same-sqlite-parameter-more-than-once-causes-premature-memory-deallocation-tp66687p66718.html > To unsubscribe from using the same sqlite parameter more than once causes > premature memory deallocation, click > here<http://sqlite.1065341.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=66687&code=YWJkdWxsYWguYmFraGFjaEBnbWFpbC5jb218NjY2ODd8LTIwMjk1NDgyOTg=> > . > NAML<http://sqlite.1065341.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml> > -- View this message in context: http://sqlite.1065341.n5.nabble.com/using-the-same-sqlite-parameter-more-than-once-causes-premature-memory-deallocation-tp66687p66726.html Sent from the SQLite mailing list archive at Nabble.com. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
