Re: [sqlite] Crash bug in sqlite

[Richard Hipp]

On 12/24/19, Yongheng Chen  wrote:
> Hi,
>
> We found a crash bug in sqlite.

Introduced yesterday afternoon by check-in
https://sqlite.org/src/info/eb95dac7f6482c36


-- 
D. Richard Hipp
d...@sqlite.org
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Crash Bug in Sqlite

[Jose Isaias Cabrera]

Yongheng Chen, on Thursday, December 19, 2019 04:29 PM, wrote...
>
> Hi,
>
> We found another crash in Sqlite. Here’s the POC:
> —
> CREATE TABLE v0 ( v1 , v2 ) ;
> SELECT 10 , 1 UNION SELECT v2 , dense_rank () OVER( ORDER BY - 10 ) FROM
> v0 ;
> —
>
> This bug exists in both the latest development code and the release code.

Indeed, sqlite v3.30.0 for Windows crashes with this set of instructions...

josé
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Crash bug in Sqlite

[Jose Isaias Cabrera]

Yongheng Chen, on Thursday, December 19, 2019 01:21 PM, wrote...
>
> Hi,
>
> We found another crash in Sqlite. Here’s the POC:
> —
> CREATE TABLE v0 ( v1 INTEGER PRIMARY KEY ) ;
> CREATE VIEW v2 ( v3 ) AS SELECT DISTINCT ( SELECT DISTINCT v1 , v1 , v1 ,
> v3 , v1 , v3 , v1 , 10.10 ) ;
> CREATE TABLE v4 ( v5 INTEGER PRIMARY KEY , v6 INT );
> DELETE FROM v0 WHERE NULL BETWEEN ( SELECT v1 FROM v0 AS x GROUP BY v1
> ORDER BY 10 + sum ( v1 ) OVER( ORDER BY - 10 ) DESC ) AND 10 ;

Entering each of those lines above, one at a time, when I hit enter after the 
last line above,
sqlite3 crashes right after.  So, I don't even need the line below.  This is 
using sqlite3
v3.30.0 in Windows.  Just an FYI.

> SELECT * FROM v4 , v2 WHERE v3 = v3 AND v3 = 10;
> —
>
> This bug exists in both the latest development code and the release code.
> (And thanks josé for the confirmation every time we report a bug).

You're welcome.  I have SQlite3 tool opened, so it's a "nice copy and paste" 
and see your
replication text/steps go to work. ;-)

josé
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Crash bug in Sqlite

[Jose Isaias Cabrera]

Yongheng Chen, on Thursday, December 19, 2019 09:54 AM, wrote...
>
> Hi,
>
> We found another crash in Sqlite. Here’s the POC:
> —
> CREATE TABLE v0 ( v7 FLOAT , v3 DOUBLE , v6 TEXT , v1 INTEGER UNIQUE , v5
> DOUBLE , v2 VARCHAR(20) UNIQUE , v4 ) ;
> REPLACE INTO v0 ( v6 , v3 , v2 ) VALUES ( 10 , 10 , 10 );
> CREATE VIRTUAL TABLE v8 USING zipfile ( v9 DOUBLE ) ;
> REPLACE INTO v8 SELECT * FROM v0;
> —
>
> This bug exists in both the latest development code and the release code.

Crash confirmed in Windows Sqlite3 v3.30.0. Just fyi...

josé
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Crash bug in Sqlite

[Jose Isaias Cabrera]

Yongheng Chen, on Wednesday, December 18, 2019 10:45 AM, wrote...
>
> Hi,
>
> We found another crash in Sqlite. Here’s the POC:
>
> —
> CREATE TABLE v0 ( v2 INTEGER UNIQUE ON CONFLICT IGNORE , v1 TEXT PRIMARY
> KEY ) ;
> CREATE VIEW v3 ( v4 ) AS SELECT v2 IN ( 9223372036854775808 , ( printf ()
> IN ( 0 , 0 ) ) , 10 , 10 , 10 ) AS AVG_YEARLY FROM v0 ;
> CREATE TABLE v5 ( v6 , v7 ) ; INSERT INTO v0 VALUES ( 1.10 , 'y' ) ;
> INSERT INTO v5 VALUES ( 10 , 10 ) ;
> INSERT INTO v0 VALUES ( 10 , 10 ) ;
> SELECT DISTINCT v4 FROM v0 LEFT JOIN v3 ON v4 = 10 OR v4 = v3 . v4 ORDER
> BY v4 ;
> —
>
> This bug exists in both the latest development code and the release code.

Yep, took down sqlite3.exe with 3.30.0.  Just fyi.

josé
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Crash Bug in Sqlite

[Yongheng Chen]

It’s Yongheng & Rui. Sorry for the typo.

> On Dec 17, 2019, at 4:58 PM, Jose Isaias Cabrera  wrote:
> 
> 
> Yongheng Chen, on Tuesday, December 17, 2019 04:21 PM, wrote...
>> 
>> Hi,
>> 
>> We found a bug that crashes Sqlite. Here’s the test case:
>> 
>> ——
>> CREATE TABLE v0 ( v1 UNIQUE , v2 VARCHAR(80) NULL PRIMARY KEY ) ;
>> CREATE VIEW v3 ( v4 ) AS SELECT max ( ( SELECT count ( v1 ) OVER( ORDER
>> BY 10 ASC ) ) ) FROM v0 ;
>> SELECT * FROM v3 WHERE - 'b' >= v4 AND v4 > 10 OR ( v4 BETWEEN 10 AND 10
>> );
>> ——
>> 
>> This bug exists in both the development code and the latest release code.
> 
> Yep, 3.30.0 has the problem.
> 
> josé
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org 
> 
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users 
> 
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Crash Bug in Sqlite

[Yongheng Chen]

We just took a look at the bug. The value of the accessed address in the crash 
point can be controlled by the value in the second line of the test input, 
which means:

——
…….
CREATE VIEW v3 ( v4 ) AS SELECT max ( ( SELECT count ( v1 ) OVER( ORDER BY 1234 
ASC ) ) ) FROM v0 ; 
….. 
—— — 

Then address 1234 will be accessed. We think this has the potential of 
achieving RCE.

Yongheng & Chen


> On Dec 17, 2019, at 4:58 PM, Jose Isaias Cabrera  wrote:
> 
> 
> Yongheng Chen, on Tuesday, December 17, 2019 04:21 PM, wrote...
>> 
>> Hi,
>> 
>> We found a bug that crashes Sqlite. Here’s the test case:
>> 
>> ——
>> CREATE TABLE v0 ( v1 UNIQUE , v2 VARCHAR(80) NULL PRIMARY KEY ) ;
>> CREATE VIEW v3 ( v4 ) AS SELECT max ( ( SELECT count ( v1 ) OVER( ORDER
>> BY 10 ASC ) ) ) FROM v0 ;
>> SELECT * FROM v3 WHERE - 'b' >= v4 AND v4 > 10 OR ( v4 BETWEEN 10 AND 10
>> );
>> ——
>> 
>> This bug exists in both the development code and the latest release code.
> 
> Yep, 3.30.0 has the problem.
> 
> josé
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org 
> 
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users 
> 
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Crash Bug in Sqlite

[Jose Isaias Cabrera]

Yongheng Chen, on Tuesday, December 17, 2019 04:21 PM, wrote...
>
> Hi,
>
> We found a bug that crashes Sqlite. Here’s the test case:
>
> ——
> CREATE TABLE v0 ( v1 UNIQUE , v2 VARCHAR(80) NULL PRIMARY KEY ) ;
> CREATE VIEW v3 ( v4 ) AS SELECT max ( ( SELECT count ( v1 ) OVER( ORDER
> BY 10 ASC ) ) ) FROM v0 ;
> SELECT * FROM v3 WHERE - 'b' >= v4 AND v4 > 10 OR ( v4 BETWEEN 10 AND 10
> );
> ——
>
> This bug exists in both the development code and the latest release code.

Yep, 3.30.0 has the problem.

josé
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Crash Bug Report

[Yongheng Chen]

Thanks for the fix.

> On Dec 9, 2019, at 9:43 AM, Richard Hipp  wrote:
> 
> On 12/8/19, Yongheng Chen  wrote:
>> 
>> We found one crash bug in sqlite,
> 
> Simplified test case:
> 
> CREATE TABLE t1(a);
> CREATE VIEW v2(b) AS WITH t3 AS (SELECT b FROM v2) VALUES(1);
> ALTER TABLE t1 RENAME TO t4;
> 
> Notice how the definition of the V2 view refers to itself.  The ALTER
> TABLE command was failing to detect this circular reference in the
> view definition.  This caused an infinite recursion of attempts to
> resolve the definition of V2, ultimately resulting in a stack
> overflow, which on some systems manifests as a segfault.  Dan checked
> in a fix earlier today.
> 
> -- 
> D. Richard Hipp
> d...@sqlite.org
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Crash Bug Report

[Richard Hipp]

On 12/8/19, Yongheng Chen  wrote:
>
> We found one crash bug in sqlite,

Simplified test case:

CREATE TABLE t1(a);
CREATE VIEW v2(b) AS WITH t3 AS (SELECT b FROM v2) VALUES(1);
ALTER TABLE t1 RENAME TO t4;

Notice how the definition of the V2 view refers to itself.  The ALTER
TABLE command was failing to detect this circular reference in the
view definition.  This caused an infinite recursion of attempts to
resolve the definition of V2, ultimately resulting in a stack
overflow, which on some systems manifests as a segfault.  Dan checked
in a fix earlier today.

-- 
D. Richard Hipp
d...@sqlite.org
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Crash Bug Report

[D Burgess]

3.30.1 x86_64 Linux

Same problem here.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Crash Bug Report

[Tim Streater]

On 08 Dec 2019, at 21:55, Simon Slavin  wrote:

> On 8 Dec 2019, at 7:51pm, Yongheng Chen  wrote:
>
>> The bug exists in "SQLite version 3.31.0 2019-12-08 00:06:39” and before.
>
> SQLite version 3.28.0 2019-04-15 14:49:49
> Enter ".help" for usage hints.
> Connected to a transient in-memory database.
> Use ".open FILENAME" to reopen on a persistent database.
> sqlite> CREATE TABLE v0 ( v1 ) ;
> sqlite> CREATE TABLE v2 ( v3 ) ;
> sqlite> CREATE VIEW v4 AS WITH x AS ( SELECT x () OVER( ) FROM v4 ) SELECT v3
> AS x FROM v2 ;
> sqlite> DROP TRIGGER IF EXISTS x ;
> sqlite> ALTER TABLE v2 RENAME TO t3;
> sqlite>
>
> Not a problem for this version.

macOS 10.14.6:

Third-Mini% sqlite3
-- Loading resources from /Users/tim/.sqliterc
SQLite version 3.28.0 2019-04-16 19:49:53
Enter ".help" for usage hints.
Connected to a transient in-memory database.
Use ".open FILENAME" to reopen on a persistent database.
sqlite> CREATE TABLE v0 ( v1 ) ;
sqlite> CREATE TABLE v2 ( v3 ) ;
sqlite> CREATE VIEW v4 AS WITH x AS ( SELECT x () OVER( ) FROM v4 ) SELECT v3 
AS x FROM v2 ;
sqlite> DROP TRIGGER IF EXISTS x ;
sqlite> ALTER TABLE v2 RENAME TO t3;
zsh: segmentation fault sqlite3
Third-Mini% 

My .sqliterc has:

Third-Mini% more .sqliterc 
.mode column
.width 0
.headers on



-- 
Cheers  --  Tim
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Crash Bug Report

[Simon Slavin]

simon@178 sqlite-tools-osx-x86-3300100 % ./sqlite3
SQLite version 3.30.1 2019-10-10 20:19:45
Enter ".help" for usage hints.
Connected to a transient in-memory database.
Use ".open FILENAME" to reopen on a persistent database.
sqlite> CREATE TABLE v0 ( v1 ) ; 
sqlite> CREATE TABLE v2 ( v3 ) ; 
sqlite> CREATE VIEW v4 AS WITH x AS ( SELECT x () OVER( ) FROM v4 ) SELECT v3 
AS x FROM v2 ;
sqlite> DROP TRIGGER IF EXISTS x ; 
sqlite> ALTER TABLE v2 RENAME TO t3; 
zsh: segmentation fault  ./sqlite3
simon@178 sqlite-tools-osx-x86-3300100 % 

In the current version of SQLite, I obtain a segmentation fault under recent 
version of macOS.  Same OS had no problem when running

SQLite version 3.28.0 2019-04-15 14:49:49

So the problem crept in sometime between 3.28.0 and 3.30.1.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Crash Bug Report

[Jose Isaias Cabrera]

Yongheng Chen, on Sunday, December 8, 2019 02:51 PM, wrote...
>
> Hi,
>
> We found one crash bug in sqlite, which causes a dead loop and then OOM.
> 
> CREATE TABLE v0 ( v1 ) ;
> CREATE TABLE v2 ( v3 ) ;
> CREATE VIEW v4 AS WITH x AS ( SELECT x () OVER( ) FROM v4 ) SELECT v3 AS x 
> FROM v2 ;
> DROP TRIGGER IF EXISTS x ;
> ALTER TABLE v2 RENAME TO t3;
> 
> The bug exists in "SQLite version 3.31.0 2019-12-08 00:06:39” and before.
>
> We reported this bug to one of the developers but didn’t get response. And we 
> reported
> several bugs to the same person one-to-one before (which was required by him) 
> and the
> bugs got fixed but we never got any credits for them. We hope somebody else 
> can help
> us. Thanks.

This definitely crashes in Windows 10:

17:21:58.01>sqlite3
SQLite version 3.30.1 2019-10-10 20:19:45
Enter ".help" for usage hints.
Connected to a transient in-memory database.
Use ".open FILENAME" to reopen on a persistent database.
sqlite> CREATE TABLE v0 ( v1 ) ;
sqlite> CREATE TABLE v2 ( v3 ) ;
sqlite> CREATE VIEW v4 AS WITH x AS ( SELECT x () OVER( ) FROM v4 ) SELECT v3 
AS x FROM v2 ;
sqlite> DROP TRIGGER IF EXISTS x ;
sqlite> ALTER TABLE v2 RENAME TO t3;

17:23:08.57>

Just fyi. thanks.

josé

___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Crash Bug Report

[Yongheng Chen]

I haven’t tested many versions. But the most up-to-date master branch and the 
release version has this bug.


> On Dec 8, 2019, at 4:55 PM, Simon Slavin  wrote:
> 
> On 8 Dec 2019, at 7:51pm, Yongheng Chen  wrote:
> 
>> The bug exists in "SQLite version 3.31.0 2019-12-08 00:06:39” and before.
> 
> SQLite version 3.28.0 2019-04-15 14:49:49
> Enter ".help" for usage hints.
> Connected to a transient in-memory database.
> Use ".open FILENAME" to reopen on a persistent database.
> sqlite> CREATE TABLE v0 ( v1 ) ; 
> sqlite> CREATE TABLE v2 ( v3 ) ; 
> sqlite> CREATE VIEW v4 AS WITH x AS ( SELECT x () OVER( ) FROM v4 ) SELECT v3 
> AS x FROM v2 ;
> sqlite> DROP TRIGGER IF EXISTS x ; 
> sqlite> ALTER TABLE v2 RENAME TO t3; 
> sqlite> 
> 
> Not a problem for this version.
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Crash Bug Report

[Simon Slavin]

On 8 Dec 2019, at 7:51pm, Yongheng Chen  wrote:

> The bug exists in "SQLite version 3.31.0 2019-12-08 00:06:39” and before.

SQLite version 3.28.0 2019-04-15 14:49:49
Enter ".help" for usage hints.
Connected to a transient in-memory database.
Use ".open FILENAME" to reopen on a persistent database.
sqlite> CREATE TABLE v0 ( v1 ) ; 
sqlite> CREATE TABLE v2 ( v3 ) ; 
sqlite> CREATE VIEW v4 AS WITH x AS ( SELECT x () OVER( ) FROM v4 ) SELECT v3 
AS x FROM v2 ;
sqlite> DROP TRIGGER IF EXISTS x ; 
sqlite> ALTER TABLE v2 RENAME TO t3; 
sqlite> 

Not a problem for this version.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] crash at sqlite3DbMallocRawNN

[HA Thi Tham]

Hi Richard,

Thanks for the tips.
I'll base on that to investigate on my app.

Regards, Tham

On Tue, Aug 20, 2019 at 8:18 PM Richard Hipp  wrote:

> Faults in the memory allocation routines of SQLite are almost always
> due to heap corruption caused by other unrelated parts of the
> application.  In other words, some other part of the application is
> misusing the memory heap, and SQLite merely has the misfortune of
> being the first innocent party to stumble over the damage.
>
> I recommend you run your application using Valgrind.  Or, recompile
> using -fsanitize=memory.  That will likely pinpoint the source of the
> trouble.
>
> On 8/20/19, HA Thi Tham  wrote:
> > Hi,
> >
> > I have a crash at sqlite when reading a row in database (detailed
> > stacktrace in the attachment). It happens rarely in our customer machine.
> > We cannot reproduce it.
> >
> > Can you please give some suggestions when this can happen and maybe how
> to
> > fix it.
> >
> > FAULTING_SOURCE_LINE:
> >
> c:\jenkins\workspace\cortexv2-dev-win64-service-release\src\thirdparty\couchbase-lite-core-ee\encryption\see-sqlite.c
> >
> > FAULTING_SOURCE_FILE:
> >
> c:\jenkins\workspace\cortexv2-dev-win64-service-release\src\thirdparty\couchbase-lite-core-ee\encryption\see-sqlite.c
> >
> > FAULTING_SOURCE_CODE:
> >  27014:   p = sqlite3Malloc(n);
> >  27015:   sqlite3MemdebugSetType(p, MEMTYPE_HEAP);
> >  27016:   return p;
> >  27017: }
> >>27018: SQLITE_PRIVATE void *sqlite3DbMallocRawNN(sqlite3 *db, u64 n){
> >  27019: #ifndef SQLITE_OMIT_LOOKASIDE
> >  27020:   LookasideSlot *pBuf;
> >  27021:   assert( db!=0 );
> >  27022:   assert( sqlite3_mutex_held(db->mutex) );
> >  27023:   assert( db->pnBytesFreed==0 );
> >
> >
> > Thanks in advance!
> >
> > Tham
> >
>
>
> --
> D. Richard Hipp
> d...@sqlite.org
>
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] crash at sqlite3DbMallocRawNN

[Richard Hipp]

Faults in the memory allocation routines of SQLite are almost always
due to heap corruption caused by other unrelated parts of the
application.  In other words, some other part of the application is
misusing the memory heap, and SQLite merely has the misfortune of
being the first innocent party to stumble over the damage.

I recommend you run your application using Valgrind.  Or, recompile
using -fsanitize=memory.  That will likely pinpoint the source of the
trouble.

On 8/20/19, HA Thi Tham  wrote:
> Hi,
>
> I have a crash at sqlite when reading a row in database (detailed
> stacktrace in the attachment). It happens rarely in our customer machine.
> We cannot reproduce it.
>
> Can you please give some suggestions when this can happen and maybe how to
> fix it.
>
> FAULTING_SOURCE_LINE:
> c:\jenkins\workspace\cortexv2-dev-win64-service-release\src\thirdparty\couchbase-lite-core-ee\encryption\see-sqlite.c
>
> FAULTING_SOURCE_FILE:
> c:\jenkins\workspace\cortexv2-dev-win64-service-release\src\thirdparty\couchbase-lite-core-ee\encryption\see-sqlite.c
>
> FAULTING_SOURCE_CODE:
>  27014:   p = sqlite3Malloc(n);
>  27015:   sqlite3MemdebugSetType(p, MEMTYPE_HEAP);
>  27016:   return p;
>  27017: }
>>27018: SQLITE_PRIVATE void *sqlite3DbMallocRawNN(sqlite3 *db, u64 n){
>  27019: #ifndef SQLITE_OMIT_LOOKASIDE
>  27020:   LookasideSlot *pBuf;
>  27021:   assert( db!=0 );
>  27022:   assert( sqlite3_mutex_held(db->mutex) );
>  27023:   assert( db->pnBytesFreed==0 );
>
>
> Thanks in advance!
>
> Tham
>


-- 
D. Richard Hipp
d...@sqlite.org
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Crash in sqlite3fts5BufferAppendBlob

[bhandari_nikhil]

Please help as to what parameters could have gone wrong when I see the crash
here:

#0  sqlite3Fts5BufferAppendBlob (pRc=pRc@entry=0xf54139c8,
pBuf=pBuf@entry=0xf5afeb90, nData=*4294967295*, pData=0xf49fff76
"90246ture") at sqlite3.c:180474

#1  0xf717b6f8 in fts5WriteAppendTerm (p=p@entry=0xf54139a8,
pWriter=pWriter@entry=0xf5afeb84, nTerm=5, pTerm=0xf49fff70
"06280290246ture") at sqlite3.c:188868

The nData became negative and a big value because it is u32. I t became
negative in frame #1 which did nTerm - nPrefix, nTerm =5 and nPrefix turned
out to be 6. Can anyone help as to how this can happen and what this means ?



--
Sent from: http://sqlite.1065341.n5.nabble.com/
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Crash observation in certain conditions (SQLite v.3.25.2)

[Vlad Khokholkov]

I tried to make the issue more detailed (as you asked me in the beginning).
Each attached file is referenced in the letter.

Regards,
Vladimir.

сб, 29 сент. 2018 г. в 23:37, Richard Hipp :

> On 9/29/18, Vlad Khokholkov  wrote:
> > Yes, you are right that is a link to compiler.
> > Please, see source code in the attached to prior letter file
> > (SQLiteDebug.zip).
> > Do you see attached files?
>
> Yes, thank you.  I now see the source code buried amongst the other
> attachments.
>
> --
> D. Richard Hipp
> d...@sqlite.org
>
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Crash observation in certain conditions (SQLite v.3.25.2)

[Vlad Khokholkov]

Yes, you are right that is a link to compiler.
Please, see source code in the attached to prior letter file
(SQLiteDebug.zip).
Do you see attached files?

Regards,
Vladimir.

сб, 29 сент. 2018 г. в 23:09, Richard Hipp :

> On 9/29/18, Vlad Khokholkov  wrote:
> >   a) Download already fetched compiler files and library from the link:
> > https://jmp.sh/v/bYhfdyV4ombZcWXVs98Z  (Please, download it in next 23
> > hours, otherwise link will be invalidated and I need to re-share it)
>
> That ZIP archive does not contain any source code.  It is all LIB, and
> EXE, and DLL.
>
> I need the source code to the program that is failing, please.
> --
> D. Richard Hipp
> d...@sqlite.org
>
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Crash observation in certain conditions (SQLite v.3.25.2)

[Vlad Khokholkov]

Good day!

To answer your questions I prepare a simple test example where I can
reproduce the crash (see file 'SQLiteDebug.zip').
The results of its execution please see in files ('SQLite_expected1.png',
'SQLite_expected2.png', 'SQLite_expected3.png', 'SQLite_unexpected.png') -
crash is in 'SQLite_unexpected.png' with an error 'Access violation'.

To get and install (if needed) the MS compiler of 13xxx version, you can:
* Either: get it (compiler files and library) form "Windows XP Driver
Development Kit (DDK)  2600" (sorry, I use so old compiler, it is just to
support my old projects)
* Or:
  a) Download already fetched compiler files and library from the link:
https://jmp.sh/v/bYhfdyV4ombZcWXVs98Z  (Please, download it in next 23
hours, otherwise link will be invalidated and I need to re-share it)
  b) Copy it into VC6 folder (see file 'Copy_13xx_compiler_here.png')
  c.1) To set 13xxx compiler active, see configuration as
'Set_13xxx_compiler.png'
  c.2) To set 12xxx (native VC6) compiler active, see configuration as
'Set_12xxx_compiler.png'

Thanks a lot for your efforts!

PS. I am sorry if I am asking you to spend your time by checking the SQLite
on so old compiler (it might be compiler issue).

Regards,
Vladimir.


сб, 29 сент. 2018 г. в 18:07, Simon Slavin :

>
>
> On 29 Sep 2018, at 1:53am, Vlad Khokholkov  wrote:
>
> > Unfortunately, today I download the latest version of SQLite (3.25.2) and
> > got crash on the first 'sqlite3_prepare_v2' call.
>
> Thank you for posting.  Can you tell us
>
> 1) What the crash error message is.
> 2) What statement you are passing to sqlite3_prepare().
> 3) Whether you have checked the result codes of all previous calls to the
> SQLite API to make sure they are returning SQLITE_OK .
>
> Simon.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Crash observation in certain conditions (SQLite v.3.25.2)

[Richard Hipp]

On 9/29/18, Vlad Khokholkov  wrote:
> Yes, you are right that is a link to compiler.
> Please, see source code in the attached to prior letter file
> (SQLiteDebug.zip).
> Do you see attached files?

Yes, thank you.  I now see the source code buried amongst the other attachments.

-- 
D. Richard Hipp
d...@sqlite.org
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Crash observation in certain conditions (SQLite v.3.25.2)

[Richard Hipp]

On 9/29/18, Vlad Khokholkov  wrote:
>   a) Download already fetched compiler files and library from the link:
> https://jmp.sh/v/bYhfdyV4ombZcWXVs98Z  (Please, download it in next 23
> hours, otherwise link will be invalidated and I need to re-share it)

That ZIP archive does not contain any source code.  It is all LIB, and
EXE, and DLL.

I need the source code to the program that is failing, please.
-- 
D. Richard Hipp
d...@sqlite.org
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Crash observation in certain conditions (SQLite v.3.25.2)

[Simon Slavin]

On 29 Sep 2018, at 1:53am, Vlad Khokholkov  wrote:

> Unfortunately, today I download the latest version of SQLite (3.25.2) and
> got crash on the first 'sqlite3_prepare_v2' call.

Thank you for posting.  Can you tell us

1) What the crash error message is.
2) What statement you are passing to sqlite3_prepare().
3) Whether you have checked the result codes of all previous calls to the 
SQLite API to make sure they are returning SQLITE_OK .

Simon.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Crash observation in certain conditions (SQLite v.3.25.2)

[Richard Hipp]

Please send additional information.  We are unable to reproduce or fix
the problem without further data.

On 9/28/18, Vlad Khokholkov  wrote:
> Good day!
>
> First of all thanks a lot for this really nice project!
> I use it in different projects (including the projects where the DB file is
>> 120 Gb), it works perfectly!!!
>
> Unfortunately, today I download the latest version of SQLite (3.25.2) and
> got crash on the first 'sqlite3_prepare_v2' call.
>
> Execution environment: Win32 XP.
> Compilers:
> "CL-12":
> Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 12.00.8804 for 80x86
> Copyright (C) Microsoft Corp 1984-1998. All rights reserved.
>
> "CL-13":
> Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.00.9176 for 80x86
> Copyright (C) Microsoft Corporation 1984-2001. All rights reserved.
>
> My small observations:
> * CL-12 + SQLite v3.24.0 (RELEASE) - work
> * CL-12 + SQLite v3.25.2 (RELEASE) - work
> * CL-13 + SQLite v3.24.0 (RELEASE) - work
> * CL-13 + SQLite v3.25.2 (RELEASE) - crash.
>
> It is ok for me to work on 3.24.0 version (I do not use latest features in
> this it this project), but I just want to help you make SQLIte better!
>
> PS. Sorry if I send so few information about the crash. But if you decide
> to check/investigate this case - just write me I will try to prepare more
> details about the issue.
>
> Once again, thanks alot for your efforts in creating so amazing System!
>
> Regards,
> Vladimir.
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>


-- 
D. Richard Hipp
d...@sqlite.org
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] crash dropping table

[Simon Slavin]

On 18 Apr 2018, at 5:59pm, Mark Wagner  wrote:

> I will try to produce a repro case that I can share out (the database I was
> testing on has lots of personal data that I will first try to delete).

Before you do anything else to it, make a copy and use the SQLite shell to do

PRAGMA integrity_check();

on it.  Just in case the reason for the crash is that the database is corrupt.

Simon.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] crash dropping table

[Mark Wagner]

I will try to produce a repro case that I can share out (the database I was
testing on has lots of personal data that I will first try to delete).
Thanks for the responses.

@David Note that those weren't the precise commands (i.e. drop command was
"drop table x;").



On Wed, Apr 18, 2018 at 9:56 AM Simon Slavin  wrote:

> On 18 Apr 2018, at 4:47pm, Mark Wagner  wrote:
>
> > I have a simple test case wherein I delete from a number of tables and
> then
> > drop one of those tables.  This crashes sqlite3.
> >
> > So something like this:
> >
> > begin;
> > delete from x;
> > delete from y;
> > delete from z;
> > drop x;  << crashes here
> >
> > Sorry for my ignorance but is there a procedure for submitting bugs for
> > things like this?
>
> Can you make the same problem happen in the SQLite CLI tool ?  If so,
> please post a full script here.  If not, there's a possibility that the
> problem is somewhere in your own software.
>
> If it's in your software, are you checking the return values from the
> first four commands in your list ?
>
> Simon.
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] crash dropping table

[Simon Slavin]

On 18 Apr 2018, at 4:47pm, Mark Wagner  wrote:

> I have a simple test case wherein I delete from a number of tables and then
> drop one of those tables.  This crashes sqlite3.
> 
> So something like this:
> 
> begin;
> delete from x;
> delete from y;
> delete from z;
> drop x;  << crashes here
> 
> Sorry for my ignorance but is there a procedure for submitting bugs for
> things like this?

Can you make the same problem happen in the SQLite CLI tool ?  If so, please 
post a full script here.  If not, there's a possibility that the problem is 
somewhere in your own software.

If it's in your software, are you checking the return values from the first 
four commands in your list ?

Simon.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] crash dropping table

[David Raymond]

The more specific info the better.

Can you reproduce it with a new database or does it only happen on one specific 
database?

What're the schemas of x, y and z?

Are those the exact commands you're giving it?
(For example: "drop x;" should give you a syntax error, but not crash)

What journal mode is the database using?

Etc...


-Original Message-
From: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] On 
Behalf Of Mark Wagner
Sent: Wednesday, April 18, 2018 11:48 AM
To: SQLite mailing list
Subject: [sqlite] crash dropping table

I have a simple test case wherein I delete from a number of tables and then
drop one of those tables.  This crashes sqlite3.

So something like this:

begin;
delete from x;
delete from y;
delete from z;
drop x;  << crashes here

Sorry for my ignorance but is there a procedure for submitting bugs for
things like this?

SQLite 3.22.0 2018-01-22 18:45:57
0c55d179733b46d8d0ba4d88e01a25e10677046ee3da1d5b1581e86726f2alt1
zlib version 1.2.8
gcc-7.3.0
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] crash dropping table

[Richard Hipp]

On 4/18/18, Mark Wagner  wrote:
> I have a simple test case wherein I delete from a number of tables and then
> drop one of those tables.  This crashes sqlite3.
>
> So something like this:
>
> begin;
> delete from x;
> delete from y;
> delete from z;
> drop x;  << crashes here

Can you send in a reproducible test case?

-- 
D. Richard Hipp
d...@sqlite.org
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] crash dropping table

[Kees Nuyt]

On Wed, 18 Apr 2018 15:47:47 +, Mark Wagner 
wrote:

> Sorry for my ignorance but is there a procedure for
> submitting bugs for things like this?

The procedure is to mail bugs to this mailing list, including
version info, so you did exactly the right thing.

-- 
Regards,
Kees Nuyt
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Crash when writing header

[Richard Hipp]

On 2/13/18, Chris Brody  wrote:
> I was wondering what would happen if there would be an application crash,
> system crash, or power failure while SQLite is updating the file header?
>
> Did I miss an explanation somewhere?

The content is replicated either in the rollback-journal or in the
write-head log (depending on whether or not you are in WAL mode) and
will be recovered automatically when the database is first opened
after power has been restored.  See
https://www.sqlite.org/atomiccommit.html for further information.
-- 
D. Richard Hipp
d...@sqlite.org
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Crash in libsqlite3 with sqlite-3.21.0 and KDE plasmashell

[Leonard Lausen]

Thanks for your prompt reply Richard. With this information I will go
back to the KDE developers and let you know once/if there is further and
detailed evidence for sqlites fault.

Best regards
Leonard

Richard Hipp  writes:

> On 1/19/18, Leonard Lausen  wrote:
>>
>> A crash in sqlite crashes plasmashell. Downstream bug
>> https://bugs.kde.org/show_bug.cgi?id=388140. Please find the backtrace
>> below:
>>
>
> (1) These kinds of things are almost always the result of heap
> corruption in the application.  In other words, there is nothing wrong
> with SQLite.  SQLite just happened to be the unlucky victim to first
> stumble over the corrupted heap.  In fact, we find that whenever there
> is heap corruption of any sort, SQLite is more likely that most other
> libraries to be the first to stumble into it.
>
> (2) You have provided us very little to go on:  There is no version
> number on the SQLite library, no information on the platform on which
> the application is running, no line-number information on the stack
> trace, and no reproducible test case.
>
> (3) Given the above, we will take no action on this.
>
> (4) We will reconsider (3) if you can provide a scintilla of evidence
> that SQLite is at fault.
>
> -- 
> D. Richard Hipp
> d...@sqlite.org

-- 
Leonard Lausen
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Crash in libsqlite3 with sqlite-3.21.0 and KDE plasmashell

[Richard Hipp]

On 1/19/18, Leonard Lausen  wrote:
>
> A crash in sqlite crashes plasmashell. Downstream bug
> https://bugs.kde.org/show_bug.cgi?id=388140. Please find the backtrace
> below:
>

(1) These kinds of things are almost always the result of heap
corruption in the application.  In other words, there is nothing wrong
with SQLite.  SQLite just happened to be the unlucky victim to first
stumble over the corrupted heap.  In fact, we find that whenever there
is heap corruption of any sort, SQLite is more likely that most other
libraries to be the first to stumble into it.

(2) You have provided us very little to go on:  There is no version
number on the SQLite library, no information on the platform on which
the application is running, no line-number information on the stack
trace, and no reproducible test case.

(3) Given the above, we will take no action on this.

(4) We will reconsider (3) if you can provide a scintilla of evidence
that SQLite is at fault.

-- 
D. Richard Hipp
d...@sqlite.org
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Crash when querying a unique index containing 12 columns using sub-selects

[Matthew Towler]

Hi

> I think it is now back to Matthew to come up with a new test case that 
> actually demonstrates his problem.

I believe I stated in my earlier message that the example test code did not 
show the issue - apologies that you spent time re-proving this.

What would really help me to achieve a failing test case is if someone could 
please look at the query plans I provided and give me some vague pointers as to 
what kind of changes to the data in the tables might cause the difference 
between the failing and passing query plans for version 1.17.0 (near the bottom 
of the last message).  This might enable me to adjust the data generation in 
the example application to give a failing result.

Thanks

Matthew
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Crash when querying a unique index containing 12 columns using sub-selects

[Richard Hipp]

On 1/16/18, Dominique Devienne  wrote:
> You're not compiling in C++11 mode, are you?
> Probably use -std=c++11 or perhaps -std=gnu++11 on your g++ command line.

Did that.  It compiles now.  But it also just works.  There is no
slowdown.  Everything is very fast, regardless of which SQLite version
I use.  I added a line:

   std::cout << "SQLite version: " << sqlite3_libversion() << " "
<< sqlite3_sourceid() << std::endl;

Just to verify that I was testing against the particular versions of
SQLite that allegedly do not work.

I think it is now back to Matthew to come up with a new test case that
actually demonstrates his problem.
-- 
D. Richard Hipp
d...@sqlite.org
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Crash when querying a unique index containing 12 columns using sub-selects

[Dominique Devienne]

On Tue, Jan 16, 2018 at 4:10 PM, Richard Hipp  wrote:

> On 1/16/18, Matthew Towler  wrote:
> >
> > Firstly, here is a C++11 example application.
>
> Does not compile.  These are the errors:
>
> x2.cpp:53:2: warning: missing terminating " character
>  R"(SELECT AbundanceId FROM[ABUNDANCE]
>   ^
> ...

x2.cpp:7:2: error: in C++98 ‘query_texts’ must be initialized by
> constructor, not by ‘{...}’
>

You're not compiling in C++11 mode, are you?
Probably use -std=c++11 or perhaps -std=gnu++11 on your g++ command line.
--DD
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Crash when querying a unique index containing 12 columns using sub-selects

[Richard Hipp]

On 1/16/18, Matthew Towler  wrote:
>
> Firstly, here is a C++11 example application.

Does not compile.  These are the errors:

x2.cpp:53:2: warning: missing terminating " character
 R"(SELECT AbundanceId FROM[ABUNDANCE]
  ^
x2.cpp:53:1: error: missing terminating " character
 R"(SELECT AbundanceId FROM[ABUNDANCE]
 ^
x2.cpp:128:6: warning: missing terminating " character
 )";
  ^
x2.cpp:128:5: error: missing terminating " character
 )";
 ^
x2.cpp:246:38: warning: missing terminating " character
 std::string main_table_insert = R"(INSERT INTO
ABUNDANCE(AbundanceId0, AbundanceId1, AbundanceId2, AbundanceId3,
AbundanceId4, AbundanceId5, AbundanceId6, AbundanceId7, AbundanceId8,
SetAbundanceId0, SetAbundanceId1, SetAbundanceId2)
  ^
x2.cpp:246:5: error: missing terminating " character
 std::string main_table_insert = R"(INSERT INTO
ABUNDANCE(AbundanceId0, AbundanceId1, AbundanceId2, AbundanceId3,
AbundanceId4, AbundanceId5, AbundanceId6, AbundanceId7, AbundanceId8,
SetAbundanceId0, SetAbundanceId1, SetAbundanceId2)
 ^
x2.cpp:247:72: warning: missing terminating " character
   VALUES(?,?,?,?,?,?,?,?,?,?,?,?) )";
^
x2.cpp:247:39: error: missing terminating " character
   VALUES(?,?,?,?,?,?,?,?,?,?,?,?) )";
   ^
x2.cpp:7:1: error: ‘R’ was not declared in this scope
 R"(CREATE TABLE ABUNDANCE(AbundanceId INTEGER PRIMARY KEY NOT NULL,
AbundanceId0 INTEGER, AbundanceId1 INTEGER, AbundanceId2 INTEGER,
AbundanceId3 INTEGER, AbundanceId4 INTEGER, AbundanceId5 INTEGER,
AbundanceId6 INTEGER, AbundanceId7 INTEGER, AbundanceId8 INTEGER,
SetAbundanceId0 INTEGER, SetAbundanceId1 INTEGER, SetAbundanceId2
INTEGER))",
 ^
x2.cpp:7:2: error: expected ‘}’ before string constant
 R"(CREATE TABLE ABUNDANCE(AbundanceId INTEGER PRIMARY KEY NOT NULL,
AbundanceId0 INTEGER, AbundanceId1 INTEGER, AbundanceId2 INTEGER,
AbundanceId3 INTEGER, AbundanceId4 INTEGER, AbundanceId5 INTEGER,
AbundanceId6 INTEGER, AbundanceId7 INTEGER, AbundanceId8 INTEGER,
SetAbundanceId0 INTEGER, SetAbundanceId1 INTEGER, SetAbundanceId2
INTEGER))",
  ^
x2.cpp:7:2: error: in C++98 ‘query_texts’ must be initialized by
constructor, not by ‘{...}’
x2.cpp:7:2: error: could not convert ‘{}’ from
‘’ to ‘const
std::vector >’
x2.cpp:7:2: error: expected ‘,’ or ‘;’ before string constant
x2.cpp:50:1: error: expected declaration before ‘}’ token
 };
 ^

-- 
D. Richard Hipp
d...@sqlite.org
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Crash when querying a unique index containing 12 columns using sub-selects

[Matthew Towler]

Hello again,

Thanks for the responses, here is some additional information.

> Is it hanging, or is it crashing?  Your statement of the problem is unclear 
> on this point.
It depends on the version. 3.8.0 gives an access violation (a crash) the other 
versions I have tried hang, in that the call to step "never" returns, where 
"never" means "takes longer than an hour".

As requested I have generated some explain plans, and I have had a go at making 
a stand-alone example program but it does not show the problem - I suspect 
because the distribution of data values is different and results in a different 
plan (I do have evidence for this view).  Read on for the details...

Firstly, here is a C++11 example application.  This works perfectly with 3.6.16 
and 3.17.0.  note I had to change the close call at the end from 
sqlite_close_v2() to sqlite_close in order for it to work with 3.6.16 - I don't 
expect this changes the results.

#include "sqlite3.h"
#include 
#include 

const std::vector query_texts =
{
R"(CREATE TABLE ABUNDANCE(AbundanceId INTEGER PRIMARY KEY NOT NULL, 
AbundanceId0 INTEGER, AbundanceId1 INTEGER, AbundanceId2 INTEGER, AbundanceId3 
INTEGER, AbundanceId4 INTEGER, AbundanceId5 INTEGER, AbundanceId6 INTEGER, 
AbundanceId7 INTEGER, AbundanceId8 INTEGER, SetAbundanceId0 INTEGER, 
SetAbundanceId1 INTEGER, SetAbundanceId2 INTEGER))",
R"(CREATE UNIQUE INDEX ABUNDANCE_UNIQUE_DATA_INDEX ON ABUNDANCE(AbundanceId0, 
AbundanceId1, AbundanceId2, AbundanceId3, AbundanceId4, AbundanceId5, 
AbundanceId6, AbundanceId7, AbundanceId8, SetAbundanceId0, SetAbundanceId1, 
SetAbundanceId2))",
R"(CREATE INDEX ABUNDANCE_INDEX ON ABUNDANCE(AbundanceId0, AbundanceId1, 
AbundanceId2, AbundanceId3, AbundanceId4, AbundanceId5, AbundanceId6, 
AbundanceId7, AbundanceId8))",
R"(CREATE INDEX ABUNDANCE_SetAbundanceId0 ON ABUNDANCE(SetAbundanceId0))",
R"(CREATE INDEX ABUNDANCE_SetAbundanceId1 ON ABUNDANCE(SetAbundanceId1))",
R"(CREATE INDEX ABUNDANCE_SetAbundanceId2 ON ABUNDANCE(SetAbundanceId2))",

R"(CREATE TABLE ABUNDANCE_0(AbundanceId0 INTEGER PRIMARY KEY NOT NULL, Col6 
INTEGER, Col16 INTEGER, Col19 INTEGER, Col3l INTEGER, Col14 INTEGER, Col15 
INTEGER, Col3 INTEGER, Col8 INTEGER))",
R"(CREATE UNIQUE INDEX ABUNDANCE_0_UNIQUE_DATA_INDEX ON ABUNDANCE_0(Col6, 
Col16, Col19, Col3l, Col14, Col15, Col3, Col8))",

R"(CREATE TABLE ABUNDANCE_1(AbundanceId1 INTEGER PRIMARY KEY NOT NULL, 
Col16t INTEGER, Col26n INTEGER, Col13o INTEGER, Col9 INTEGER, Col18u INTEGER, 
Col14i INTEGER, Col3o INTEGER, Col1r INTEGER, Col19i INTEGER, Col6e INTEGER, 
Col1 INTEGER, Col3u INTEGER, Col19n INTEGER, Col23 INTEGER, Col13n INTEGER, 
Col16d INTEGER))",
R"(CREATE UNIQUE INDEX ABUNDANCE_1_UNIQUE_DATA_INDEX ON ABUNDANCE_1(Col16t, 
Col26n, Col13o, Col9, Col18u, Col14i, Col3o, Col1r, Col19i, Col6e, Col1, Col3u, 
Col19n, Col23, Col13n, Col16d))",

R"(CREATE TABLE ABUNDANCE_2(AbundanceId2 INTEGER PRIMARY KEY NOT NULL, 
Col15s INTEGER, Col26r INTEGER, Col22 INTEGER, Col9r INTEGER, Col0l INTEGER, 
Col0u INTEGER, Col11 INTEGER, Col3d INTEGER, Col20i INTEGER, Col14a INTEGER, 
Col12i INTEGER, Col3r INTEGER, Col19e INTEGER, Col18e INTEGER, Col0g INTEGER, 
Col18h INTEGER))",
R"(CREATE UNIQUE INDEX ABUNDANCE_2_UNIQUE_DATA_INDEX ON ABUNDANCE_2(Col15s, 
Col26r, Col22, Col9r, Col0l, Col0u, Col11, Col3d, Col20i, Col14a, Col12i, 
Col3r, Col19e, Col18e, Col0g, Col18h))",

R"(CREATE TABLE ABUNDANCE_3(AbundanceId3 INTEGER PRIMARY KEY NOT NULL, 
Col14b INTEGER, Col1i INTEGER, Col14d INTEGER, Col25b INTEGER, Col19m INTEGER, 
Col9n INTEGER, Col13g INTEGER, Col16b INTEGER, Col21 INTEGER, Col7e INTEGER, 
Col20e INTEGER, Col7a INTEGER, Col8g INTEGER, Col0s INTEGER, Col19b INTEGER, 
Col12a INTEGER))",
R"(CREATE UNIQUE INDEX ABUNDANCE_3_UNIQUE_DATA_INDEX ON ABUNDANCE_3(Col14b, 
Col1i, Col14d, Col25b, Col19m, Col9n, Col13g, Col16b, Col21, Col7e, Col20e, 
Col7a, Col8g, Col0s, Col19b, Col12a))",

R"(CREATE TABLE ABUNDANCE_4(AbundanceId4 INTEGER PRIMARY KEY NOT NULL, 
Col4y INTEGER, Col19r INTEGER, Col18b INTEGER, Col8f INTEGER, Col20b INTEGER, 
Col16r INTEGER, Col3e INTEGER, Col5r INTEGER, Col20l INTEGER, Col3s INTEGER, 
Col1a INTEGER, Col7d INTEGER, Col25 INTEGER, Col3a INTEGER, Col5u INTEGER, 
Col20a INTEGER))",
R"(CREATE UNIQUE INDEX ABUNDANCE_4_UNIQUE_DATA_INDEX ON ABUNDANCE_4(Col4y, 
Col19r, Col18b, Col8f, Col20b, Col16r, Col3e, Col5r, Col20l, Col3s, Col1a, 
Col7d, Col25, Col3a, Col5u, Col20a))",

R"(CREATE TABLE ABUNDANCE_5(AbundanceId5 INTEGER PRIMARY KEY NOT NULL, 
Col3m INTEGER, Col16a INTEGER, Col11r INTEGER, Col0m INTEGER, Col0r INTEGER, 
Col24e INTEGER, Col16u INTEGER, Col4 INTEGER, Col14p INTEGER, Col20m INTEGER, 
Col1e INTEGER, Col20h INTEGER, Col8o INTEGER, Col19c INTEGER, Col12u INTEGER, 
Col20c INTEGER))",
R"(CREATE UNIQUE INDEX ABUNDANCE_5_UNIQUE_DATA_INDEX ON ABUNDANCE_5(Col3m, 
Col16a, Col11r, Col0m, Col0r, Col24e, Col16u, Col4, Col14p, Col20m, Col1e, 
Col20h, Col8o, Col19c, Col12u, Col20c))",

R"(CREATE TA

Re: [sqlite] Crash when querying a unique index containing 12 columns using sub-selects

[Luuk]

On 11-01-18 18:01, Matthew Towler wrote:
> Hi
>
> I believe I have found a bug in sqlite, which my tests show was introduced 
> between versions 3.7.17 and 3.8.0 and remains present in all versions up to 
> and including 3.21.0 (I have also tested 3.8.11, 3.9.3, 3.12.2 all of which 
> hang.  I believe it closely related to, and probably just a bigger version 
> of, bug https://www.sqlite.org/src/tktview/9f2eb3abac9b83222f8a (problems 
> with indices with more than four columns) which was introduced in 3.8.0, and 
> fixed in a later version.  I am struggling slightly to produce a small 
> example for reproduction as to get it to fail requires both a complex 
> arrangement of tables and a significant volume of data (it all works 
> flawlessly when there are only a few rows) and the data I have is 
> proprietary.  I thought in the first instance I might be able to pass on what 
> I can easily and as it is so very similar to the previous issue someone 
> familiar with the code might understand the issue immediately - whilst I work 
> on getting more data I can pass on.  I hope this is acceptable, apologies for 
> the long message.
>
> I have an ABUNDANCE table with 12 rows, with a unique index across all the 
> rows.
>
> CREATE TABLE ABUNDANCE(AbundanceId INTEGER PRIMARY KEY NOT NULL,AbundanceId0 
> INTEGER,AbundanceId1 INTEGER,AbundanceId2 INTEGER,AbundanceId3 
> INTEGER,AbundanceId4 INTEGER,AbundanceId5 INTEGER,AbundanceId6 
> INTEGER,AbundanceId7 INTEGER,AbundanceId8 INTEGER,SetAbundanceId0 
> INTEGER,SetAbundanceId1 INTEGER,SetAbundanceId2 INTEGER);

a more readable version:

CREATE TABLE ABUNDANCE(
  AbundanceId INTEGER PRIMARY KEY NOT NULL,
  AbundanceId0 INTEGER,
  AbundanceId1 INTEGER,
  AbundanceId2 INTEGER,
  AbundanceId3 INTEGER,
  AbundanceId4 INTEGER,
  AbundanceId5 INTEGER,
  AbundanceId6 INTEGER,
  AbundanceId7 INTEGER,
  AbundanceId8 INTEGER,
  SetAbundanceId0 INTEGER,
  SetAbundanceId1 INTEGER,
  SetAbundanceId2 INTEGER);


> CREATE UNIQUE INDEX ABUNDANCE_UNIQUE_DATA_INDEX ON 
> ABUNDANCE(AbundanceId0,AbundanceId1,AbundanceId2,AbundanceId3,AbundanceId4,AbundanceId5,AbundanceId6,AbundanceId7,AbundanceId8,SetAbundanceId0,SetAbundanceId1,SetAbundanceId2);
> CREATE INDEX ABUNDANCE ON 
> ABUNDANCE(AbundanceId0,AbundanceId1,AbundanceId2,AbundanceId3,AbundanceId4,AbundanceId5,AbundanceId6,AbundanceId7,AbundanceId8);
Error: there is already a table named ABUNDANCE


When trying (good try !) to report an error, make sure you copy/paste
this kind of stuff, of tripple check!

___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Crash when querying a unique index containing 12 columns using sub-selects

[Simon Slavin]

On 11 Jan 2018, at 5:01pm, Matthew Towler  wrote:

> With versions prior to 3.8.0 the query returns in under a second (which is 
> very impressive!).  A query without all the sub-selects (so just selecting 
> some specific ID values from the main table) always works correctly (which is 
> why I had to include the long version in this message, for which apologies).

In your two versions, please prepend "EXPLAIN QUERY PLAN " to your SELECT 
command.  Do they both report the same query plan ?

> What I have found, and the reason I feel this is closely related to the bug I 
> mentioned earlier, is that if I delete the index ABUNDANCE_UNIQUE_DATA_INDEX 
> on the main table (a unique index on all the columns) the query works 
> perfectly on all versions I have tested.

Does the query plan remain the same when you delete the index ?

Simon.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Crash when querying a unique index containing 12 columns using sub-selects

[Richard Hipp]

On 1/11/18, Matthew Towler  wrote:
> for the
> volumes of data I have sqlite hangs

Is it hanging, or is it crashing?  Your statement of the problem is
unclear on this point.
-- 
D. Richard Hipp
d...@sqlite.org
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Crash while rollback database in journal_mode=DELETE

[Taewon Park]

Thank you for your quick reply!

> If so, please tell us the email address that is associated with your SEE
license.

Unfortunately I'm using my own implementation, not SEE. Of course via
SQLite3 C API interface, such as sqlite3CodecAttach and etc.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Crash while rollback database in journal_mode=DELETE

[Richard Hipp]

On 4/7/17, Taewon Park  wrote:
>
> Because of changed default page size, My application has different
> page-sized encrypted databases : 1024 and 4096.
>

Are you using the SQLite encryption extension (SEE) for this?  If so,
please tell us the email address that is associated with your SEE
license.
-- 
D. Richard Hipp
d...@sqlite.org
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Crash on Android

[Hick Gunter]

Looks like attempting to dereference a NULL pointer. Without a backtrace of the 
call stack this is not of much use. Most commonly this is caused by an 
uninitialized variable on the stack, accessing a structure that has been 
freed/garbage collected or memory being clobbered by a rogue write operation 
(too long, wrong place e.g. dangling pointer).

Attaching a debugger and/or adding log messages may change the stack layout in 
a way that makes the problem appear to have gone away (it is just affecting 
"something else", which may or may not mind).

In the context of sqlite3_column_text16(), make sure that the last call to 
sqlite3_step() returned SQLITE_ROW and that sqlite3_step(), sqlite3_finalize) 
or sqlite3_reset() are not called on the statement (even from another thread) 
and that you are not using an object returned from sqlite3_column_value() or 
using pointers returned from prior sqlite3_column functions and calling an 
sqlite3_column function that requires a conversion to take place.

-Ursprüngliche Nachricht-
Von: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] Im 
Auftrag von Jeff Archer
Gesendet: Montag, 27. Februar 2017 17:28
An: SQLite mailing list 
Betreff: [sqlite] Crash on Android

Hi All,
Any thoughts on this will be greatly appreciated.

I am having an issue only on a specific tablet when it is running Android 
4.2.2.  When Android is upgraded to 4.4.2 problems appears to be gone.  I still 
want to understand root cause to know if problem is really gone.

My environment is a little unusual.  I am running SQLite amalgamation wrapped 
by JDBC driver.  I was running 3.13.0 when issue was initially found but have 
updated to 3.17.0 and no change.

Problem always occurs while doing same operation but unable to predict when it 
will occur.  Problem occurs while reading in a specific table and a call to 
sqlite3_column_text16() results in the following error being logged:
A/libc(5225): Fatal signal 11 (SIGSEGV) at 0x (code=128), thread
5225 (saltillo.chatpc)
and of course kills the process.

Also, I find that attaching a debugger or writing too many log messages seems 
to make the problems disappear also.

Thanks,
Jeff
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users


___
 Gunter Hick
Software Engineer
Scientific Games International GmbH
FN 157284 a, HG Wien
Klitschgasse 2-4, A-1130 Vienna, Austria
Tel: +43 1 80100 0
E-Mail: h...@scigames.at

This communication (including any attachments) is intended for the use of the 
intended recipient(s) only and may contain information that is confidential, 
privileged or legally protected. Any unauthorized use or dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please immediately notify the sender by return e-mail message and 
delete all copies of the original communication. Thank you for your cooperation.


___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Crash on Android

[Daniel Anderson]

looks like a race condition!

but it could also be uninitialized variable, but this is rarer these day as
most compiler flag uninitialized var.
unless your uninitialized var happen to be in a struct, this is why
constructor are so important for struct/class






2017-02-27 11:28 GMT-05:00 Jeff Archer :

> Hi All,
> Any thoughts on this will be greatly appreciated.
>
> I am having an issue only on a specific tablet when it is running Android
> 4.2.2.  When Android is upgraded to 4.4.2 problems appears to be gone.  I
> still want to understand root cause to know if problem is really gone.
>
> My environment is a little unusual.  I am running SQLite amalgamation
> wrapped by JDBC driver.  I was running 3.13.0 when issue was initially
> found but have updated to 3.17.0 and no change.
>
> Problem always occurs while doing same operation but unable to predict when
> it will occur.  Problem occurs while reading in a specific table and a call
> to sqlite3_column_text16() results in the following error being logged:
> A/libc(5225): Fatal signal 11 (SIGSEGV) at 0x (code=128), thread
> 5225 (saltillo.chatpc)
> and of course kills the process.
>
> Also, I find that attaching a debugger or writing too many log messages
> seems to make the problems disappear also.
>
> Thanks,
> Jeff
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>



-- 
Daniel
*L'action accède à la perfection quand, bien que vivant, vous êtes déjà
mort*
*Bunan*
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Crash Report

[Richard Hipp]

On 9/18/16, Keith Medcalf  wrote:
>
> Somewhere between:
>
> 2016-09-03 16:23:42 672c21bcf09c5bfb67e061456a56be45409c4f34
>
> 2016-09-09 20:23:59 19e2e5950541f1a93eed994cc2b1eaf64b68e858
>
> where the former works and the later crashes (with a wunderful new fangled
> Windows 10 content free  error message) ((I do not have all versions from
> the fossil repository in my private repository)
>
> also fails on head of trunk
>
> 2016-09-18 16:08:10 6bf5ba10d28f1b0a32aa9a560ae3143a1235eadb

I cannot get it to fail - probably because I do not have data.

Can you please recompile with -DSQLITE_DEBUG than add "PRAGMA
vdbe_debug=ON;" just before the UPDATE, and send me the output?
-- 
D. Richard Hipp
d...@sqlite.org
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] crash in sqlite3MatchSpanName

[Richard Hipp]

On 1/22/15, Michal Zalewski  wrote:
> Hey,
>
> Another afl-fuzz crash, looks like a straightforward NULL ptr deref,
> 3.8.8.1:
>
> -- snip! --
> select e.*,0 from(s,(L))e;
> -- snip! --

Thanks for the bug report.

The fix is at https://www.sqlite.org/src/info/9e6eae660a0230 and the
trouble-ticket is at https://www.sqlite.org/src/info/32b63d542433ca67


>
> #0  sqlite3MatchSpanName (zSpan=0x0, zCol=0x0, zTab=0x6dce30 "e",
> zDb=0x0) at sqlite3.c:80494
> #1  0x0047413c in selectExpander (pWalker=0x0, p=0x0) at
> sqlite3.c:109581
> #2  0x0041d28d in sqlite3WalkSelect (pWalker=0x7fffc230,
> p=) at sqlite3.c:80307
> #3  0x00424405 in sqlite3SelectExpand (pSelect= out>, pParse=) at sqlite3.c:109707
> #4  sqlite3SelectPrep (pParse=0x0, p=0x0, pOuterNC=0x6dce30) at
> sqlite3.c:44257
> #5  0x0045afcd in sqlite3Select (pParse=0x0, p=0x0,
> pDest=0x6dce30) at sqlite3.c:110036
> #6  0x0048344d in yy_reduce (yyruleno=,
> yypParser=) at sqlite3.c:124023
> #7  sqlite3Parser (yyp=0x6dd318, yymajor=0, yyminor=...,
> pParse=0x6dbbe8, pParse@entry=0x6dd078) at sqlite3.c:59579
> ...
>
> /mz
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>


-- 
D. Richard Hipp
d...@sqlite.org
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Crash when binding default column value

[Jean-Christophe Deschamps]

At 21:53 24/09/2014, you wrote:


> If the default cannot be represented exactly, its rounding will be the
> least of the difficulties.

Not always: in scientific applications I've had column values default 
to plenty of irrational numbers: fractions of pi, sqrt(2.0) etc.


My main gripe is when the value being read from a database isn't 
identical to the value written to the database. I've had problems in 
the past where conversion between double and text, e.g. sprintf() and 
atof(), isn't perfectly invertible even at 17+ significant figures. 
Perhaps this may only be an issue on some of the older platforms I've 
worked on or on traditional client/server architectures (with which 
I'm more familiar) where client and server can be different platforms. 
I haven't (yet) tested SQLite empirically, though I notice SQLite has 
its own atof() implementation sqlite3AtoF() which weakens my 
confidence that I'll get out exactly what float I put in represented 
as text. In my (admittedly limited) experience, IEEE754 
implementations are transferable, when endian-flipped as appropriate.


While it's only almost true that IEEE754 (which flavor?) are 
"transferable", you still seem to bark at the wrong tree.


Like other contributors have already said, you definitely can't rely on 
a double stored value to represent exactly a real literal you supply. 
For instance as shown below, 0.75 = 0.5 + 0.25 has a bounded 
representation as fractional binary (1/2 + 1/4). On the contrary, 0.3 
doesn't enjoy the same property and it would need an infinite string of 
decreasing powers of 2 to represent: its floating point representation 
is inexact.


0.75 is represented exactly   in IEEE754 by X'3FE8'
0.3  is represented approximately in IEEE754 by X'3FD3'

The finite set of reals (rational numbers in fact) that IEEE754 can 
represent is infinitesimally smaller than the set of reals, whatever 
finite number of bits the FP representation uses.


Here's a real-world scenario where this could cause an issue (I've 
actually encountered this for real) Imagine an application writer 
who's instructed my library to use pi (say) as a column's default. 
When reading the value out of the database, they may want to test if 
the value equals the default...


One way to get rid of that: use the output of
select 
3.1415926535897932384626433832795028841971693993751058209749445923078164062862089986280348253421170679


which gives:

3.14159265358979

That value is now safe. 


___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Crash when binding default column value

[James K. Lowden]

On Wed, 24 Sep 2014 20:53:32 +0100
Nathaniel Trellice  wrote:

> > > You are doing CREATE TABLE statements based on text from an
> > > untrusted user?  Really?
> 
> > My reaction exactly.  
> 
> 
> I'm writing a library so the safety of the input is out of my hands
> and in that of the application writers who work 'above' me. I neither
> want to burden them with the responsibility to escape strings nor
> trust them to remember to do so.

Fair enough.  I can see why you'd want to use parameterized queries for
that.  And it looks as though you might get your wish.  

I guess if I were in your shoes I'd run the input through
sqlite3_snprintf with %q, to safely double any quotes.  

--jkl

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Crash when binding default column value

[Simon Slavin]

On 24 Sep 2014, at 8:53pm, Nathaniel Trellice  wrote:

> Imagine an application writer who's instructed my library to use pi (say) as 
> a column's default. When reading the value out of the database, they may want 
> to test if the value equals the default

Sorry, but you don't do this with REALs.  Every programmer worth their salt 
knows you can't rely on that sort of thing.

Simon.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Crash when binding default column value

[Nathaniel Trellice]

Hi Richard, James,

> > >  * SQL injection attacks;
> > >
> > 
> > You are doing CREATE TABLE statements based on text from an untrusted
> > user?  Really?

> My reaction exactly.  


I'm writing a library so the safety of the input is out of my hands and in that 
of the application writers who work 'above' me. I neither want to burden them 
with the responsibility to escape strings nor trust them to remember to do so. 
In the myriad of uses planned for this library, it's a distinct possibility 
that there may be a UI with a default text value field filled-in by a user that 
trickles down directly into a database column default: there will certainly be 
occasions when a property's default value is specified by a user. Even if 
malicious injection attacks are unlikely via a text column default, seemingly 
benign default text, perhaps hard-coded by an unwitting application developer, 
could cause havoc (or, more likely, cause an exception to be thrown and a 
migration to fail) when not suitably escaped.


This library includes limited support for schema evolution. SQLite's limited 
support for ALTER TABLE leads me to make many more CREATE TABLE calls than you 
might expect.


> > >  * floating point value rounding in conversion to/from text;

> If the default cannot be represented exactly, its rounding will be the
> least of the difficulties. 


Not always: in scientific applications I've had column values default to plenty 
of irrational numbers: fractions of pi, sqrt(2.0) etc.


My main gripe is when the value being read from a database isn't identical to 
the value written to the database. I've had problems in the past where 
conversion between double and text, e.g. sprintf() and atof(), isn't perfectly 
invertible even at 17+ significant figures. Perhaps this may only be an issue 
on some of the older platforms I've worked on or on traditional client/server 
architectures (with which I'm more familiar) where client and server can be 
different platforms. I haven't (yet) tested SQLite empirically, though I notice 
SQLite has its own atof() implementation sqlite3AtoF() which weakens my 
confidence that I'll get out exactly what float I put in represented as text. 
In my (admittedly limited) experience, IEEE754 implementations are 
transferable, when endian-flipped as appropriate.

Here's a real-world scenario where this could cause an issue (I've actually 
encountered this for real) Imagine an application writer who's instructed my 
library to use pi (say) as a column's default. When reading the value out of 
the database, they may want to test if the value equals the default: if so, 
they can head up some pre-computed branch of code, otherwise they have to 
compute everything from scratch. Of course their equality comparison could 
(should?) have some tolerance threshold, but they'll come to me to complain 
when their code runs slow because I can't return exactly the same value they 
gave me. Okay, it was a 1 min patch.


Nevertheless, you're right that representing a floating point value as text 
using a bunch of significant figures (I'd err on the side of caution and go 
with 17 or 18) will suffice: it will have to.


> > >  * how else can I set a default value for a binary blob column?

>http://www.sqlite.org/lang_expr.html

>"BLOB literals are string literals containing hexadecimal data
> and preceded by a single "x" or "X" character. Example: X'53514C697465'"


Thanks for the pointer to Blob literals. I hadn't spotted them.



If you think I'm being pedantic/overly-preemptive, you're right: These issues 
are unlikely to cause anyone headaches. My motivation for wanting to bind 
default values is a combination of:


1. An artificial (unrealistic?) attempt to maintain clean separation between 
manipulation of database structure and database content: I'm happy to use 
sql/text for the former but want to use all-binary transfer for the latter. So 
far, I've been able to adhere to this, but life's never so clean: default 
values fall nicely in the grey area: they start as database structure (part of 
the schema), then end up as database content.

2. Binding values makes these concerns, however poxie, go away.


Nathaniel

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Crash when binding default column value

[James K. Lowden]

On Wed, 24 Sep 2014 09:49:36 -0400
Richard Hipp  wrote:

> >  * SQL injection attacks;
> >
> 
> You are doing CREATE TABLE statements based on text from an untrusted
> user?  Really?

My reaction exactly.  

> >  * floating point value rounding in conversion to/from text;

If the default cannot be represented exactly, its rounding will be the
least of the difficulties. 

> >  * how else can I set a default value for a binary blob column?

http://www.sqlite.org/lang_expr.html

"BLOB literals are string literals containing hexadecimal data
and preceded by a single "x" or "X" character. Example: X'53514C697465'"

HTH.  

--jkl
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Crash when binding default column value

[Richard Hipp]

On Wed, Sep 24, 2014 at 7:36 AM, Nathaniel Trellice 
wrote:

> Dear list members,
>
> I'm trying to set a default value for a column in my "CREATE TABLE"
> statement. I really, really want to bind the default value (using
> sqlite3_bind_*) rather than expressing it in SQL text to avoid the
> following problems:
>
>  * SQL injection attacks;
>

You are doing CREATE TABLE statements based on text from an untrusted
user?  Really?

If you really need to do that, construct the CREATE TABLE statement using
the sqlite3_mprintf() family of string formatting functions and use %Q  to
substitute text literals.  %Q will automatically add the surrounding '..'
marks and escape internal ' characters, correctly.

   char *zSql = sqlite3_mprintf("CREATE TABLE t1(a, b DEFAULT(%Q))",
zStringFromUser);
   sqlite3_exec(db, zSql, 0, 0, 0);
   sqlite3_free(zSql);




>  * floating point value rounding in conversion to/from text;
>

Just give 15 or 16 digits of precision.


>  * how else can I set a default value for a binary blob column?
>

Using a blob literal.  Ex:  x'a5b4c3'.   See the output of:  "SELECT
quote(randomblob(10));"



>
>
> The SQL syntax tree for the "CREATE TABLE" statement at
> http://www.sqlite.org/lang_createtable.html suggests binding a default
> value is permitted. In
> particular"create-table-stmt:column-def:column-constraint:expr:" can be a
> bind parameter.
>

The text has been clarified to say that bound parameters are not permitted
in a DEFAULT clause.


>
>
> The example code, below, highlights the problem I'm having. The code
> creates a table with a bound default value for one of the two columns. The
> statement is prepared (no syntax error warning), and the value bound
> successfully. But upon inserting a row that requires using the default
> parameter, it crashes in function sqlite3ExprCodeTarget(). (Inserting a row
> with both column values explicitly set works fine.)
>
>
> Tech details: using sqlite-amalgamation-3080600 on Centos 7, compiling
> with GCC4.8.2.
>

The segfault problem has now been fixed in trunk.  You'll get an error
message instead.  Legacy databases that already have parameters sitting in
their sqlite_master tables will see those parameters be silently converted
into NULL if they are ever used.


>
>
> Am I making a silly mistake? Or, contrary to the documentation, is binding
> a default column value in a "CREATE TABLE" statement not possible? If it's
> not possible, can anyone suggest another way to achieve the goal of
> avoiding conversion ofdefault column values to SQL text?
>
>
> Many thanks,
>
> Nathaniel
>
>
> Example code:
>
>
>
> #include 
> #include 
> #include 
>
> int main(int argc, char* argv[])
> {
>   sqlite3 *db = NULL;
>   sqlite3_stmt *pStmt = NULL;
>   int c;
>
>   /* Open database */
>   c = sqlite3_open_v2(
> "test.db", &db, (SQLITE_OPEN_READWRITE | SQLITE_OPEN_CREATE), 0);
>   if (c) {
> fprintf(stderr, "Can't open database: %s\n", sqlite3_errmsg(db));
> exit(0);
>   }
>
>   /* Table creation SQL */
>   const char *sql =
> "CREATE TABLE test_table ("
> "name TEXT  DEFAULT ('joe'), "
> "interest TEXT  DEFAULT (?1))";
>
>   /* Prepare SQL statement */
>   c = sqlite3_prepare(db, sql, -1, &pStmt, NULL);
>   if (c != SQLITE_OK) {
> fprintf(stderr, "Can't prepare statement: %s\n", sqlite3_errmsg(db));
> exit(0);
>   }
>
>   /* Bind SQL statement value */
>   const char *golf = "golf";
>   c = sqlite3_bind_text(pStmt, 1, golf, -1, SQLITE_STATIC);
>   if (c != SQLITE_OK) {
> fprintf(stderr, "Can't bind statement: %s\n", sqlite3_errmsg(db));
> exit(0);
>   }
>
>   /* Evaluate SQL statement */
>   c = sqlite3_step(pStmt);
>   if (c != SQLITE_DONE) {
> fprintf(stderr, "Can't evaluate statement: %s\n", sqlite3_errmsg(db));
> exit(0);
>   }
>
>   /* Destroy prepared SQL statement */
>   c = sqlite3_finalize(pStmt);
>   if (c != SQLITE_OK) {
> fprintf(stderr, "Can't destroy statement: %s\n", sqlite3_errmsg(db));
> exit(0);
>   }
>
>   /* Insert row */
>   const char *sql2 = "INSERT INTO test_table (name) VALUES ('jack');";
>   char *errmsg = NULL;
>   c = sqlite3_exec(db, sql2, NULL, NULL, &errmsg);
>   if (c != SQLITE_OK) {
> fprintf(stderr, "Can't insert row: %s\n", errmsg);
> exit(0);
>   }
>   sqlite3_free(errmsg);
>
>   /* Close database */
>   c = sqlite3_close(db);
>   if (c != SQLITE_OK) {
> fprintf(stderr, "Can't close database: %s\n", sqlite3_errmsg(db));
> exit(0);
>   }
>
>   return 0;
> }
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>



-- 
D. Richard Hipp
d...@sqlite.org
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Crash when binding default column value

[Simon Slavin]

On 24 Sep 2014, at 1:33pm, Nathaniel Trellice  wrote:

> Without the INSERT call, my test code runs through without crashing. 
> Attempting the INSERT call in the shell tool crashes it too. Following your 
> advice, the output of the .schema command looks dodgy:
> 
> CREATE TABLE test_table (name TEXT DEFAULT ('joe'), interest TEXT DEFAULT 
> (?1));
> 
> I'm an SQLite newbie, though, so maybe that's right. Or perhaps bound 
> parameters aren't 'resolved' in a "CREATE TABLE" statement?

You got it right.  As you can see from the above, SQLite did not make the 
substitution for your bound value and the '?1' made it all the way to the table 
definition.  You should, of course, be seeing your 'golf' value there instead.  
I'm going to have to let someone else tell you whether you should or shouldn't 
be able to bind DEFAULT values.  I don't know.

But having allowed that to happen SQLite now has a definition for a table, and 
that definition has bad syntax.  And that bad syntax is causing SQLite to 
crash.  And that is a no-no and will be fixed.  I have no idea how it'll be 
fixed but it will.  Thanks for posting the details of your problem and a clear 
way to reproduce it.

In the meantime if you need your program to set default values for table 
columns at runtime you'll have to do it by editing the command's text instead 
of using binding.  Which you already know is bad for reasons you listed in your 
first post.  Sorry for the inconvenience.

Simon.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Crash when binding default column value

[Keith Medcalf]

I think that the diagrams on http://www.sqlite.org/lang_createtable.html are 
the generic parsing and construction rules for "expr" everywhere an "expr" can 
be used.  The text description further down the page describes restrictions and 
usage particular to the CREATE TABLE statement itself.

Under COLUMN DEFINITIONS you have:

The DEFAULT clause specifies a default value to use for the column if no value 
is explicitly provided by the user when doing an INSERT. If there is no 
explicit DEFAULT clause attached to a column definition, then the default value 
of the column is NULL. An explicit DEFAULT clause may specify that the default 
value is NULL, a string constant, a blob constant, a signed-number, or any 
constant expression enclosed in parentheses. An explicit default value may also 
be one of the special case-independent keywords CURRENT_TIME, CURRENT_DATE or 
CURRENT_TIMESTAMP. For the purposes of the DEFAULT clause, an expression is 
considered constant provided that it does not contain any sub-queries, column 
or table references, or string literals enclosed in double-quotes instead of 
single-quotes.

note the "constant expression".  The type of "constant" is stated, and that it 
may also be a constant expression (meaning an expression of constants).  45.7 
given  literally is a constant.  sin(45.7) is a constant expression.  Since ? 
is not a constant, then an expression containing ? is not a constant 
expression.   Perhaps it could be more explicit by saying that bound values are 
not permitted.


Under SQL Data Constraints you will also see that:

A CHECK constraint may be attached to a column definition or specified as a 
table constraint. In practice it makes no difference. Each time a new row is 
inserted into the table or an existing row is updated, the expression 
associated with each CHECK constraint is evaluated and cast to a NUMERIC value 
in the same way as a CAST expression. If the result is zero (integer value 0 or 
real value 0.0), then a constraint violation has occurred. If the CHECK 
expression evaluates to NULL, or any other non-zero value, it is not a 
constraint violation. The expression of a CHECK constraint may not contain a 
subquery.


Nothing in the CREATE TABLE (or any CREATE) can contain a bound value (well, I 
suppose the parser could render it into text and insert that value literally, 
but at the moment it does not).  This is because the schema is stored as the 
text of the create statements, so the value of that variable must be available 
each time the constraint parsed when DML is parsed against the definition.


>-Original Message-
>I'm trying to set a default value for a column in my "CREATE TABLE"
>statement. I really, really want to bind the default value (using
>sqlite3_bind_*) rather than expressing it in SQL text to avoid the
>following problems:
>
> * SQL injection attacks;
> * floating point value rounding in conversion to/from text;
> * how else can I set a default value for a binary blob column?
>
>
>The SQL syntax tree for the "CREATE TABLE" statement at
>http://www.sqlite.org/lang_createtable.html suggests binding a default
>value is permitted. In particular"create-table-stmt:column-def:column-
>constraint:expr:" can be a bind parameter.
>
>
>The example code, below, highlights the problem I'm having. The code
>creates a table with a bound default value for one of the two columns.
>The statement is prepared (no syntax error warning), and the value bound
>successfully. But upon inserting a row that requires using the default
>parameter, it crashes in function sqlite3ExprCodeTarget(). (Inserting a
>row with both column values explicitly set works fine.)
>
>
>Tech details: using sqlite-amalgamation-3080600 on Centos 7, compiling
>with GCC4.8.2.
>
>
>Am I making a silly mistake? Or, contrary to the documentation, is
>binding a default column value in a "CREATE TABLE" statement not
>possible? If it's not possible, can anyone suggest another way to achieve
>the goal of avoiding conversion ofdefault column values to SQL text?
>
>
>Many thanks,
>
>Nathaniel
>
>
>Example code:
>
>
>
>#include 
>#include 
>#include 
>
>int main(int argc, char* argv[])
>{
>  sqlite3 *db = NULL;
>  sqlite3_stmt *pStmt = NULL;
>  int c;
>
>  /* Open database */
>  c = sqlite3_open_v2(
>"test.db", &db, (SQLITE_OPEN_READWRITE | SQLITE_OPEN_CREATE), 0);
>  if (c) {
>fprintf(stderr, "Can't open database: %s\n", sqlite3_errmsg(db));
>exit(0);
>  }
>
>  /* Table creation SQL */
>  const char *sql =
>"CREATE TABLE test_table ("
>"name TEXT  DEFAULT ('joe'), "
>"interest TEXT  DEFAULT (?1))";
>
>  /* Prepare SQL statement */
>  c = sqlite3_prepare(db, sql, -1, &pStmt, NULL);
>  if (c != SQLITE_OK) {
>fprintf(stderr, "Can't prepare statement: %s\n", sqlite3_errmsg(db));
>exit(0);
>  }
>
>  /* Bind SQL statement value */
>  const char *golf = "golf";
>  c = sqlite3_bind_text(pStmt, 1, golf, -1, SQLITE_STATIC);
>  if (c != SQLITE_OK) {
>fpr

Re: [sqlite] Crash when binding default column value

[Richard Hipp]

On Wed, Sep 24, 2014 at 8:33 AM, Nathaniel Trellice 
wrote:

> Attempting the INSERT call in the shell tool crashes it too. Following
> your advice, the output of the .schema command looks dodgy:
>
>  CREATE TABLE test_table (name TEXT DEFAULT ('joe'), interest TEXT DEFAULT
> (?1));
>
> I'm an SQLite newbie, though, so maybe that's right.
>

SQLite should never crash.  This is a bug.  We've already written the
ticket (http://www.sqlite.org/src/tktview/78c0c8c3c9f7c) and are working on
a fix.
-- 
D. Richard Hipp
d...@sqlite.org
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Crash when binding default column value

[Nathaniel Trellice]

Hi Simon,

Thanks for the quick reply.


Without the INSERT call, my test code runs through without crashing. Attempting 
the INSERT call in the shell tool crashes it too. Following your advice, the 
output of the .schema command looks dodgy:

 CREATE TABLE test_table (name TEXT DEFAULT ('joe'), interest TEXT DEFAULT 
(?1));

I'm an SQLite newbie, though, so maybe that's right. Or perhaps bound 
parameters aren't 'resolved' in a "CREATE TABLE" statement?

Thanks again,

Nathaniel
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Crash when binding default column value

[Hick Gunter]

My guess would be that finalizing the create table statement makes the bound 
value go out of scope and thus be unavailable to the insert statement.

Bound values reside somewhere in the internal prepared statement structure and 
do not get copied into the database file, even if they happen to be default 
column values.

-Ursprüngliche Nachricht-
Von: Nathaniel Trellice [mailto:napt...@yahoo.co.uk]
Gesendet: Mittwoch, 24. September 2014 13:36
An: sqlite-users@sqlite.org
Betreff: [sqlite] Crash when binding default column value

Dear list members,

I'm trying to set a default value for a column in my "CREATE TABLE" statement. 
I really, really want to bind the default value (using sqlite3_bind_*) rather 
than expressing it in SQL text to avoid the following problems:

 * SQL injection attacks;
 * floating point value rounding in conversion to/from text;
 * how else can I set a default value for a binary blob column?


The SQL syntax tree for the "CREATE TABLE" statement at 
http://www.sqlite.org/lang_createtable.html suggests binding a default value is 
permitted. In particular"create-table-stmt:column-def:column-constraint:expr:" 
can be a bind parameter.


The example code, below, highlights the problem I'm having. The code creates a 
table with a bound default value for one of the two columns. The statement is 
prepared (no syntax error warning), and the value bound successfully. But upon 
inserting a row that requires using the default parameter, it crashes in 
function sqlite3ExprCodeTarget(). (Inserting a row with both column values 
explicitly set works fine.)


Tech details: using sqlite-amalgamation-3080600 on Centos 7, compiling with 
GCC4.8.2.


Am I making a silly mistake? Or, contrary to the documentation, is binding a 
default column value in a "CREATE TABLE" statement not possible? If it's not 
possible, can anyone suggest another way to achieve the goal of avoiding 
conversion ofdefault column values to SQL text?


Many thanks,

Nathaniel


Example code:



#include 
#include 
#include 

int main(int argc, char* argv[])
{
  sqlite3 *db = NULL;
  sqlite3_stmt *pStmt = NULL;
  int c;

  /* Open database */
  c = sqlite3_open_v2(
"test.db", &db, (SQLITE_OPEN_READWRITE | SQLITE_OPEN_CREATE), 0);
  if (c) {
fprintf(stderr, "Can't open database: %s\n", sqlite3_errmsg(db));
exit(0);
  }

  /* Table creation SQL */
  const char *sql =
"CREATE TABLE test_table ("
"name TEXT  DEFAULT ('joe'), "
"interest TEXT  DEFAULT (?1))";

  /* Prepare SQL statement */
  c = sqlite3_prepare(db, sql, -1, &pStmt, NULL);
  if (c != SQLITE_OK) {
fprintf(stderr, "Can't prepare statement: %s\n", sqlite3_errmsg(db));
exit(0);
  }

  /* Bind SQL statement value */
  const char *golf = "golf";
  c = sqlite3_bind_text(pStmt, 1, golf, -1, SQLITE_STATIC);
  if (c != SQLITE_OK) {
fprintf(stderr, "Can't bind statement: %s\n", sqlite3_errmsg(db));
exit(0);
  }

  /* Evaluate SQL statement */
  c = sqlite3_step(pStmt);
  if (c != SQLITE_DONE) {
fprintf(stderr, "Can't evaluate statement: %s\n", sqlite3_errmsg(db));
exit(0);
  }

  /* Destroy prepared SQL statement */
  c = sqlite3_finalize(pStmt);
  if (c != SQLITE_OK) {
fprintf(stderr, "Can't destroy statement: %s\n", sqlite3_errmsg(db));
exit(0);
  }

  /* Insert row */
  const char *sql2 = "INSERT INTO test_table (name) VALUES ('jack');";
  char *errmsg = NULL;
  c = sqlite3_exec(db, sql2, NULL, NULL, &errmsg);
  if (c != SQLITE_OK) {
fprintf(stderr, "Can't insert row: %s\n", errmsg);
exit(0);
  }
  sqlite3_free(errmsg);

  /* Close database */
  c = sqlite3_close(db);
  if (c != SQLITE_OK) {
fprintf(stderr, "Can't close database: %s\n", sqlite3_errmsg(db));
exit(0);
  }

  return 0;
}
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users


___
 Gunter Hick
Software Engineer
Scientific Games International GmbH
FN 157284 a, HG Wien
Klitschgasse 2-4, A-1130 Vienna, Austria
Tel: +43 1 80100 0
E-Mail: h...@scigames.at

This communication (including any attachments) is intended for the use of the 
intended recipient(s) only and may contain information that is confidential, 
privileged or legally protected. Any unauthorized use or dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please immediately notify the sender by return e-mail message and 
delete all copies of the original communication. Thank you for your cooperation.


___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Crash when binding default column value

[Simon Slavin]

On 24 Sep 2014, at 12:36pm, Nathaniel Trellice  wrote:

> The example code, below, highlights the problem I'm having. The code creates 
> a table with a bound default value for one of the two columns. The statement 
> is prepared (no syntax error warning), and the value bound successfully. But 
> upon inserting a row that requires using the default parameter, it crashes in 
> function sqlite3ExprCodeTarget(). (Inserting a row with both column values 
> explicitly set works fine.)

Can you split your program into two ?

Use your code to create the table in the first place but not do the INSERT.

Then use the SQLite shell tool to open the resulting database and look at the 
schema (perhaps use the command '.schema').  Check to see that the schema is 
what you'd expect it to be.

Then use the SQLite shell tool to INSERT some lines and see whether the shell 
tool crashes.

If the shell tool crashes we have a 100% repeatable case where the SQLite 
development team have all the source code.  It would be very easy to debug.

If the shell tool doesn't crash then the problem is probably somewhere in your 
own code rather than in SQLite.  This doesn't mean nobody will help you, but it 
makes it easier to see where the problem is.

Simon.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Crash in sqlite3_mutex_try [Was: SQLite 3.8.6 beta]

[Jan Nijtmans]

2014-08-22 9:14 GMT+02:00 Jan Nijtmans :
> It looks like this is on its way to being corrected:
>
>
> However, I don't think this will work on Win95/98/NT

Fixed here:
 

Thanks! No more remarks!

Regards,
   Jan Nijtmans
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Crash in sqlite3_mutex_try [Was: SQLite 3.8.6 beta]

[Jan Nijtmans]

2014-08-15 12:50 GMT+02:00 Jan Nijtmans :
> Looking at the function sqlite3_win32_is_nt()
> It should simply return 1 on any
> currently supported platform. Looking closely,
> it returns 0 on Windows RT, but who cares 
> (leaving the "why" as practice for the reader)

It looks like this is on its way to being corrected:
   

However, I don't think this will work on Win95/98/NT
(not that I really care ..). The reason: GetVersionExW()
will be called to check whether the kernal is NT-based,
but Win95/98/NT is not NT-based so it doesn't have
this function  ;-). Suggested solution:


Second-best suggested solution as patch below
(based on the winrt branch)

Regards,
  Jan Nijtmans

Index: src/os_win.c
==
--- src/os_win.c
+++ src/os_win.c
@@ -1323,17 +1323,17 @@
   **   kernel.
   */
   return 1;
 #elif defined(SQLITE_WIN32_GETVERSIONEX) && SQLITE_WIN32_GETVERSIONEX
   if( osInterlockedCompareExchange(&sqlite3_os_type, 0, 0)==0 ){
-#if defined(SQLITE_WIN32_HAS_WIDE)
+#if !defined(SQLITE_WIN32_HAS_ANSI)
 OSVERSIONINFOW sInfo;
 sInfo.dwOSVersionInfoSize = sizeof(sInfo);
 osGetVersionExW(&sInfo);
 osInterlockedCompareExchange(&sqlite3_os_type,
 (sInfo.dwPlatformId == VER_PLATFORM_WIN32_NT) ? 2 : 1, 0);
-#elif defined(SQLITE_WIN32_HAS_ANSI)
+#else
 OSVERSIONINFOA sInfo;
 sInfo.dwOSVersionInfoSize = sizeof(sInfo);
 osGetVersionExA(&sInfo);
 osInterlockedCompareExchange(&sqlite3_os_type,
 (sInfo.dwPlatformId == VER_PLATFORM_WIN32_NT) ? 2 : 1, 0);
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Crash in sqlite3_mutex_try [Was: SQLite 3.8.6 beta]

[Jan Nijtmans]

2014-08-12 10:35 GMT+02:00 Jan Nijtmans :

>
> $ i686-w64-mingw32-gcc -c -DSQLITE_WIN32_NO_ANSI sqlite3.c
> sqlite3.c: In function ‘sqlite3_win32_is_nt’:
> sqlite3.c:33312:10: error: ‘sInfo’ undeclared (first use in this function)
>
>  (sInfo.dwPlatformId == VER_PLATFORM_WIN32_NT) ? 2 : 1, 0);
>   ^
> sqlite3.c:33312:10: note: each undeclared identifier is reported only once
> for each function it appears in
>

Fixed here: 

Thanks!

Looking at the function sqlite3_win32_is_nt():

it's getting more and more complicated, without doing
really anything: It should simply return 1 on any
currently supported platform. Looking closely,
it returns 0 on Windows RT, but who cares 
(leaving the "why" as practice for the reader)

Best overall-solution can be found here:

A big +1 from me for this, paying any attention
to Win95 just isn't worth the effort IMHO!

Regards,
 Jan Nijtmans
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Crash in sqlite3_mutex_try [Was: SQLite 3.8.6 beta]

[jose isaias cabrera]

"Richard Hipp" wrote...



On Tue, Aug 12, 2014 at 6:50 PM, jose isaias cabrera <
jic...@cinops.xerox.com> wrote:



"Klaas V" wrote...



Jan wrote: " ** can manually set this value to 1 to emulate Win98
behavior.
*/"

Can anyone give me one good reason apart from nostalgia to support a MS
system not supported by MS?



There are 1000's of reason$ why, but if some win98 machines are doing 
jobs

that are working perfectly without any need to upgrade, why upgrade them?
If things are working correctly, why break it?  I am one of those that do
not upgrade just because.



So if your old win98 machine is working perfectly, why do you need the
latest version of SQLite?  Won't an older version of SQLite that *does*
support win98 and that has been working perfectly for all these years
suffice?


I don't have any win98 machine. I was just responding to the question,


Can anyone give me one good reason apart from nostalgia to support a MS
system not supported by MS?


But, I don't have any issues with win98. :-)

josé

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Crash in sqlite3_mutex_try [Was: SQLite 3.8.6 beta]

[Richard Hipp]

On Tue, Aug 12, 2014 at 6:50 PM, jose isaias cabrera <
jic...@cinops.xerox.com> wrote:

>
> "Klaas V" wrote...
>
>
>> Jan wrote: " ** can manually set this value to 1 to emulate Win98
>> behavior.
>> */"
>>
>> Can anyone give me one good reason apart from nostalgia to support a MS
>> system not supported by MS?
>>
>
> There are 1000's of reason$ why, but if some win98 machines are doing jobs
> that are working perfectly without any need to upgrade, why upgrade them?
> If things are working correctly, why break it?  I am one of those that do
> not upgrade just because.
>

So if your old win98 machine is working perfectly, why do you need the
latest version of SQLite?  Won't an older version of SQLite that *does*
support win98 and that has been working perfectly for all these years
suffice?

-- 
D. Richard Hipp
d...@sqlite.org
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Crash in sqlite3_mutex_try [Was: SQLite 3.8.6 beta]

[jose isaias cabrera]

"Klaas V" wrote...


Jan wrote: " ** can manually set this value to 1 to emulate Win98 
behavior.

*/"

Can anyone give me one good reason apart from nostalgia to support a MS 
system not supported by MS?


There are 1000's of reason$ why, but if some win98 machines are doing jobs 
that are working perfectly without any need to upgrade, why upgrade them? 
If things are working correctly, why break it?  I am one of those that do 
not upgrade just because.


josé 


___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Crash in sqlite3_mutex_try [Was: SQLite 3.8.6 beta]

[Adam Devita]

1a) Somebody is paying you to do it.
1b) Incremental cost (or risk) of supporting it is small compared to the
cost (or risk) of porting /upgrading

Adam


On Tue, Aug 12, 2014 at 2:46 AM, Klaas V  wrote:

>
>
>  Jan wrote: " ** can manually set this value to 1 to emulate Win98
> behavior.
> */"
>
> Can anyone give me one good reason apart from nostalgia to support a MS
> system not supported by MS?
>
>
> Kind regards | Cordiali saluti | Vriendelijke groeten | Freundliche Grüsse,
> Klaas `Z4us` V  - OrcID -0001-7190-2544
> ___
> 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] Crash in sqlite3_mutex_try [Was: SQLite 3.8.6 beta]

[Jan Nijtmans]

2014-08-11 13:12 GMT+02:00 Jan Nijtmans :

> And below is a minimal patch which fixes this problem.
>

Unfortunately, latest SQLite trunk, which fixes the
SQLITE_WIN32_GETVERSIONEX problem brought
back the SQLITE_WIN32_NO_ANSI problem
I reported earlier   -(

$ i686-w64-mingw32-gcc -c -DSQLITE_WIN32_NO_ANSI sqlite3.c
sqlite3.c: In function ‘sqlite3_win32_is_nt’:
sqlite3.c:33312:10: error: ‘sInfo’ undeclared (first use in this function)
 (sInfo.dwPlatformId == VER_PLATFORM_WIN32_NT) ? 2 : 1, 0);
  ^
sqlite3.c:33312:10: note: each undeclared identifier is reported only once
for each function it appears in

I could deliver a patch, but there are two fundementally
different (but both correct) approaches to handle this.

Regards,
  Jan Nijtmans
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Crash in sqlite3_mutex_try [Was: SQLite 3.8.6 beta]

[Klaas V]

 Jan wrote: " ** can manually set this value to 1 to emulate Win98 behavior.
*/"

Can anyone give me one good reason apart from nostalgia to support a MS system 
not supported by MS?


Kind regards | Cordiali saluti | Vriendelijke groeten | Freundliche Grüsse,
Klaas `Z4us` V  - OrcID -0001-7190-2544
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Crash if "sqlite3_db_release_memory" has no memory to release

[Richard Hipp]

On Thu, Mar 13, 2014 at 2:57 PM, Eduardo Morras  wrote:

>
> Hi, I get app crash if sqlite3_db_release_memory(db) is called and Sqlite3
> has no memory to release, for example calling it twice.
>
> The backtrace is:
>
> #0  0x0042ab60 in sqlite3PcacheShrink (pCache=0x6f6c6f63207b2065)
> at /usr/home/gowen/clang/scgi/src/sqlite3.c:37835
> #1  0x00415f3c in sqlite3PagerShrink (pPager=0x801072308)
> at /usr/home/gowen/clang/scgi/src/sqlite3.c:42949
> #2  0x00415ee8 in sqlite3_db_release_memory (db=0x801007808)
> at /usr/home/gowen/clang/scgi/src/sqlite3.c:120647
> #3  0x004ab3e3 in db_get_binary_content (fn=0x7fffcf10
> "background.jpeg",
> size=0x7fffce4c, ret=0x7fffd6e8) at
> /usr/home/gowen/clang/scgi/src/db.c:116
>
> Line 116 on #3 is the call to sqlite3_db_release_memory(db).
>
> I know it's an internal sqlite3 call and I should use
> sqlite3_release_memory instead.
>

sqlite3_db_release_memory() is a valid API that anybody can call.  It
should just work.

We are unable to reproduce your crash.  Perhaps there is heap corruption
caused by some other part of the application and that this is tripping up
SQLite.



>
> Versions tried 3.8.3, 3.8.4, 3.8.4.1. amalgamation under FreeBSD 9.2
> x86_64. using clang 3.4 compiler.
>
> ---   ---
> Eduardo Morras 
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>



-- 
D. Richard Hipp
d...@sqlite.org
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] [CRASH] Segmentation fault since 3.8.0

[Alexandre Courbot]

On Tue, Sep 3, 2013 at 9:20 PM, Richard Hipp  wrote:
> On Mon, Sep 2, 2013 at 11:07 PM, Alexandre Courbot  wrote:
>>
>> Hi everyone, (not subscribed to the ML, please CC)
>>
>> The following happens since 3.8.0 (tested on both 3.8.0 and 3.8.0.1):
>>
>> $ cat |sqlite3
>> create table t1(id INTEGER);
>> create table t2(id INTEGER, v INTEGER);
>> insert into t1 values(1);
>> select distinct t1.id from t1 left join t2 on t2.id = t1.id order by
>> t2.v is null;
>> Segmentation fault (core dumped)
>
>
> Thanks for the simple test case!  See
> http://www.sqlite.org/src/tktview/be84e357c03 for the ticket.  We'll get to
> work on this right away.

Seen on the ticket this has been fixed already, thanks for the quick reaction!

Alex.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] [CRASH] Segmentation fault since 3.8.0

[Richard Hipp]

On Tue, Sep 3, 2013 at 9:09 AM, Richard Hipp  wrote:

>
>
> We should have a proper fix before too long.
>
>
That fix can now be seen at http://www.sqlite.org/src/info/0303d6bc71
-- 
D. Richard Hipp
d...@sqlite.org
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] [CRASH] Segmentation fault since 3.8.0

[Richard Hipp]

On Mon, Sep 2, 2013 at 11:07 PM, Alexandre Courbot  wrote:

> Hi everyone, (not subscribed to the ML, please CC)
>
> The following happens since 3.8.0 (tested on both 3.8.0 and 3.8.0.1):
>
> Could this be related to the new query planner?
>

No.  This seems to be due to the new optimization that strives to omit
unused tables from the query.  The optimizer was under the impression that
the second table (the one on the right of the LEFT JOIN) is not being used
and so it is omitted.  Somehow the optimizaer is missing the fact that the
second table is used in the ORDER BY clause.  The line of code at
http://www.sqlite.org/src/artifact/a37169b46fc?ln=5912 should detect that
the second table is used in the ORDER BY clause, but somehow it is not.
However this happens, the cursor object for this table is never opened, and
so when ORDER BY clause goes to try to extract values from the cursor, it
dereferences a NULL pointer and segfaults.

You can disable the optimization in the shell using:

.testctrl optimizations 0x400

Or from C code:

sqlite3_test_control(SQLITE_TESTCTRL_OPTIMIZATIONS, db, 0x400);

We should have a proper fix before too long.

-- 
D. Richard Hipp
d...@sqlite.org
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] [CRASH] Segmentation fault since 3.8.0

[Richard Hipp]

On Mon, Sep 2, 2013 at 11:07 PM, Alexandre Courbot  wrote:

> Hi everyone, (not subscribed to the ML, please CC)
>
> The following happens since 3.8.0 (tested on both 3.8.0 and 3.8.0.1):
>
> $ cat |sqlite3
> create table t1(id INTEGER);
> create table t2(id INTEGER, v INTEGER);
> insert into t1 values(1);
> select distinct t1.id from t1 left join t2 on t2.id = t1.id order by
> t2.v is null;
> Segmentation fault (core dumped)
>

Thanks for the simple test case!  See
http://www.sqlite.org/src/tktview/be84e357c03 for the ticket.  We'll get to
work on this right away.


>
> The same statements with 3.7.17 do *not* crash.
>
> Removing the "distinct" keyword, selecting t2.id instead of t1.id, or
> ordeting on just t2.v result in a successful query. This seems
> triggered by the usage of "distinct", a left join, and ordering on a
> condition, but I haven't managed to narrow it further down. I am also
> not familiar enough with SQLite's internals to debug it further
> unfortunately. Could this be related to the new query planner?
>
> Alex.
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>



-- 
D. Richard Hipp
d...@sqlite.org
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Crash

[bardzotajnekonto]

> Works fine for me on both Linux and Windows7, for SQLite version 3.7.16.2
> and 3.7.17 (beta).  

It also works for me on linux. I'v looked what is happening on vista and it 
doesn't crash but silently exists. fgets() in local_getline() is returning 0 
when n is 0. My problem with small nField on older version must be something 
different.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Crash

[Clemens Ladisch]

bardzotajneko...@interia.pl wrote:
> Select below crashes sqlite:
>
> C:\>chcp 65001
> Aktywna strona kodowa: 65001

Nice try.

> C:\>sqlite3.exe db
> sqlite> SELECT `czy firma upadła` FROM `tabela_analityczna`;

In Windows, UTF-8 I/O on the console does not work.

It would be possible to enable UTF-8 *output* by calling _setmode
(), but it is
not possible to enable UTF-8 for stdin because somebody forgot to
implement it:


The only way to get UTF-8 from the console would be to replace the
standard functions like read/fgets with ReadConsoleW, but this works
only if the input is not redirected.


Regards,
Clemens
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Crash

[Richard Hipp]

On Fri, May 10, 2013 at 6:41 AM,  wrote:

>
> Select below crashes sqlite:
> C:\>sqlite3.exe db
> SQLite version 3.7.16.2 2013-04-12 11:52:43
> Enter ".help" for instructions
> Enter SQL statements terminated with a ";"
> sqlite> SELECT `czy firma upadła` FROM `tabela_analityczna`;
>

Works fine for me on both Linux and Windows7, for SQLite version 3.7.16.2
and 3.7.17 (beta).  Running on linux with valgrind gives no warnings.
Renaming your database as "pl1.db" and putting your single query in a
script named "pl1.txt":

drh@tallis:~/sqlite/bld$ valgrind ./sqlite3 pl1.db http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Crash (c0000005 - Access Violation) in sqlite3.exe

[Yuriy Kaminskiy]

Yuriy Kaminskiy wrote:
> Richard Hipp wrote:
>> On Thu, Feb 23, 2012 at 12:29 PM, Petite Abeille
>> wrote:
>>
>>> On Feb 23, 2012, at 6:21 PM, Levi Haskell wrote:
>>>
 sqlite> select 1 from (select *);
>>> Wow, wicked :)
>>>
>>> Confirmed on sqlite3 -version
>>> 3.7.10 2012-01-16 13:28:40 ebd01a8deffb5024a5d7494eef800d2366d97204
>>>
>>
>> Fixed here:  http://www.sqlite.org/src/info/c8c7846fb9
> 
> This fix triggers SQLITE_NOMEM and test/select1.test select1-16.1 failure when
> lookaside allocation failed (or sqlite compiled with SQLITE_OMIT_LOOKASIDE):
>> select1-16.1...
>> Expected: [1 {no tables specified}]
>>  Got: [1 {out of memory}]
> Maybe sqlite3Malloc() should be changed to NOT return NULL when called with 
> n==0.
Conservative fix:

Index: sqlite3-3.7.11/src/select.c
===
--- sqlite3-3.7.11.orig/src/select.c2012-03-31 12:32:12.0 +0400
+++ sqlite3-3.7.11/src/select.c 2012-03-31 12:34:42.0 +0400
@@ -1258,7 +1258,11 @@ static int selectColumnsFromExprList(
   char *zName;/* Column name */
   int nName;  /* Size of name in zName[] */

-  *pnCol = nCol = pEList ? pEList->nExpr : 0;
+  if( !pEList ){
+*pnCol = 0; *paCol = NULL;
+return SQLITE_OK;
+  }
+  *pnCol = nCol = pEList->nExpr;
   aCol = *paCol = sqlite3DbMallocZero(db, sizeof(aCol[0])*nCol);
   if( aCol==0 ) return SQLITE_NOMEM;
   for(i=0, pCol=aCol; ihttp://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Crash (c0000005 - Access Violation) in sqlite3.exe

[Yuriy Kaminskiy]

Richard Hipp wrote:
> On Thu, Feb 23, 2012 at 12:29 PM, Petite Abeille
> wrote:
> 
>> On Feb 23, 2012, at 6:21 PM, Levi Haskell wrote:
>>
>>> sqlite> select 1 from (select *);
>> Wow, wicked :)
>>
>> Confirmed on sqlite3 -version
>> 3.7.10 2012-01-16 13:28:40 ebd01a8deffb5024a5d7494eef800d2366d97204
>>
> 
> 
> Fixed here:  http://www.sqlite.org/src/info/c8c7846fb9

This fix triggers SQLITE_NOMEM and test/select1.test select1-16.1 failure when
lookaside allocation failed (or sqlite compiled with SQLITE_OMIT_LOOKASIDE):
> select1-16.1...
> Expected: [1 {no tables specified}]
>  Got: [1 {out of memory}]
Maybe sqlite3Malloc() should be changed to NOT return NULL when called with 
n==0.

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Crash in icuOpen()

[Damian Pietras]

On Fri, Mar 30, 2012 at 07:38:11PM -0400, Richard Hipp wrote:
> It is easy enough for use to just put a patch in the code to fix this.  But
> we would rather understand what is happening first.  Can you recreate the
> problem?  Can you give us any clues what you are doing in order to make
> this happen?

Please see my email "Segfault with FTS and tokenize=icu", it's from 2010
but this seems to be the same scenario. Then steps to reproduce were:

CREATE VIRTUAL TABLE f USING fts3 (t TEXT, tokenize=icu);
insert into f (docid) values (1);
insert into f (docid) values (2);
insert into f (docid) values (3);
insert into f (docid) values (4);
update f set t = 'test' where docid = 3;

-- 
Damian Pietras

http://www.linuxprogrammingblog.com
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Crash in icuOpen()

[Richard Hipp]

It is easy enough for use to just put a patch in the code to fix this.  But
we would rather understand what is happening first.  Can you recreate the
problem?  Can you give us any clues what you are doing in order to make
this happen?

On Fri, Mar 30, 2012 at 6:18 PM, Rajeev Sharma  wrote:

> Hello,
>
> The SQLite library is crashing in icuOpen() function because it is trying
> to check the strlen of a string, which is NULL. I have also put the stack
> trace.
>
> In this case zInput is NULL. And so it is crashing in this line: nInput =
> strlen(zInput);
>
> Here is the partial function definition of icuOpen().
>
> static int icuOpen(
>  sqlite3_tokenizer *pTokenizer, /* The tokenizer */
>  const char *zInput,/* Input string */
>  int nInput,/* Length of zInput in bytes */
>  sqlite3_tokenizer_cursor **ppCursor/* OUT: Tokenization cursor */
> ){
>  IcuTokenizer *p = (IcuTokenizer *)pTokenizer;
>  IcuCursor *pCsr;
>
>  const int32_t opt = U_FOLD_CASE_DEFAULT;
>  UErrorCode status = U_ZERO_ERROR;
>  int nChar;
>
>  UChar32 c;
>  int iInput = 0;
>  int iOut = 0;
>
>  *ppCursor = 0;
>
>  if( nInput<0 ){
>nInput = strlen(zInput);///Crashes here because zInput is NULL///
>  }
>  nChar = nInput+1;
> .
> .
> .
> .
> .
> .
> .
>
>
> Stack trace:
>
> #0  strlen (s=0x0)
> at strlen.c:9
> #1  0x7979f44c in icuOpen (pTokenizer=, zInput=0x0,
> nInput=-1,
> ppCursor=0x77dc7084)
> at sqlite3/src/sqlite3.c:131816
> #2  0x797ab548 in sqlite3Fts3CacheDeferredDoclists (pCsr=)
> at sqlite3/src/sqlite3.c:126136
> #3  fts3EvalTestDeferredAndNear (pCsr=0x7baed400, pRc=)
> at sqlite3/src/sqlite3.c:53892
> #4  0x797acfb0 in fts3EvalNext (pCsr=)
> at sqlite3/src/sqlite3.c:119461
> #5  fts3NextMethod (pCursor=)
> at sqlite3/src/sqlite3.c:52003
> #6  0x797c747c in sqlite3VdbeExec (p=0x7b9d8210)
> at sqlite3/src/sqlite3.c:69467
> #7  0x797aa314 in sqlite3Step (p=)
> at sqlite3/src/sqlite3.c:61921
> #8  sqlite3_step (pStmt=0x7b9ed598)
>at sqlite3/src/sqlite3.c:61994
>
> -
> This transmission (including any attachments) may contain confidential
> information, privileged material (including material protected by the
> solicitor-client or other applicable privileges), or constitute non-public
> information. Any use of this information by anyone other than the intended
> recipient is prohibited. If you have received this transmission in error,
> please immediately reply to the sender and delete this information from
> your system. Use, dissemination, distribution, or reproduction of this
> transmission by unintended recipients is not authorized and may be unlawful.
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>



-- 
D. Richard Hipp
d...@sqlite.org
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Crash (c0000005 - Access Violation) in sqlite3.exe

[Richard Hipp]

On Thu, Feb 23, 2012 at 12:29 PM, Petite Abeille
wrote:

>
> On Feb 23, 2012, at 6:21 PM, Levi Haskell wrote:
>
> > sqlite> select 1 from (select *);
>
> Wow, wicked :)
>
> Confirmed on sqlite3 -version
> 3.7.10 2012-01-16 13:28:40 ebd01a8deffb5024a5d7494eef800d2366d97204
>


Fixed here:  http://www.sqlite.org/src/info/c8c7846fb9



>
>
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>



-- 
D. Richard Hipp
d...@sqlite.org
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Crash (c0000005 - Access Violation) in sqlite3.exe

[Petite Abeille]

On Feb 23, 2012, at 6:21 PM, Levi Haskell wrote:

> sqlite> select 1 from (select *);

Wow, wicked :) 

Confirmed on sqlite3 -version
3.7.10 2012-01-16 13:28:40 ebd01a8deffb5024a5d7494eef800d2366d97204


___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Crash SQLite [version: 3.6.23.1; tested: shell]

[Jay A. Kreibich]

On Mon, May 17, 2010 at 06:10:09PM +0100, Simon Slavin scratched on the wall:
> 
> On 17 May 2010, at 5:48pm, Jay A. Kreibich wrote:
> 
> >  The other options is to just use fixed-point integer values (e.g. an
> >  integer value that is 1 cent, or 1/100th of a cent, or whatever range
> >  you need).  You need to be careful about the math, but that would be
> >  much simpler.  64-bit integers give you a fair amount of room to play
> >  with.
> 
> The tedium comes when you try to implement all the types of
> calculation.  It's fast to do the four which are
> 
> decimal + - * / decimal
>
> but you also have to implement
> 
> decimal + - * / integer
> decimal + - * / real
> integer + - * / decimal
> real + - * / decimal

  No, you don't.  Once a DECIMAL is "tainted" by a REAL, you don't want
  it going back unless the SQL programmer manually casts it back (which
  usually isn't wise).  So there is no additional operation.  You
  just convert to REAL before and do the standard math.  So you have:

dec2real(decimal) + - * / real => real
real + - * / dec2real(decimal) => real
  

  With fixed and/or BCD it is always safe to cast an INTEGER into a
  DECIMAL (outside of overflows), so any INT/DEC interactions
  become DEC/DEC:

decimal + - * / int2dec(integer) => decimal
int2dec(integer) + - * / decimal => decimal

  Decimal to real is whatever it is.  Decimal to integer is either
  known to be safe or not.

> and that's before implementing all the functions which take more than
> two arguments (e.g. max(), sum()).

  I never said it was simple.  If you wanted to modify SQLite to do
  this with built-in types, you'd have to do all that as well.

  By making it a modified type (e.g. TEXT or BLOB) you remove yourself
  from the standard numeric sort order.  I'm not sure if that's good or
  bad.  Likely good.

  And you can still do all that with an extension.

> You also have to decide whether 1.33 is meant to equal 4/3, which
> means reading up on how much slip to allow and trying to implement
> one solution which suits everyone who will want to use SQLite.

  Again, yes, but that's still no different with BCD or Fixed, or with
  an extension or built-in types.  Those concerns are tied to the
  problem (and part of the reason to move to BCD or Fixed), not any
  specific solution.

   -j

-- 
Jay A. Kreibich < J A Y  @  K R E I B I.C H >

"Our opponent is an alien starship packed with atomic bombs.  We have
 a protractor."   "I'll go home and see if I can scrounge up a ruler
 and a piece of string."  --from Anathem by Neal Stephenson
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Crash SQLite [version: 3.6.23.1; tested: shell]

[Simon Slavin]

On 17 May 2010, at 5:48pm, Jay A. Kreibich wrote:

>  The other options is to just use fixed-point integer values (e.g. an
>  integer value that is 1 cent, or 1/100th of a cent, or whatever range
>  you need).  You need to be careful about the math, but that would be
>  much simpler.  64-bit integers give you a fair amount of room to play
>  with.

The tedium comes when you try to implement all the types of calculation.  It's 
fast to do the four which are

decimal + - * / decimal

but you also have to implement

decimal + - * / integer
decimal + - * / real
integer + - * / decimal
real + - * / decimal

and that's before implementing all the functions which take more than two 
arguments (e.g. max(), sum()).  You also have to decide whether 1.33 is 
meant to equal 4/3, which means reading up on how much slip to allow and trying 
to implement one solution which suits everyone who will want to use SQLite.

Simon.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Crash SQLite [version: 3.6.23.1; tested: shell]

[Jay A. Kreibich]

On Mon, May 17, 2010 at 08:17:02AM -0700, Roger Binns scratched on the wall:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On 05/17/2010 06:29 AM, Samuel Adam wrote:
> > Plug for outstanding feature request: DECIMAL type
> 
> Leaving the merits of the type aside, adding it would make the database
> incompatible with every existing SQLite library version already out there.
> That is not done lightly.
> 
> Additionally for the code to be compatible with SQLite's license, a public
> domain library implementation would be needed for the vast majority of
> platforms that do not support the type in hardware.  This is a non-trivial
> amount of work.
> 
> You can of course fork SQLite and add the type yourself.

  It would also be possible to do a pretty good job with an extension.
  I would either store them as text values or BCD BLOBs.  An extension
  that contained basic conversion functions, conversions, possible
  collations, and basic math operators would get you most of the way
  there.  It would make a lot of the SQL a bit ugly, but it could be
  done.

  The other options is to just use fixed-point integer values (e.g. an
  integer value that is 1 cent, or 1/100th of a cent, or whatever range
  you need).  You need to be careful about the math, but that would be
  much simpler.  64-bit integers give you a fair amount of room to play
  with.

   -j

-- 
Jay A. Kreibich < J A Y  @  K R E I B I.C H >

"Our opponent is an alien starship packed with atomic bombs.  We have
 a protractor."   "I'll go home and see if I can scrounge up a ruler
 and a piece of string."  --from Anathem by Neal Stephenson
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Crash SQLite [version: 3.6.23.1; tested: shell]

[Roger Binns]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 05/17/2010 06:29 AM, Samuel Adam wrote:
> Plug for outstanding feature request: DECIMAL type

Leaving the merits of the type aside, adding it would make the database
incompatible with every existing SQLite library version already out there.
That is not done lightly.

Additionally for the code to be compatible with SQLite's license, a public
domain library implementation would be needed for the vast majority of
platforms that do not support the type in hardware.  This is a non-trivial
amount of work.

You can of course fork SQLite and add the type yourself.  Or pay anyone to
do that.

Roger
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkvxXeIACgkQmOOfHg372QR5KACgq2lREoDEDTIgGbcxN4ZtB2Sh
dvwAoIULkaToeGWnCM1LzhL0ZKlHK0mv
=D+bE
-END PGP SIGNATURE-
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Crash SQLite [version: 3.6.23.1; tested: shell]

[Richard Hipp]

On Mon, May 17, 2010 at 9:29 AM, Samuel Adam  wrote:

> CREATE TABLE "Test"
>("Number" INTEGER DEFAULT (123));
>-- Was originally a dynamic default with strftime().
>-- Cut down for test case/to find crash.
> CREATE TRIGGER "Automatic"
>BEFORE INSERT ON "Test"
>BEGIN
>DELETE FROM "Test";
>END;
> INSERT INTO "Test" DEFAULT VALUES; -- Crash here.
>


http://www.sqlite.org/src/info/f3162063fd


>
> (Yes, I have an actual use case; that’s how I found the bug.)
>
> Most recent version tested:
>  * SQLite version 3.6.23.1
>  * Application tested: sqlite3.exe shell from sqlite.org (file date
> 2010-03-29)
>  * Platform tested: Windows
>  * Dr. Watson claimed exception number c005 (access violation): “The
> exception generated was c005 at address 00436B85 ()”
>  * A few other versions and configurations have crashed as well.
>  * First noticed in SQLite 3.6.19.
>
> Plug for outstanding feature request: DECIMAL type (such as IEEE 754-2008
> BCD format).  Why?  Humans use decimal; computers ought be made to serve
> humans, not vice versa; and if you put a penny into a database, you should
> be able to get a penny back out.
>
> Very truly,
>
> Samuel Adam   http://certifound.com/+A
> 763 Montgomery Road • Hillsborough, New Jersey (U.S.)
> Justice: http://certifound.com/
> Spotlight: http://certifound.com/+A9097BE/JPMorgan.Chase.delenda.est.
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>



-- 
-
D. Richard Hipp
d...@sqlite.org
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Crash SQLite [version: 3.6.23.1; tested: shell]

[Black, Michael (IS)]

This bug was fixed (we just went though this last week).
 
Download a recent fossil repository and you'll be good.
 
 
Sounds kind of like it's time for a new release to me.  Is there any planned 
time for 3.7.0?
 
 
Michael D. Black
Senior Scientist
Northrop Grumman Mission Systems
 



From: sqlite-users-boun...@sqlite.org on behalf of Samuel Adam
Sent: Mon 5/17/2010 8:29 AM
To: sqlite-users@sqlite.org
Subject: [sqlite] Crash SQLite [version: 3.6.23.1; tested: shell]



CREATE TABLE "Test"
("Number" INTEGER DEFAULT (123));
-- Was originally a dynamic default with strftime().
-- Cut down for test case/to find crash.
CREATE TRIGGER "Automatic"
BEFORE INSERT ON "Test"
BEGIN
DELETE FROM "Test";
END;
INSERT INTO "Test" DEFAULT VALUES; -- Crash here.

(Yes, I have an actual use case; that's how I found the bug.)

Most recent version tested:
  * SQLite version 3.6.23.1
  * Application tested: sqlite3.exe shell from sqlite.org (file date 
2010-03-29)
  * Platform tested: Windows
  * Dr. Watson claimed exception number c005 (access violation): "The 
exception generated was c005 at address 00436B85 ()"
  * A few other versions and configurations have crashed as well.
  * First noticed in SQLite 3.6.19.

Plug for outstanding feature request: DECIMAL type (such as IEEE 754-2008 
BCD format).  Why?  Humans use decimal; computers ought be made to serve 
humans, not vice versa; and if you put a penny into a database, you should 
be able to get a penny back out.

Very truly,

Samuel Adam   http://certifound.com/+A
763 Montgomery Road * Hillsborough, New Jersey (U.S.)
Justice: http://certifound.com/
Spotlight: http://certifound.com/+A9097BE/JPMorgan.Chase.delenda.est.
___
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] Crash after add column

[a1rex]

- Original Message 

>From: VasiliyF4 
>After I try to ADD a column by run the querry "ALTER TABLE x
>ADD y NUMERIC" from my application, I can't use the data base any more. If I
>try to get or save any data at my DB it cause crash of the application.

Of course your old INSERT statements will not work anymore, since INSERT 
statement requires knowledge of all columns in the table.


  __
Looking for the perfect gift? Give the gift of Flickr! 

http://www.flickr.com/gift/
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Crash after add column

[a1rex]

>I try to ADD a column by run the querry "ALTER TABLE x
>ADD y NUMERIC" from my application, I can't use the data base any more.

Try this: "ALTER TABLE main.x ADD y NUMERIC" and verify by external tool that 
column x has been added.


  __
Connect with friends from any web browser - no download required. Try the new 
Yahoo! Canada Messenger for the Web BETA at 
http://ca.messenger.yahoo.com/webmessengerpromo.php
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Crash after add column

[A.]

On Sat, 2010-03-06 at 23:39 -0800, VasiliyF4 wrote:
> I Use C/Linux. After I try to ADD a column by run the querry "ALTER TABLE x
> ADD y NUMERIC" from my application, I can't use the data base any more. If I
> try to get or save any data at my DB it cause crash of the application.

Could you provide us with some reproducible steps?

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Crash in Rtree

[Dan Kennedy]

On Feb 16, 2010, at 4:30 PM, Dair Grant wrote:

>
> Hi,
>
> I think I have run into a crashing bug in the Rtree module,  
> triggered by
> changing the database page size.

Thanks for working this out. A new version of rtree.c with the fix
included is here:

   http://www.sqlite.org/src/raw/ext/rtree/rtree.c?name=30945

> One fix would be to memcpy only the actual size of the blob into the  
> node,
> however I'm not sure if this is the best fix or if there are wider  
> issues
> with the iNodeSize on disk (for a given blob) being larger/smaller  
> than the
> iNodeSize calculated by rtreeInit.

Changing just the memcpy() will only work if the Rtree.iNodeSize is
larger than the actual node-size on disk. If it is smaller, only the
first part of each node will be loaded. Chaos follows. The patched
version above changes rtreeInit() to use the on-disk node-size when
connecting to an existing rtree structure.

Dan.

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Crash inside sqlite3_step

[Kavita Raghunathan]

I found that you are correct. I wasn't reading the valgrind log properly.
Thank you.
Kavita

On 1/25/10 10:26 PM, "Dan Kennedy"  wrote:

> 
> On Jan 26, 2010, at 6:16 AM, Kavita Raghunathan wrote:
> 
>> Following Sql query crashes in allocateCursor inside of sqlite3_step
>> 
>> INSERT INTO EntityTbl (AttrName, AttrEnum, AttrType, AttrValue,
>> ReadWrite, Entity_id) VALUES(Œimage_crc¹, 6008, 16, Œ0¹, 1, 34013184);
>> 
>> I¹m not able to get an understanding of what I might be doing wrong.
>> Please note:
>> 
>> 1.  I have successfully created EntityTbl
>> 2.  I have added n rows successfully into table this is row n+1 that
>> causes a crash
>> 3.  I know previously this group asked me to use valgrind to see if
>> the crash was elsewhere and I did that. I¹ve enclosed the results.
> 
> The valgrind output seems to indicate the problem is not in SQLite, no?
> Function get_default_database() has a buffer overrun in it.
> 
>> 
>> Thanks,
>> Kavita
>> 
>> ==28525== Memcheck, a memory error detector
>> ==28525== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward
>> et al.
>> ==28525== Using Valgrind-3.5.0 and LibVEX; rerun with -h for
>> copyright info
>> ==28525== Command: cm
>> ==28525==
>> updating hw address
>> sh: ifconfig: command not found
>> ==28525== Syscall param write(buf) points to uninitialised byte(s)
>> ==28525==at 0x62A44B: ??? (in /lib/libpthread-2.5.so)
>> ==28525==by 0x80661F3: unixWrite (in /home/kraghunathan/views/
>> sfdev-2.0/out/usr/bin/cm)
>> ==28525==by 0x805F1A3: sqlite3OsWrite (in /home/kraghunathan/
>> views/sfdev-2.0/out/usr/bin/cm)
>> ==28525==by 0x8069E19: writeJournalHdr (in /home/kraghunathan/
>> views/sfdev-2.0/out/usr/bin/cm)
>> ==28525==by 0x806D416: pager_open_journal (in /home/kraghunathan/
>> views/sfdev-2.0/out/usr/bin/cm)
>> ==28525==by 0x806D4E1: sqlite3PagerBegin (in /home/kraghunathan/
>> views/sfdev-2.0/out/usr/bin/cm)
>> ==28525==by 0x8071BB3: sqlite3BtreeBeginTrans (in /home/
>> kraghunathan/views/sfdev-2.0/out/usr/bin/cm)
>> ==28525==by 0x80852F5: sqlite3VdbeExec (in /home/kraghunathan/
>> views/sfdev-2.0/out/usr/bin/cm)
>> ==28525==by 0x808084F: sqlite3Step (in /home/kraghunathan/views/
>> sfdev-2.0/out/usr/bin/cm)
>> ==28525==by 0x8080A00: sqlite3_step (in /home/kraghunathan/views/
>> sfdev-2.0/out/usr/bin/cm)
>> ==28525==by 0x80C2866: sf_database_mgr::set_cache_size(sqlite3*,
>> int) (in /home/kraghunathan/views/sfdev-2.0/out/usr/bin/cm)
>> ==28525==by 0x80C2AF4:
>> sf_database_mgr::create_database(sqlite3**, char const*) (in /home/
>> kraghunathan/views/sfdev-2.0/out/usr/bin/cm)
>> ==28525==  Address 0x40757b9 is 9 bytes inside a block of size 2,056
>> alloc'd
>> ==28525==at 0x4005903: malloc (vg_replace_malloc.c:195)
>> ==28525==by 0x805F746: sqlite3MemMalloc (in /home/kraghunathan/
>> views/sfdev-2.0/out/usr/bin/cm)
>> ==28525==by 0x8060062: mallocWithAlarm (in /home/kraghunathan/
>> views/sfdev-2.0/out/usr/bin/cm)
>> ==28525==by 0x806010A: sqlite3Malloc (in /home/kraghunathan/
>> views/sfdev-2.0/out/usr/bin/cm)
>> ==28525==by 0x80683CD: pcache1Alloc (in /home/kraghunathan/views/
>> sfdev-2.0/out/usr/bin/cm)
>> ==28525==by 0x8068541: sqlite3PageMalloc (in /home/kraghunathan/
>> views/sfdev-2.0/out/usr/bin/cm)
>> ==28525==by 0x806BA08: sqlite3PagerSetPagesize (in /home/
>> kraghunathan/views/sfdev-2.0/out/usr/bin/cm)
>> ==28525==by 0x80713A2: sqlite3BtreeSetPageSize (in /home/
>> kraghunathan/views/sfdev-2.0/out/usr/bin/cm)
>> ==28525==by 0x80A3BF5: sqlite3Pragma (in /home/kraghunathan/
>> views/sfdev-2.0/out/usr/bin/cm)
>> ==28525==by 0x80BDA6A: yy_reduce (in /home/kraghunathan/views/
>> sfdev-2.0/out/usr/bin/cm)
>> ==28525==by 0x80BE3CF: sqlite3Parser (in /home/kraghunathan/
>> views/sfdev-2.0/out/usr/bin/cm)
>> ==28525==by 0x80BF01E: sqlite3RunParser (in /home/kraghunathan/
>> views/sfdev-2.0/out/usr/bin/cm)
>> ==28525==
>> ==28525== Use of uninitialised value of size 4
>> ==28525==at 0x4007D3C: strcpy (mc_replace_strmem.c:303)
>> ==28525==by 0x804FEB9:
>> fls_entity::get_default_database(sf_db_tbl_t**) (in /home/
>> kraghunathan/views/sfdev-2.0/out/usr/bin/cm)
>> ==28525==by 0x804B4E6:
>> cm_entity_manager::update_entity_database(sf_entity*) (in /home/
>> kraghunathan/views/sfdev-2.0/out/usr/bin/cm)
>> ==28525==by 0x804B601:
>> cm_entity_manager::update_entity_database() (in /home/kraghunathan/
>> views/sfdev-2.0/out/usr/bin/cm)
>> ==28525==by 0x804BB59:
>> cm_entity_manager::do_init_database(char*) (in /home/kraghunathan/
>> views/sfdev-2.0/out/usr/bin/cm)
>> ==28525==by 0x804BCDC: cm_entity_manager::cm_entity_manager()
>> (in /home/kraghunathan/views/sfdev-2.0/out/usr/bin/cm)
>> ==28525==by 0x80499FD: main (in /home/kraghunathan/views/
>> sfdev-2.0/out/usr/bin/cm)
>> ==28525==
>> ==28525== Invalid write of size 1
>> ==28525==at 0x4007D3C: strcpy (mc_replace_strmem.c:303)
>> ==28525==by 0x804FEB9:
>> fls_entity::get_def

Re: [sqlite] Crash inside sqlite3_step

[Dan Kennedy]

On Jan 26, 2010, at 6:16 AM, Kavita Raghunathan wrote:

> Following Sql query crashes in allocateCursor inside of sqlite3_step
>
> INSERT INTO EntityTbl (AttrName, AttrEnum, AttrType, AttrValue,  
> ReadWrite, Entity_id) VALUES(‘image_crc’, 6008, 16, ‘0’, 1, 34013184);
>
> I’m not able to get an understanding of what I might be doing wrong.
> Please note:
>
> 1.  I have successfully created EntityTbl
> 2.  I have added n rows successfully into table this is row n+1 that  
> causes a crash
> 3.  I know previously this group asked me to use valgrind to see if  
> the crash was elsewhere and I did that. I’ve enclosed the results.

The valgrind output seems to indicate the problem is not in SQLite, no?
Function get_default_database() has a buffer overrun in it.

>
> Thanks,
> Kavita
>
> ==28525== Memcheck, a memory error detector
> ==28525== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward  
> et al.
> ==28525== Using Valgrind-3.5.0 and LibVEX; rerun with -h for  
> copyright info
> ==28525== Command: cm
> ==28525==
> updating hw address
> sh: ifconfig: command not found
> ==28525== Syscall param write(buf) points to uninitialised byte(s)
> ==28525==at 0x62A44B: ??? (in /lib/libpthread-2.5.so)
> ==28525==by 0x80661F3: unixWrite (in /home/kraghunathan/views/ 
> sfdev-2.0/out/usr/bin/cm)
> ==28525==by 0x805F1A3: sqlite3OsWrite (in /home/kraghunathan/ 
> views/sfdev-2.0/out/usr/bin/cm)
> ==28525==by 0x8069E19: writeJournalHdr (in /home/kraghunathan/ 
> views/sfdev-2.0/out/usr/bin/cm)
> ==28525==by 0x806D416: pager_open_journal (in /home/kraghunathan/ 
> views/sfdev-2.0/out/usr/bin/cm)
> ==28525==by 0x806D4E1: sqlite3PagerBegin (in /home/kraghunathan/ 
> views/sfdev-2.0/out/usr/bin/cm)
> ==28525==by 0x8071BB3: sqlite3BtreeBeginTrans (in /home/ 
> kraghunathan/views/sfdev-2.0/out/usr/bin/cm)
> ==28525==by 0x80852F5: sqlite3VdbeExec (in /home/kraghunathan/ 
> views/sfdev-2.0/out/usr/bin/cm)
> ==28525==by 0x808084F: sqlite3Step (in /home/kraghunathan/views/ 
> sfdev-2.0/out/usr/bin/cm)
> ==28525==by 0x8080A00: sqlite3_step (in /home/kraghunathan/views/ 
> sfdev-2.0/out/usr/bin/cm)
> ==28525==by 0x80C2866: sf_database_mgr::set_cache_size(sqlite3*,  
> int) (in /home/kraghunathan/views/sfdev-2.0/out/usr/bin/cm)
> ==28525==by 0x80C2AF4:  
> sf_database_mgr::create_database(sqlite3**, char const*) (in /home/ 
> kraghunathan/views/sfdev-2.0/out/usr/bin/cm)
> ==28525==  Address 0x40757b9 is 9 bytes inside a block of size 2,056  
> alloc'd
> ==28525==at 0x4005903: malloc (vg_replace_malloc.c:195)
> ==28525==by 0x805F746: sqlite3MemMalloc (in /home/kraghunathan/ 
> views/sfdev-2.0/out/usr/bin/cm)
> ==28525==by 0x8060062: mallocWithAlarm (in /home/kraghunathan/ 
> views/sfdev-2.0/out/usr/bin/cm)
> ==28525==by 0x806010A: sqlite3Malloc (in /home/kraghunathan/ 
> views/sfdev-2.0/out/usr/bin/cm)
> ==28525==by 0x80683CD: pcache1Alloc (in /home/kraghunathan/views/ 
> sfdev-2.0/out/usr/bin/cm)
> ==28525==by 0x8068541: sqlite3PageMalloc (in /home/kraghunathan/ 
> views/sfdev-2.0/out/usr/bin/cm)
> ==28525==by 0x806BA08: sqlite3PagerSetPagesize (in /home/ 
> kraghunathan/views/sfdev-2.0/out/usr/bin/cm)
> ==28525==by 0x80713A2: sqlite3BtreeSetPageSize (in /home/ 
> kraghunathan/views/sfdev-2.0/out/usr/bin/cm)
> ==28525==by 0x80A3BF5: sqlite3Pragma (in /home/kraghunathan/ 
> views/sfdev-2.0/out/usr/bin/cm)
> ==28525==by 0x80BDA6A: yy_reduce (in /home/kraghunathan/views/ 
> sfdev-2.0/out/usr/bin/cm)
> ==28525==by 0x80BE3CF: sqlite3Parser (in /home/kraghunathan/ 
> views/sfdev-2.0/out/usr/bin/cm)
> ==28525==by 0x80BF01E: sqlite3RunParser (in /home/kraghunathan/ 
> views/sfdev-2.0/out/usr/bin/cm)
> ==28525==
> ==28525== Use of uninitialised value of size 4
> ==28525==at 0x4007D3C: strcpy (mc_replace_strmem.c:303)
> ==28525==by 0x804FEB9:  
> fls_entity::get_default_database(sf_db_tbl_t**) (in /home/ 
> kraghunathan/views/sfdev-2.0/out/usr/bin/cm)
> ==28525==by 0x804B4E6:  
> cm_entity_manager::update_entity_database(sf_entity*) (in /home/ 
> kraghunathan/views/sfdev-2.0/out/usr/bin/cm)
> ==28525==by 0x804B601:  
> cm_entity_manager::update_entity_database() (in /home/kraghunathan/ 
> views/sfdev-2.0/out/usr/bin/cm)
> ==28525==by 0x804BB59:  
> cm_entity_manager::do_init_database(char*) (in /home/kraghunathan/ 
> views/sfdev-2.0/out/usr/bin/cm)
> ==28525==by 0x804BCDC: cm_entity_manager::cm_entity_manager()  
> (in /home/kraghunathan/views/sfdev-2.0/out/usr/bin/cm)
> ==28525==by 0x80499FD: main (in /home/kraghunathan/views/ 
> sfdev-2.0/out/usr/bin/cm)
> ==28525==
> ==28525== Invalid write of size 1
> ==28525==at 0x4007D3C: strcpy (mc_replace_strmem.c:303)
> ==28525==by 0x804FEB9:  
> fls_entity::get_default_database(sf_db_tbl_t**) (in /home/ 
> kraghunathan/views/sfdev-2.0/out/usr/bin/cm)
> ==28525==by 0x804B4E6:  
> cm_entity_manager::update_entity_database(sf_entity*) (in /home/ 
> kraghunathan/v

Re: [sqlite] Crash on freeing mutex in sqlite3.c

[Keith Roberts]

On Tue, 20 Oct 2009, Pavel Ivanov wrote:

> To: General Discussion of SQLite Database 
> From: Pavel Ivanov 
> Subject: Re: [sqlite] Crash on freeing mutex in sqlite3.c
> 
> When I say "path ... completely irrelevant" it means path doesn't
> cause the error and it doesn't matter at all what path you're giving -
> you can pass an empty path and the error will still persist.
>
> ddd or gdb or whatever debugger you use - it doesn't show you memory
> access errors in your program (I heard totalview can do something like
> that but I didn't try that). But if you run your program under
> valgrind it will show you those types of errors. So go ahead and do
> it.
>
> Pavel

Eclipse and the CDT plugin allows you to look into memory 
locations in C/C++ if that helps. Not quite the same as 
valgrind does, but may be of some use.

Check out the fourth one down on this page, for the C 
development tools:

http://www.eclipse.org/downloads/

Kind Regards,

Keith Roberts

-
Websites:
http://www.php-debuggers.net
http://www.karsites.net
http://www.raised-from-the-dead.org.uk

All email addresses are challenge-response protected with
TMDA [http://tmda.net]
-
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Crash on freeing mutex in sqlite3.c

[Kavita Raghunathan]

Pavel, You're the man! If you are ever in Dallas let me know, I owe you lunch.

Found my bug using valgrind and it had nothing to do with the mutex or sqlite.

Kavita

- Original Message -
From: "Pavel Ivanov" 
To: "General Discussion of SQLite Database" 
Sent: Tuesday, October 20, 2009 3:24:59 PM GMT -06:00 US/Canada Central
Subject: Re: [sqlite] Crash on freeing mutex in sqlite3.c

When I say "path ... completely irrelevant" it means path doesn't
cause the error and it doesn't matter at all what path you're giving -
you can pass an empty path and the error will still persist.

ddd or gdb or whatever debugger you use - it doesn't show you memory
access errors in your program (I heard totalview can do something like
that but I didn't try that). But if you run your program under
valgrind it will show you those types of errors. So go ahead and do
it.

Pavel

On Tue, Oct 20, 2009 at 4:18 PM, Kavita Raghunathan
 wrote:
> I'm using ddd, its the GUI version of gdb.
>
> Are you saying that the file pathname is wrong ? When you say
>  "path give to sqlite is completely irrelevant" do you mean "db_filename"?
> I printed this path out using the debugger and it looks correct.
>
> And you are correct, it does die in sqlite3_initialize while trying to free
> the mutex pointer but the allocation of the pointer succeeds. So still lost.
>
> - Original Message -
> From: "Pavel Ivanov" 
> To: "General Discussion of SQLite Database" 
> Sent: Tuesday, October 20, 2009 3:06:01 PM GMT -06:00 US/Canada Central
> Subject: Re: [sqlite] Crash on freeing mutex in sqlite3.c
>
> The only place I see this line in SQLite's code is
> sqlite3_initialize(). So your path given to sqlite3_open_v2() is
> completely irrelevant and FTR no other process "can have a mutex" so
> that it will lead to crash of your process. The problem is that your
> application corrupts memory. Run it under valgrind and see where the
> problem is.
>
> Pavel
>
> On Tue, Oct 20, 2009 at 3:25 PM, Kavita Raghunathan
>  wrote:
>> Although i have successfully opened the database several times,
>> today I'm seeing crashes on this line when I use sqlite3_open_v2:
>>
>> sqlite3_mutex_free(sqlite3GlobalConfig.pInitMutex);
>>
>> Any ideas what I could be doing wrong to cause this crash ?
>>
>> Here is the exact way I'm using this C wrapper:
>> sqlite3_open_v2(db_filename, &EntityDB, 
>> SQLITE_OPEN_READWRITE|SQLITE_OPEN_FULLMUTEX, NULL)
>>
>>
>> Things I've already tried:
>> 1) Killed any processes that are still running that might have the mutex
>> 2) Checked to see if I have a valid file name and path, I'm using /tmp/abc.db
>>
>> Thanks,
>> Kavita
>>
>> ___
>> 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-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-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Crash on freeing mutex in sqlite3.c

[Kavita Raghunathan]

ok, thanks, will try that.

- Original Message -
From: "Pavel Ivanov" 
To: "General Discussion of SQLite Database" 
Sent: Tuesday, October 20, 2009 3:24:59 PM GMT -06:00 US/Canada Central
Subject: Re: [sqlite] Crash on freeing mutex in sqlite3.c

When I say "path ... completely irrelevant" it means path doesn't
cause the error and it doesn't matter at all what path you're giving -
you can pass an empty path and the error will still persist.

ddd or gdb or whatever debugger you use - it doesn't show you memory
access errors in your program (I heard totalview can do something like
that but I didn't try that). But if you run your program under
valgrind it will show you those types of errors. So go ahead and do
it.

Pavel

On Tue, Oct 20, 2009 at 4:18 PM, Kavita Raghunathan
 wrote:
> I'm using ddd, its the GUI version of gdb.
>
> Are you saying that the file pathname is wrong ? When you say
>  "path give to sqlite is completely irrelevant" do you mean "db_filename"?
> I printed this path out using the debugger and it looks correct.
>
> And you are correct, it does die in sqlite3_initialize while trying to free
> the mutex pointer but the allocation of the pointer succeeds. So still lost.
>
> - Original Message -
> From: "Pavel Ivanov" 
> To: "General Discussion of SQLite Database" 
> Sent: Tuesday, October 20, 2009 3:06:01 PM GMT -06:00 US/Canada Central
> Subject: Re: [sqlite] Crash on freeing mutex in sqlite3.c
>
> The only place I see this line in SQLite's code is
> sqlite3_initialize(). So your path given to sqlite3_open_v2() is
> completely irrelevant and FTR no other process "can have a mutex" so
> that it will lead to crash of your process. The problem is that your
> application corrupts memory. Run it under valgrind and see where the
> problem is.
>
> Pavel
>
> On Tue, Oct 20, 2009 at 3:25 PM, Kavita Raghunathan
>  wrote:
>> Although i have successfully opened the database several times,
>> today I'm seeing crashes on this line when I use sqlite3_open_v2:
>>
>> sqlite3_mutex_free(sqlite3GlobalConfig.pInitMutex);
>>
>> Any ideas what I could be doing wrong to cause this crash ?
>>
>> Here is the exact way I'm using this C wrapper:
>> sqlite3_open_v2(db_filename, &EntityDB, 
>> SQLITE_OPEN_READWRITE|SQLITE_OPEN_FULLMUTEX, NULL)
>>
>>
>> Things I've already tried:
>> 1) Killed any processes that are still running that might have the mutex
>> 2) Checked to see if I have a valid file name and path, I'm using /tmp/abc.db
>>
>> Thanks,
>> Kavita
>>
>> ___
>> 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-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-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Crash on freeing mutex in sqlite3.c

[Pavel Ivanov]

When I say "path ... completely irrelevant" it means path doesn't
cause the error and it doesn't matter at all what path you're giving -
you can pass an empty path and the error will still persist.

ddd or gdb or whatever debugger you use - it doesn't show you memory
access errors in your program (I heard totalview can do something like
that but I didn't try that). But if you run your program under
valgrind it will show you those types of errors. So go ahead and do
it.

Pavel

On Tue, Oct 20, 2009 at 4:18 PM, Kavita Raghunathan
 wrote:
> I'm using ddd, its the GUI version of gdb.
>
> Are you saying that the file pathname is wrong ? When you say
>  "path give to sqlite is completely irrelevant" do you mean "db_filename"?
> I printed this path out using the debugger and it looks correct.
>
> And you are correct, it does die in sqlite3_initialize while trying to free
> the mutex pointer but the allocation of the pointer succeeds. So still lost.
>
> - Original Message -
> From: "Pavel Ivanov" 
> To: "General Discussion of SQLite Database" 
> Sent: Tuesday, October 20, 2009 3:06:01 PM GMT -06:00 US/Canada Central
> Subject: Re: [sqlite] Crash on freeing mutex in sqlite3.c
>
> The only place I see this line in SQLite's code is
> sqlite3_initialize(). So your path given to sqlite3_open_v2() is
> completely irrelevant and FTR no other process "can have a mutex" so
> that it will lead to crash of your process. The problem is that your
> application corrupts memory. Run it under valgrind and see where the
> problem is.
>
> Pavel
>
> On Tue, Oct 20, 2009 at 3:25 PM, Kavita Raghunathan
>  wrote:
>> Although i have successfully opened the database several times,
>> today I'm seeing crashes on this line when I use sqlite3_open_v2:
>>
>> sqlite3_mutex_free(sqlite3GlobalConfig.pInitMutex);
>>
>> Any ideas what I could be doing wrong to cause this crash ?
>>
>> Here is the exact way I'm using this C wrapper:
>> sqlite3_open_v2(db_filename, &EntityDB, 
>> SQLITE_OPEN_READWRITE|SQLITE_OPEN_FULLMUTEX, NULL)
>>
>>
>> Things I've already tried:
>> 1) Killed any processes that are still running that might have the mutex
>> 2) Checked to see if I have a valid file name and path, I'm using /tmp/abc.db
>>
>> Thanks,
>> Kavita
>>
>> ___
>> 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-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