Sorry for the long reply. Been busy with other things. Yeah I initialize my
sqlite3_stmt* pointer in the constructor and de-initialize it in the
destructor. BTW, here's a snippet of my program:
QueryStatement::QueryStatement(sqlite3* dbaseConn, const char* syntax):
m_SQL_syntax(""),
m_QueryStmtHandler(NULL),
m_QueryIndex(0),
m_IsRow(false),
m_IsRowDone(false),
m_IsBoundable(false),
m_IsResetable(false)
{
int result = prepare(dbaseConn, syntax); // The usual sqlite3_prepare.
Pointer is stored in: m_QueryStmtHandler.
if (result != SQLITE_OK)
{
throw result;
}
}
QueryStatement::~QueryStatement()
{
finalize(); // The usual sqlite3_finalize.
}
I don't see anything wrong with it IMHO. BTW, the error usually occurs if
I combine between sqlite3_exec and the usual sqlite3_prepare -> step ->
finalize steps in the same method. For example: I use sqlite3_exec with
"CREATE TABLE stamps (name char(100) NOT NULL, thumbName char(100),
category_id int NOT NULL, number_picked FLOAT, PRIMARY KEY( name ),
FOREIGN KEY (category_id) REFERENCES asset_category(id_asset) )" and then
initialize the items inside the table with sqlite3_prepare like this:
"INSERT INTO stamps (name, thumbName, category_id, number_picked) values
(?, ?, ?, ?)", bind the values and use a loop to insert all the items. It
usually crashes during the insertion. But if I close the db and re-opened
it again before preparing the "INSERT" statement, it worked flawlessly.
Weird.
Any idea to trace this bug? Anything would be appreciated because I don't
have a clue whatsoever. Thanks.
Pavel Ivanov wrote:
> Do you initialize your sqlite3_stmt* pointer in constructor? Is there
> any corrupting memory code in other parts of your application?
> You know, it's pretty hard to read and debug your application without
> seeing it. But believe us there's nothing wrong with SQLite and
> sqlite3MemFree(), something wrong with your application and so start
> looking from this point of view.
> You can easily debug the problem as long as you already started
> reading SQLite's code: just look what pointer causes the problem, look
> what value it has at the statement initialization, put breakpoint at
> its change and put breakpoint at sqlite3MemFree with this pointer
> value...
>
>
> Pavel
>
> On Tue, Oct 13, 2009 at 11:46 PM, <ben...@cs.its.ac.id> wrote:
>> Oh yeah, I forgot to tell you that I'm using Visual C++ 2008
>> professional
>> and it always crashes at this:
>>
>> C:\Program Files\Microsoft Visual Studio 9.0\VC\crt\src\dbgheap.c -
>> function "_free_dbg_nolock", line 1317:
>> /*
>> * If this ASSERT fails, a bad pointer has been passed in. It may
>> be
>> * totally bogus, or it may have been allocated from another
>> heap.
>> * The pointer MUST come from the 'local' heap.
>> */
>> _ASSERTE(_CrtIsValidHeapPointer(pUserData));
>>
>>
>>
>> ben...@cs.its.ac.id wrote:
>>> Well, I'm pretty sure I haven't. FYI, I wrapped the sqlite3_stmt into a
>>> class and only call its sqlite3_finalize on its destructor. So there's
>>> no
>>> way that it would be called twice. Or so I think.
>>>
>>> Pavel Ivanov wrote:
>>>>> The pPrior or p pointer isn't null so it should've been
>>>>> freed without error IMHO. Can anybody tell me what's wrong with it?
>>>>> Thanks
>>>>> a lot in advance.
>>>>
>>>> If "pPrior or p pointer" isn't null but was already freed then double
>>>> free can cause segmentation fault. In other words most probably you're
>>>> calling sqlite3_finalize on already finalized statement.
>>>>
>>>> Pavel
>>>>
>>>> On Tue, Oct 13, 2009 at 5:58 AM, <ben...@cs.its.ac.id> wrote:
>>>>> Hi there, I'm a new member of the mailing list. Nice to meet you all.
>>>>>
>>>>> BTW, I've got one problem that's been bugging me for weeks.
>>>>>
>>>>> Occasionally (not always), I got a seg fault at "static void
>>>>> sqlite3MemFree(void *pPrior)". It happened when I do sqlite3_reset or
>>>>> sqlite3_finalize. The pPrior or p pointer isn't null so it should've
>>>>> been
>>>>> freed without error IMHO. Can anybody tell me what's wrong with it?
>>>>> Thanks
>>>>> a lot in advance.
>>>>>
>>>>>
>>
>>
>> Fare thee well,
>> Bawenang R. P. P.
>>
>> ----------------
>> "If a picture is worth a thousand words, an animations is worth a
>> thousand
>> pictures. And to take that a step further, a game is worth a thousand
>> animations." Peter Raad, Executive Director, The Guildhall at SMU
>>
>>
>> --
>>
>> http://www.its.ac.id
>> _______________________________________________
>> sqlite-users mailing list
>> sqlite-users@sqlite.org
>> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>>
> _______________________________________________
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>
Fare thee well,
Bawenang R. P. P.
----------------
"If a picture is worth a thousand words, an animations is worth a thousand
pictures. And to take that a step further, a game is worth a thousand
animations." Peter Raad, Executive Director, The Guildhall at SMU
--
http://www.its.ac.id
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
