> Any idea to trace this bug? Anything would be appreciated because I don't
> have a clue whatsoever. Thanks.
To have any idea on our side we should see your code and better a
stacktrace of the crash too.
Pavel
On Sun, Oct 18, 2009 at 11:34 PM, <ben...@cs.its.ac.id> wrote:
> 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
>
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
