Thanks. I'll hold off on checking the result of every sqlite3_bind_* for now.
It's unlikely I'm using a finalized statement otherwise I believe I would get a
given crash much more often. The sqlite3_prepare_v2 statements that are failing
only fail occasionally, not every time. But I'll double ch
On Thu, Jul 19, 2012 at 2:07 PM, Rick Maddy wrote:
> Didn't mean to imply that failing to check the return value resulted in
> memory corruption. I was wondering if it was possible that one of the many
> calls to sqlite3_bind_* in my code may actually be causing some memory
> corruption. I can
On Thu, Jul 19, 2012 at 2:07 PM, Rick Maddy wrote:
> Didn't mean to imply that failing to check the return value resulted in
> memory corruption. I was wondering if it was possible that one of the many
> calls to sqlite3_bind_* in my code may actually be causing some memory
> corruption. I can en
Didn't mean to imply that failing to check the return value resulted in memory
corruption. I was wondering if it was possible that one of the many calls to
sqlite3_bind_* in my code may actually be causing some memory corruption. I can
envision some possible buffer overflows associated with thos
On Thu, Jul 19, 2012 at 1:56 PM, Rick Maddy wrote:
> What about checking all the sqlite3_bind_* methods? Is it possible any of
> those could cause the problems I'm seeing?
>
Being busing with other issues, I have not been following this thread
closely, so perhaps I have missed something, but
What about checking all the sqlite3_bind_* methods? Is it possible any of those
could cause the problems I'm seeing?
Rick
On Jul 19, 2012, at 11:42 AM, Simon Slavin wrote:
>
> On 19 Jul 2012, at 6:03pm, Rick Maddy wrote:
>
>> Thanks. Time to add checks to nearly 400 prepare and step statem
I should know better. I've been coding in C-based languages for over 25 years.
I guess I just never thought a prepare statement needed checking. I figured
once the query worked all was good.
I already have a simple check method. I do check quite a few of the 'step'
method result values, just no
On 19 Jul 2012, at 6:03pm, Rick Maddy wrote:
> Thanks. Time to add checks to nearly 400 prepare and step statements.
Sorry about that. But you should be able to make a tiny test function which
just tests the result and makes sure it's SQLITE_OK.
You are nowhere near the only person who has h
Thanks but doesn't that code check to see if the database pointer has changed
and not whether the memory it references has been corrupted? I guess that's a
start though.
Rick
On Jul 19, 2012, at 11:02 AM, Black, Michael (IS) wrote:
> Buffer overflow issues can cause problems at seemingly ran
Thanks. Time to add checks to nearly 400 prepare and step statements.
Rick
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Maddy [rma...@gmail.com]
Sent: Thursday, July 19, 2012 11:46 AM
To: General Discussion of SQLite Database
Subject: EXT :Re: [sqlite] Getting occasional crashes with sqlite3_prepare_v2
and sqlite3_step in iOS app
Thanks. One of the users that reported one of the slqite3_prepare_v2 crashes
also sen
On 19 Jul 2012, at 5:46pm, Rick Maddy wrote:
> With regard to memory issues, I don't see how this could be the case. One of
> the places the app crashes (on rare occasions) is:
>
>sqlite3_stmt *load = nil;
>sqlite3_prepare_v2(dbRef, "SELECT some_column FROM some_table WHERE
> some_id
Thanks. One of the users that reported one of the slqite3_prepare_v2 crashes
also sent me their database. I just ran the 'pragma integrity_check' command on
the database and it reported 'ok' though there was a journal file along with
the database file. But there crash happened during a transacti
On 19 Jul 2012, at 5:09pm, Rick Maddy wrote:
> Exception Type: SIGSEGV
> Exception Codes: SEGV_ACCERR at 0x1a
Those are segfaults. They indicate an attempt by your app to access memory
which doesn't belong to it. This often but not always happens because the
memory /did/ once belong to it
> For quite some time now I've been getting reports of crashes in my iOS app.
> Specifically these are caused by crashes in sqlite3_prepare_v2 and
> sqlite_step. The associated code works fine most of the time. So I'm looking
> for thoughts on how to find and fix the problem since there seems to
15 matches
Mail list logo