Re: [sqlite] bug report (INSTR() ignores NOCASE on columns)

Stephan Senzel, on Sunday, February 2, 2020 08:12 AM, wrote... > > INSTR() ignores NOCASE on columns > > --- > > example: > > SELECT * FROM table WHERE INSTR(column, ' castle ') > 0 > > returns datasets with 'castle' only, without 'Castle', even if the > column is set to

[sqlite] bug report (INSTR() ignores NOCASE on columns)

INSTR() ignores NOCASE on columns --- example: SELECT * FROM table WHERE INSTR(column, ' castle ') > 0 returns datasets with 'castle' only, without 'Castle', even if the column is set to NOCASE --- LIKE doesn't have this problem, works well SELECT

Re: [sqlite] Bug report: Potential thread safety issues in sqlite3_initialize

As I understand it, the barrier in that patch ensures that for whichever thread executes the if(!sqlite3GlobalConfig.mutex.xMutexAlloc codepath) {...}, the write to pTo->xMutexAlloc will be stored after the rest of the xMutex* field writes. But there's nothing preventing another thread *loading*

Re: [sqlite] Bug report: Potential thread safety issues in sqlite3_initialize

On 1/28/20, Oystein Eftevaag wrote: > in sqlite3MutexInit() sqlite3GlobalConfig.mutex.xMutexAlloc > can be read as being set on a core, while the rest of the initialization > done in sqlite3MutexInit() still is being read as unset. Doesn't the memory barrier at

[sqlite] Bug report: Potential thread safety issues in sqlite3_initialize

Hi folks, Data races in sqlite3_initialize was previously reported in https://www.mail-archive.com/sqlite-users@mailinglists.sqlite.org/msg94225.html and a fix landed, however while investigating internal TSan reports of this, as far as we can tell the issue is still present (on non-x86 platforms

Re: [sqlite] Bug report

On Jan 23, 2020, at 7:02 AM, Mark Benningfield wrote: > > ...whenever I do a Fossil pull of the latest > version takes a grand total of about 2 seconds, but it would be nice not to > have to remember to do it every time :) If you’re having to reapply the change on every Fossil update, you’re

Re: [sqlite] Bug report

Well, I kinda thought that this would be fixed on the next release. The "value_frombind" typo in particular prevents FTS3/4 from being built as a loadable extension. I only have one legacy application that uses FTS3/4 that way, and fixing these typos whenever I do a Fossil pull of the latest

Re: [sqlite] Bug Report

Bigthing Do, on Friday, December 27, 2019 01:56 PM, wrote... > > Dear sqlite developers: > > We met an accidental crash in sqlite with the following sample: > > CREATE VIEW table1 ( col1 , col2 ) AS WITH aaa AS ( SELECT * FROM table1 > ) SELECT col2 FROM table1 ORDER BY 1 ; > WITH aaa AS ( SELECT

Re: [sqlite] Bug Report

Hi, We tried debugging a little bit with the core dump, it crashes with a null reference actually: ` Program received signal SIGSEGV, Segmentation fault. [--registers---] RAX: 0x74 ('t') RBX: 0x782550 --> 0x76b088 --> 0x1 RCX:

Re: [sqlite] Bug Report

On Friday, 27 December, 2019 12:50, Igor Korot wrote: >On Fri, Dec 27, 2019 at 12:57 PM Bigthing Do wrote: >> We met an accidental crash in sqlite with the following sample: >> CREATE VIEW table1 ( col1 , col2 ) AS WITH aaa AS ( SELECT * FROM table1 ) >> SELECT col2 FROM table1 ORDER BY 1 ;

Re: [sqlite] Bug Report

Hi, On Fri, Dec 27, 2019 at 12:57 PM Bigthing Do wrote: > > Dear sqlite developers: > > We met an accidental crash in sqlite with the following sample: > > CREATE VIEW table1 ( col1 , col2 ) AS WITH aaa AS ( SELECT * FROM table1 ) > SELECT col2 FROM table1 ORDER BY 1 ; > WITH aaa AS ( SELECT *

[sqlite] Bug Report

Dear sqlite developers: We met an accidental crash in sqlite with the following sample: CREATE VIEW table1 ( col1 , col2 ) AS WITH aaa AS ( SELECT * FROM table1 ) SELECT col2 FROM table1 ORDER BY 1 ; WITH aaa AS ( SELECT * FROM table1 ) SELECT col1 , rank () OVER( ORDER BY col1 DESC ) FROM

[sqlite] Bug report

In version 3.30.1 ( check-in [9b14eb77] ), file "sqlite3ext.h" 618 #define sqlite3_stmt_isexplain sqlite3_api->isexplain 619 #define sqlite3_value_frombind sqlite3_api->frombind should be 618 #define sqlite3_stmt_isexplain sqlite3_api->stmt_isexplain 619 #define

Re: [sqlite] Bug report: cppcheck memory leak

On 2 Dec 2019, at 1:16am, Richard Hipp wrote: > Telling us that the > "return" from malloc() is a memory leak is not helpful information, > even if it were true. Oh, someone needs to write a story about a manager who doesn't understand computers but relies on test suites, and programmers

Re: [sqlite] Bug report: cppcheck memory leak

On 12/1/19, David Brouwer wrote: > While playing around with static code analysis with cppcheck, I ran into > the error "[modules/sqlite3_omit.c:22845]: (error) Memory leak: p". I can't > tell whether it's significant or not, but I figured I'd report it anyway. Thanks for taking the time to

[sqlite] Bug report: cppcheck memory leak

Dear, Title: Potential memory leak reported by cppcheck Version: 3.27.2 While playing around with static code analysis with cppcheck, I ran into the error "[modules/sqlite3_omit.c:22845]: (error) Memory leak: p". I can't tell whether it's significant or not, but I figured I'd report it anyway.

Re: [sqlite] Bug report

CVE will not record this bug if it doesn't affect a /released/ version of any product. One hopes that none of the products which incorporate SQLite would incorporate a version of SQLite which never received a release number. In other words, the reporters told the developer team before the bug

Re: [sqlite] Bug report

On Thu, 21 Nov 2019 21:02:57 +, Jose Isaias Cabrera wrote: >Kees Nuyt, on Thursday, November 21, 2019 03:48 PM, wrote... [...] >> >> I see no CVE entered by the OP, but maybe I missed something. > > Yes, you are right. After pasting it, I went through the top 5 > and none of these

Re: [sqlite] Bug report

Kees Nuyt, on Thursday, November 21, 2019 03:48 PM, wrote... > > > Thanks, Jose. > > I see no CVE entered by the OP, but maybe I missed something. Yes, you are right. After pasting it, I went through the top 5 and none of these aren't/weren't the one. Apologies. I thought that by searching on

Re: [sqlite] Bug report

Thanks, Jose. I see no CVE entered by the OP, but maybe I missed something. A quick look to your list : > NameDescription > CVE-2019-9937 > In SQLite 3.27.2, interleaving reads and writes in a single transaction with > an fts5

Re: [sqlite] Bug report

On 11/19/19, Yongheng Chen wrote: > Hi, > > This is Yongheng Chen from Gatech and Rui Zhong from PSU. We found 7 crashes > for sqlite of the newest commit 3842e8f166e23a1ed6e6094105e7a23502d414da. > We have attached the samples that crash sqlite in the email. FYI, we have > also reported the

Re: [sqlite] Bug report

software versions prior to v1.3.4. The underlying SQLite database query is subject to SQL injection on the username input parameter. From: sqlite-users on behalf of Kees Nuyt Sent: Thursday, November 21, 2019 09:51 AM To: sqlite-users@mailinglists.sqlite.org Subj

Re: [sqlite] Bug report

On Tue, 19 Nov 2019 00:19:13 -0500, you wrote: > Hi, > > This is Yongheng Chen from Gatech and Rui Zhong from PSU. > We found 7 crashes for sqlite of the newest commit > 3842e8f166e23a1ed6e6094105e7a23502d414da. > We have attached the samples that crash sqlite in the email. The mailing list

[sqlite] Bug report

Hi, This is Yongheng Chen from Gatech and Rui Zhong from PSU. We found 7 crashes for sqlite of the newest commit 3842e8f166e23a1ed6e6094105e7a23502d414da. We have attached the samples that crash sqlite in the email. FYI, we have also reported the bugs for CVE at cve.mitre.org

[sqlite] Bug report: DROP TABLE while a cursor is open leads to SQLITE_LOCKED

Hi, sorry for the repost. I just noticed that I probably should have added "Bug report" in the subject line. I'm using the Xerial JDBC driver for accessing SQLite (but this issue is not directly related to the driver). I have the problem that it is not possible to drop a table in the same

[sqlite] Bug report: documentation for the SQLite Android bindings should clearly call out their poor query performance

I apologize in advance if this is the wrong place to report bugs with the SQLite Android bindings, but I couldn’t figure out how to file a ticket on that subsite (https://sqlite.org/android/) and didn’t see any contact information there, so I figured I’d try here. Query performance,

Re: [sqlite] Bug report: crash when close blob handle after close_v2 db

On 14/7/62 17:18, Chaoji Li wrote: This problem is only present for 3.28+. A sample test case is attached. Thanks for reporting this. We think it's fixed here:   https://sqlite.org/src/info/52f463d29407fad6 The mailing list stripped off your test case, so if you could either run it with

Re: [sqlite] Bug report: crash when close blob handle after close_v2 db

On 14 Jul 2019, at 11:18am, Chaoji Li wrote: > This problem is only present for 3.28+. A sample test case is attached. Thank you for identifying this behaviour. I'm sure the development team will reply to your post. Attachments are automatically ignored by the mailing list. You can include

[sqlite] Bug report: crash when close blob handle after close_v2 db

This problem is only present for 3.28+. A sample test case is attached. Basically, the flow is: 1. Open in-memory db A (we don't do anything about it). 2. Open db B from file test.db 3. Create a blob handle from B 4. close_v2 A 5. close_v2 B 6. close blob handle -> Segmentation fault The

Re: [sqlite] Bug report: Segfault in sqlite3_clear_bindings when statement is nullptr

Hi, Since the last mail I sent was not really readable due to problems with my mail settings I resend the possible bug report below. I want to report a (possible) bug in sqlite3. When sqlite3_clear_bindings is called with a nullptr argument, then a SEGFAULT occurs. From the behavior of the

[sqlite] Bug report: Segfault in sqlite3_clear_bindings when statement is nullptr

Hi together, I want to report a (possible) bug in sqlite3. When sqlite3_clear_bindings is called with a nullptr argument, then a SEGFAULT occurs. From the behavior of the other methods which use statement as a parameter I expected the behaviour that sqlite3_clear_bindings with a nullptr argument

[sqlite] sqlite bug report

Summary Alter table rename to fails if the database contains a view which selects from a nonexistent table. Seen on sqlite 3.27.2. Script to reproduce it: create view view_1 as select * from table_1; create table table_2 (col_1 text, col_2 text); alter table table_2 rename to table_3; The

[sqlite] Bug report for rtree.c

If SQLITE_DEBUG is not defined, rtree.c found at https://www.sqlite.org/src/dir?ci=edb095a9a679c8c7=ext/rtree fails to compile. This is because bCorrupt is declared (at line 132) only if SQLITE_DEBUG is defined, but is referenced unconditionally at line 980. Line 980 currently is    assert(

Re: [sqlite] bug report: UPSERT / INSERT ON CONFLICT PK Autoincrement

Stanislav Zabka wrote: > When conflict occurs, no import performs, but PK is incremented nevertheless. says: | Note that "monotonically increasing" does not imply that the ROWID | always increases by exactly one. One is the usual increment. However, | if an

[sqlite] bug report: UPSERT / INSERT ON CONFLICT PK Autoincrement

UPSERT / INSERT ON CONFLICT PK Autoincrement When conflict occurs, no import performs ( as expected ), but PK is incremented nevertheless. example (focus on sqlite_sequence.seq) : run1: initial values - all ok run2: all conflict; no insert (ok) - but sqlite_sequence.seq incremented ( I would

Re: [sqlite] Bug report: Data race in pcache1.c

Hi Richard, thanks a million for your check-in! It indeed fixed our issues with TSan! Best regards, Jan On Wed, Jan 9, 2019 at 3:55 PM Richard Hipp wrote: > Check-in https://www.sqlite.org/src/info/383437be276719ac will perhaps > silence the harmless false-positives reported by TSAN. Please

Re: [sqlite] Bug Report

On 2/20/19, William ESCANDE wrote: > Hi everyone ! > > TL;DR: > with sanitizer > in func columnName (l.82210) > calling xFunc(l.82235) trigger a cfi_check (and then ABORT) > > Fix to do : > change prototype of sqlite3_value_text to let him return a `void *` There are millions and millions of

[sqlite] Bug Report

Hi everyone ! TL;DR: with sanitizer in func columnName (l.82210) calling xFunc(l.82235) trigger a cfi_check (and then ABORT) Fix to do : change prototype of sqlite3_value_text to let him return a `void *` FULL Description: I am using sqlite3.c in android system (not in NDK). I compile android

Re: [sqlite] Bug report: Data race in pcache1.c

Check-in https://www.sqlite.org/src/info/383437be276719ac will perhaps silence the harmless false-positives reported by TSAN. Please let us know if it does not solve the problem for you. On 1/7/19, Jan Krčál wrote: > Hi, > > as a Chrome developer, I've run into a data race flagged by

[sqlite] Bug report: Data race in pcache1.c

Hi, as a Chrome developer, I've run into a data race flagged by ThreadSanitizer in pcache1.c: When two threads write to in-memory sqlite DBs (each to its own separate DB), each thread has its own PCache1 with bPurgeable being false. Thus, in both threads, pCache->pnPurgeable points to the static

[sqlite] Bug report: Wrong column type retrieved from metainfo for statements with zero rows

Hi there, I have db with table as CREATE TABLE GasStats10s(GasStats10s_MaxValue REAL,GasStats10s_IntervalDuration INTEGER,GasStats10s_DataCount INTEGER,GasStats10s_MinValue REAL,GasStats10s_Value REAL,GasStats10s_DateTime INTEGER,GasStats10s_Source UID,GasStats10s_Sum REAL,Class UID,DeleteLog

Re: [sqlite] Bug report: bug in datetime conversion function

on March 1st. -Original Message- From: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] On Behalf Of Fábio Pfeifer Sent: Thursday, October 18, 2018 9:28 AM To: sqlite-users@mailinglists.sqlite.org Subject: [sqlite] Bug report: bug in datetime conversion function Hello, When

Re: [sqlite] Bug report: bug in datetime conversion function

On 18 Oct 2018, at 2:28pm, Fábio Pfeifer wrote: > When working with Apple iOS databases, I found something strange when dealing > with dates. I suspect you are you are referring to a library routine which is used by lots of iOS software, but can you give us a specific App which exhibits this

[sqlite] Bug report: bug in datetime conversion function

Hello, When working with Apple iOS databases, I found something strange when dealing with dates. Apple iOS databases store dates as seconds from 2001-01-01 (31 years after unix epoch). But from 2015-03-02 to 2016-02-29 there is a offset of one day if '31 years' modifier is used. To reproduce,

Re: [sqlite] Bug Report: corrupted double-linked list

Daniel Espinosa wrote: > Thanks for the response. > > Until now I just used GDB, cause is easy on Meson. I will try with > Valgrind, but I will be slow until I find a way to reproduce the problem. > > Just take the desition to report this bug, because just the issue trace the > fault deeply in

Re: [sqlite] Bug Report: corrupted double-linked list

Thanks for the response. Until now I just used GDB, cause is easy on Meson. I will try with Valgrind, but I will be slow until I find a way to reproduce the problem. Just take the desition to report this bug, because just the issue trace the fault deeply in the SQLite secuence of destruction,

Re: [sqlite] Bug Report: corrupted double-linked list

On 10/9/18, Daniel Espinosa wrote: > I'm current maintainer of GDA[1], I've updated embbeded version of SQLite > to 3.25.2, but I found an issue with a segfault due to a "corrupted > double-linked list". Heap corruption like this is most often the result of bugs in the application and SQLite

[sqlite] Bug Report: corrupted double-linked list

I'm current maintainer of GDA[1], I've updated embbeded version of SQLite to 3.25.2, but I found an issue with a segfault due to a "corrupted double-linked list". In order to reproduce it: a) Checkout libgda from its respository[1] b) compile using its meson: $ meson _build $ cd _build $ ninja

Re: [sqlite] Bug report: Window functions in VIEWs broken in 3.25.1

Bjoern Hoehrmann wrote: > Using the sqlite-tools-linux-x86-3250100 Linux binaries I find that > Window functions in VIEWS behave differently from PostgreSQL 9.6 and > from what I expect. > > DROP TABLE IF EXISTS example; > CREATE TABLE example(t INT, total INT); > INSERT INTO example

[sqlite] Bug report: Window functions in VIEWs broken in 3.25.1

Hi, Using the sqlite-tools-linux-x86-3250100 Linux binaries I find that Window functions in VIEWS behave differently from PostgreSQL 9.6 and from what I expect. DROP TABLE IF EXISTS example; CREATE TABLE example(t INT, total INT); INSERT INTO example VALUES(0,2); INSERT INTO example

[sqlite] Bug Report: "Is Null" where term propagated to a virtual table causes wrong query results

Hello, I have found an obscure bug in the virtual table processing. The schema looks like this: CREATE TABLE t1 (id int, value text); INSERT INTO t1 VALUES(1,'try'); CREATE TABLE t2 (ctx int, id int, value text); INSERT INTO t2 VALUES(1,1,'good'); INSERT INTO t2 VALUES(2,2,'evil'); The

Re: [sqlite] BUG REPORT

> I am using a query to check a date field between a range of dates Can you provide example values of the date in your database? Are you storing the EXACT date (eg, '2018-02-01 12:21'), or just the date? > When running this with the ODBC driver it fails to return all the appropriate record in

Re: [sqlite] BUG REPORT

On 8/15/18, Mr Max wrote: > When running this with the ODBC driver it fails to return all the > appropriate record in the range. I tried the exact same query in a DB > Browser for Sqlite and it recovers 127 records only. What answer do you get when you run your query using the

[sqlite] BUG REPORT

To whom it may concern, Whilst using an ODBC driver for SQLite acquired from: http://www.ch-werner.de/sqliteodbc/ I came across a potential bug in SQLite. I have an application running VB.NET on a Windows 7 32-bit machine and have installed the sqliteodbc.exe from the website

Re: [sqlite] Bug report

On 2/27/18, Alexander Ananin wrote: > > I've found the strange behavior in the rtree.c file. Are you trying to compile rtree.c separately, rather than using the version that is bundled into the sqlite3.c amalgmation? May I ask why you want to do that? -- D. Richard Hipp

[sqlite] Bug report

Hi, Support, I've found the strange behavior in the rtree.c file. I think that in the static int writeInt64(u8 *p, i64 i) function. static int writeInt64(u8 *p, i64 i){ #if SQLITE_BYTEORDER==1234 && GCC_VERSION>=4003000 i = (i64)__builtin_bswap64((u64)i); memcpy(p, , 8); #elif

[sqlite] Bug report in sqlite/shell.c:3766 tableColumnList

Hi guys, A bug exists in sqlite/shell.c:3766 tableColumnList in the newest tarball. Here is the url of the proof of concept: https://github.com/Ha0Team/crash-of-sqlite3/blob/master/poc.md Thanks. ___ sqlite-users mailing list

Re: [sqlite] Bug Report: Crash When Loading Short Journal

On 9/6/17, Natalie Silvanovich wrote: > I'm experiencing a crash when loading a database with a corrupt journal > file. The chances of hitting the problem by accident are remote - so much so that it is impossible in practice. This problem can only come up if an adversary

[sqlite] Bug Report: Crash When Loading Short Journal

Hi, I'm experiencing a crash when loading a database with a corrupt journal file. The error occurs in readMasterJournal in the following code: │48741 if( SQLITE_OK!=(rc = sqlite3OsFileSize(pJrnl, )) │48742 || szJ<16 │48743 || SQLITE_OK!=(rc = read32bits(pJrnl, szJ-16, )) │48744

Re: [sqlite] Bug report: Wrong column name in a table in a certain case

Now fixed on trunk. On 8/11/17, Jürgen Palm wrote: > Hi, > > please have a look at the following sequence of statements executed on > Windows 10 with sqlite3.exe, version 3.19.3 and 3.20.0: > > CREATE TABLE test("column with space" TEXT); > CREATE TABLE test2 AS SELECT

Re: [sqlite] Bug report: Wrong column name in a table in a certain case

Most probably not a bug. I asked something similar a while ago. It's as easy as https://sqlite.org/faq.html#q28 . As long as you don't explicitly assign an alias to a column name, sqlite is not guaranteed to return what you might expect. Am 11.08.2017 um 22:52 schrieb Jürgen Palm: Hi,

[sqlite] Bug report: Wrong column name in a table in a certain case

Hi, please have a look at the following sequence of statements executed on Windows 10 with sqlite3.exe, version 3.19.3 and 3.20.0: CREATE TABLE test("column with space" TEXT); CREATE TABLE test2 AS SELECT "column with space" FROM test; CREATE TABLE test3 AS SELECT "column with space" FROM

Re: [sqlite] Bug Report: https://www.sqlite.org/chronology.html out of date

I think it depends on what Tom means by the "latest release". The chronology shows the "latest" in chronological order. But the latest in chronological order is not necessary the same as the latest in logical order. In other words, perhaps Tom is assuming that release numbers are monotonically

Re: [sqlite] Bug Report: https://www.sqlite.org/chronology.html out of date

On 20 June 2017 at 07:55, Tom Ritter wrote: > In lieu of an official support RSS feed, > https://www.sqlite.org/chronology.html is used to detect new versions > of SQLite and how out of date the current one embedded in a product > is. It worked for the past several months, but now

[sqlite] Bug Report: https://www.sqlite.org/chronology.html out of date

In lieu of an official support RSS feed, https://www.sqlite.org/chronology.html is used to detect new versions of SQLite and how out of date the current one embedded in a product is. It worked for the past several months, but now this page is out of date. =) -tom

Re: [sqlite] [BUG REPORT] Open blob is invalidated by the update to unrelated fields in the same row

On Mon, Mar 6, 2017 at 3:39 AM, Yuri wrote: > On 03/06/2017 01:00, Dominique Devienne wrote: > >> This is clearly documented inhttps://www.sqlite.org/c3ref/blob_open.html >> though, so I'm afraid this is "by design". --DD >> > > > Even though this is documented, parts of this

Re: [sqlite] [BUG REPORT] Open blob is invalidated by the update to unrelated fields in the same row

Yuri wrote: > Updating an integer field in the same row shouldn't affect the blob field. Integer fields have a variable size (0 to 8 bytes): http://www.sqlite.org/fileformat2.html#record_format Regards, Clemens ___ sqlite-users mailing list

Re: [sqlite] [BUG REPORT] Open blob is invalidated by the update to unrelated fields in the same row

<sqlite-users@mailinglists.sqlite.org> Betreff: Re: [sqlite] [BUG REPORT] Open blob is invalidated by the update to unrelated fields in the same row On 03/06/2017 01:00, Dominique Devienne wrote: > This is clearly documented > inhttps://www.sqlite.org/c3ref/blob_open.html > though

Re: [sqlite] [BUG REPORT] Open blob is invalidated by the update to unrelated fields in the same row

On Mon, Mar 6, 2017 at 11:39 AM, Yuri wrote: > On 03/06/2017 01:00, Dominique Devienne wrote: > >> This is clearly documented inhttps://www.sqlite.org/c3ref/blob_open.html >> though, so I'm afraid this is "by design". --DD >> > > Even though this is documented, parts of this

Re: [sqlite] [BUG REPORT] Open blob is invalidated by the update to unrelated fields in the same row

On 03/06/2017 01:00, Dominique Devienne wrote: This is clearly documented inhttps://www.sqlite.org/c3ref/blob_open.html though, so I'm afraid this is "by design". --DD Even though this is documented, parts of this limitation don't appear to be reasonable. Updating an integer field in the

Re: [sqlite] [BUG REPORT] Open blob is invalidated by the update to unrelated fields in the same row

On Sat, Mar 4, 2017 at 8:21 AM, Yuri wrote: > The write operation using the open sqlite3_blob object fails after some > other field in the same row is updated. > This is clearly documented in https://www.sqlite.org/c3ref/blob_open.html though, so I'm afraid this is "by design".

[sqlite] [BUG REPORT] Open blob is invalidated by the update to unrelated fields in the same row

The write operation using the open sqlite3_blob object fails after some other field in the same row is updated. The testcase below illustrates the problem. Yuri ---testcase--- #include #include #include "sqlite3.h" int main(int argc, char **argv) { if(argc < 2) {

Re: [sqlite] Bug report: Incorrect error information if db fails to open due to bad flags

On 01/13/2017 06:25 AM, Jens Alfke wrote: I’ve found a case where incorrect error information gets reported to client C code trying to open a SQLite database. (This is with SQLite 3.14 on mac OS 10.12.) After the following C code runs (the path here is irrelevant): sqlite3 *db;

[sqlite] Bug report: Incorrect error information if db fails to open due to bad flags

I’ve found a case where incorrect error information gets reported to client C code trying to open a SQLite database. (This is with SQLite 3.14 on mac OS 10.12.) After the following C code runs (the path here is irrelevant): sqlite3 *db; int ret = sqlite3_open_v2("/tmp/foo", ,

Re: [sqlite] Bug report + fix: SQLite 3.11+ broken on EBCDIC systems

On Mon, Dec 12, 2016 at 9:30 PM, Bradford Larsen wrote: > An alternative possibility would be to revert to the pre-3.11 tokenizer on > EBCDIC systems. If I recall, the old tokenizer used a big switch statement > with character literals instead of the 'aiClass' table. I

Re: [sqlite] Bug report + fix: SQLite 3.11+ broken on EBCDIC systems

> > On Sun, Dec 11, 2016 at 20:42 Richard Hipp wrote: > > SQLite only uses the "[" character as a compatibility quoting > > mechanism for SQL Server. Maybe the solution is for [...] quoting to > > simply not work on EBCDIC systems? > > > > -- > > D. Richard Hipp > >

Re: [sqlite] Bug report + fix: SQLite 3.11+ broken on EBCDIC systems

SQLite only uses the "[" character as a compatibility quoting mechanism for SQL Server. Maybe the solution is for [...] quoting to simply not work on EBCDIC systems? -- D. Richard Hipp d...@sqlite.org ___ sqlite-users mailing list

Re: [sqlite] Bug report + fix: SQLite 3.11+ broken on EBCDIC systems

On Dec 11, 2016, at 4:57 PM, Richard Hipp wrote: > I agree with most of your changes. But I wonder about moving the > QUOTE2 (the '[' character) value from code 0xba over to 0xad. > According to EBCDIC chart at https://en.wikipedia.org/wiki/EBCDIC the > '[' character should be

Re: [sqlite] Bug report + fix: SQLite 3.11+ broken on EBCDIC systems

> On Dec 11, 2016, at 7:57 PM, Richard Hipp wrote: > > On 12/11/16, Bradford Larsen wrote: > >> #endif >> #ifdef SQLITE_EBCDIC >> /* x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xa xb xc xd xe xf */ >> /* 0x */ 27, 27, 27, 27, 27, 7, 27, 27,

Re: [sqlite] Bug report + fix: SQLite 3.11+ broken on EBCDIC systems

On 12/11/16, Bradford Larsen wrote: > #endif > #ifdef SQLITE_EBCDIC > /* x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xa xb xc xd xe xf */ > /* 0x */ 27, 27, 27, 27, 27, 7, 27, 27, 27, 27, 27, 27, 7, 7, 27, 27, > /* 1x */ 27, 27, 27, 27, 27, 27, 27, 27, 27,

[sqlite] Bug report + fix: SQLite 3.11+ broken on EBCDIC systems

SQLite has built-in support for EBCDIC-based systems, but I discovered that it’s been broken since 3.11.0. If you have an EBCDIC-based system, you can see the brokenness by firing up `sqlite` and trying the `.schema` metacommand – you’ll get an obscure error. In detail, in February 2016,

Re: [sqlite] Bug report: Incorrect output of a LEFT JOIN with row-values in expression

On 10/26/16, Ján Hric wrote: > Hello > I would like to report a bug in the latest version of SQLite (3.15.0). Thanks for a very clear and succinct bug report. Well done! The ticket is here: https://www.sqlite.org/src/tktview/fef4bb4bd9185ec8f18d9912abb444da61d02ff2 > >

[sqlite] Bug report: Incorrect output of a LEFT JOIN with row-values in expression

Hello I would like to report a bug in the latest version of SQLite (3.15.0). Description: If comparison of row-values is used in the expression of a LEFT JOIN clause and no mach is found, instead of one row with values from the left-hand table, no rows are returned. Example code: CREATE TABLE

Re: [sqlite] [BUG REPORT] Transaction that has the key violation is very slow

On 09/21/2016 04:34 AM, Yuri wrote: I import bulk data into SQLite DB. I run 50k records per transaction. When some bug or data inconsistency occurs and causes the key violation, this violation is reported only in the end of the transaction (this is okay and has been discussed before). But

[sqlite] [BUG REPORT] Transaction that has the key violation is very slow

I import bulk data into SQLite DB. I run 50k records per transaction. When some bug or data inconsistency occurs and causes the key violation, this violation is reported only in the end of the transaction (this is okay and has been discussed before). But I also notice that the transaction

Re: [sqlite] Bug Report: All database opening blocked awaiting wal index rebuild

I've reproduced the issue using both SERIALIZED and MULTITHREADED modes. The issue here doesn't seem to have anything to do with the threading modes. The issue is related to shared caches, and waiting on a b-tree lock while holding the global SQLITE_MUTEX_STATIC_OPEN lock. - Brian Vincent On

Re: [sqlite] Bug Report: All database opening blocked awaiting wal index rebuild

> Le 11 juil. 2016 à 21:57, Brian Vincent a écrit : > > Yes, you seem to understand the issue. The issue only happens when using > shared caches. > > I've reproduced the issue using both SERIALIZED and MULTITHREADED modes. > ... > Being an inherit limitation would seem to

Re: [sqlite] Bug Report: All database opening blocked awaiting wal index rebuild

Yes, you seem to understand the issue. The issue only happens when using shared caches. I've reproduced the issue using both SERIALIZED and MULTITHREADED modes. I'm surprised to hear you say that it might be an inherit limitation or something not necessarily undesirable. Of course, when using

Re: [sqlite] Bug Report: All database opening blocked awaiting wal index rebuild

> Le 9 juil. 2016 à 12:33, Simon Slavin a écrit : > >> I'm really interested in knowing wether you use the engine in SERIALIZED or >> MULTITHREADED mode during this event reproduction? > > In other words, please read the last part of > >

Re: [sqlite] Bug Report: All database opening blocked awaiting wal index rebuild

On 9 Jul 2016, at 9:27am, Olivier Mascia wrote: > I'm really interested in knowing wether you use the engine in SERIALIZED or > MULTITHREADED mode during this event reproduction? In other words, please read the last part of and try

Re: [sqlite] Bug Report: All database opening blocked awaiting wal index rebuild

> Le 9 juil. 2016 à 00:55, Brian Vincent a écrit : > > I've managed to reproduce a scenario where one database, database1.db is > rebuilding a large wal-index. Meanwhile, all other threads attempting to > open completely unrelated databases (e.g. database2.db) are blocked

[sqlite] Bug Report: All database opening blocked awaiting wal index rebuild

I've managed to reproduce a scenario where one database, database1.db is rebuilding a large wal-index. Meanwhile, all other threads attempting to open completely unrelated databases (e.g. database2.db) are blocked until the wal-index on database1.db is finished rebuilding. This is obviously

Re: [sqlite] bug report (security)

Hi Richard, Thanks for getting back to me. I agree it seems like the same bug. Best regards, j- On Sat, May 28, 2016 at 4:19 AM, Richard Hipp wrote: > On 5/27/16, Jonathan Brossard wrote: > > > > I'd like to report a heap overflow, please find an

Re: [sqlite] bug report (security)

On 5/27/16, Jonathan Brossard wrote: > > I'd like to report a heap overflow, please find an advisory attached to > this email. > Thanks of the bug report. I am unable to reproduce the heap overflow. Nevertheless, it looks like this problem may have been addressed by

Re: [sqlite] bug report (2/2) [security]

On 5/27/16, Jonathan Brossard wrote: > > Please find attached a second bug report for a use after free() in sqlite. > Thank you for the bug report. This problem (in the command-line shell, not in SQLite itself) has already been fixed, specifically by check-in

[sqlite] bug report (2/2) [security]

Dear Sqlite team, Please find attached a second bug report for a use after free() in sqlite. Kindest regards, j- --- * * * Sqlite3 use

[sqlite] bug report (security)

Dear Sqlite team, I hope this email finds you well. I'd like to report a heap overflow, please find an advisory attached to this email. Best regards, j- --- *

[sqlite] sqlite bug report

Bug report I downloaded sqlite 3.10.0 released in 2016-1-6, earlier I downloaded sqlite 3.9.2 and earlier version. I found below 2 bugs: bug1: Database directory which contains Simplified Chinese Character not support. bug2: Simplified Chinese Character in database table display error. bug1:

[sqlite] Bug report for MAX()

Many thanks to all. I should have checked - That table was not supposed to be able to even get strings in there - this exposed a bug in an application of ours too. Adding check constraints right away. Thanks! On 2015/11/25 1:56 PM, Richard Hipp wrote: > On 11/25/15, Dave McKee wrote: >> I

[sqlite] Bug report for MAX()

It seems there are some instances where MAX() does not return a value. I will send such an offending DB direct, but the sqlite3.exe results as follows: F:\[BACKUP]>sqlite3.exe IPDB_ImptData.idb SQLite version 3.9.2 2015-11-02 18:31:45 Enter ".help" for usage hints. sqlite> SELECT max(UnitCost)

  1   2   3   >