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
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 be no p
16 matches
Mail list logo