Re: [sqlite] Hi, new member here (and also my first question)

2009-10-19 Thread Pavel Ivanov 
> 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,   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,   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,   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
>>>
>>>
>>> --
>>>

Re: [sqlite] Hi, new member here (and also my first question)

2009-10-18 Thread benang 
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,   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,   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

Re: [sqlite] Hi, new member here (and also my first question)

2009-10-14 Thread Pavel Ivanov 
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,   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,   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

Re: [sqlite] Hi, new member here (and also my first question)

2009-10-13 Thread benang 
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,   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
>>
>>
>> --


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

Re: [sqlite] Hi, new member here (and also my first question)

2009-10-13 Thread Pavel Ivanov 
> 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,   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

[sqlite] Hi, new member here (and also my first question)

2009-10-13 Thread benang 
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