What is the C language standard to which sqlite conforms ?

classic Classic list List threaded Threaded
30 messages Options
12
Reply | Threaded
Open this post in threaded view
|

What is the C language standard to which sqlite conforms ?

Dennis Clarke

Same question as a few days ago.

This may have been asked many times before but always seems to be a
valid question.  On some machines with different compilers I get good
results using C99 strict compliance. On other machines, such as those
running Red Hat Enterprise Linux, I get terrible results.

Also I am using a variety of LLVM/Clang and also GCC 8.x and 9.x as
well as Oracle Studio 12.6 and also a few tests with less obvious
compilers.  This would be on 32-bit i386 and 32-bit armv7 and 64-bit
ppc64 and Fujitsu sparcv9 and AMD Opteron and Intel x86_64 various
types.

--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: What is the C language standard to which sqlite conforms ?

Jens Alfke-2


> On Nov 18, 2019, at 2:44 PM, Dennis Clarke <[hidden email]> wrote:
>
>  On some machines with different compilers I get good
> results using C99 strict compliance. On other machines, such as those
> running Red Hat Enterprise Linux, I get terrible results.

Why does it matter to you? I usually worry about compliance in my own code, not in 3rd party code that's known to work.

The parts of SQLite source code I've seen seem to be C90, in that they don't use "//" comments and put all their variable declarations at the top of a function. But I have no idea whether it's expected to conform to that or not.

> On other machines, such as those running Red Hat Enterprise Linux, I get terrible results.

What kind of results? RHEL tends to have old versions of everything, so it may be that its version of Clang/GCC has bugs with checking language compliance.

—Jens
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: What is the C language standard to which sqlite conforms ?

Scott Robison-2
In reply to this post by Dennis Clarke
On Mon, Nov 18, 2019 at 3:44 PM Dennis Clarke <[hidden email]> wrote:

>
> Same question as a few days ago.
>
> This may have been asked many times before but always seems to be a
> valid question.  On some machines with different compilers I get good
> results using C99 strict compliance. On other machines, such as those
> running Red Hat Enterprise Linux, I get terrible results.
>

Per https://www.sqlite.org/howtocompile.html it is "ANSI-C". C89 is the
ANSI-C standard, C90 is the first ISO-C standard. They are practically
identical.

Note that it is not strict ANSI-C, since ANSI-C doesn't provide for 64 bit
integers, and it does not provide for platform specific APIs or functions.
But as much as is possible, it is written to work with standard C as it has
existed for about 30 years now.

Different compilers have various degrees of compliance with their C89 / C90
/ C99 implementations. C99 is more strict about some things that C89 did
not care about, and the developers have made concessions on occasion to
conform to C99 when it did not compromise C89 compatibility. But as much as
possible it is desired to maintain C89 compatibility because there are
platforms that still are stuck with older compiler standards.

Note: I am not a member of the dev team, just recounting my understanding
of how things are.
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: What is the C language standard to which sqlite conforms ?

Dennis Clarke
On 11/19/19 12:32 AM, Scott Robison wrote:

> On Mon, Nov 18, 2019 at 3:44 PM Dennis Clarke <[hidden email]> wrote:
>
>>
>> Same question as a few days ago.
>>
>> This may have been asked many times before but always seems to be a
>> valid question.  On some machines with different compilers I get good
>> results using C99 strict compliance. On other machines, such as those
>> running Red Hat Enterprise Linux, I get terrible results.
>>
>
> Per https://www.sqlite.org/howtocompile.html it is "ANSI-C". C89 is the
> ANSI-C standard, C90 is the first ISO-C standard. They are practically
> identical.
>
> Note that it is not strict ANSI-C, since ANSI-C doesn't provide for 64 bit
> integers, and it does not provide for platform specific APIs or functions.
> But as much as is possible, it is written to work with standard C as it has
> existed for about 30 years now.
>

The code never passes its own test suite on Red Hat Enterprise Linux
when compiled with strict C90 flags.  In fact, the process segfaults.
Actually it is worse than that. The strict C90 flags cause the gcc
compiler to fail entirely due to the use of "asm" in the code.

Yes I have tried gcc 9.2.0 and the whole process fails in the tests
and no it will not compile as C90 code.

Dennis Clarke

_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: What is the C language standard to which sqlite conforms ?

Jens Alfke-2


> On Nov 19, 2019, at 5:29 AM, Dennis Clarke <[hidden email]> wrote:
>
> Yes I have tried gcc 9.2.0 and the whole process fails in the tests
> and no it will not compile as C90 code.

Have you tried just not forcing strict compliance? Which is the way people normally build SQLite?

—Jens

_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: What is the C language standard to which sqlite conforms ?

Jose Isaias Cabrera-4

Jens Alfke, on Tuesday, November 19, 2019 03:11 PM, wrote...
>
>
>
> > On Nov 19, 2019, at 5:29 AM, Dennis Clarke, on
> >
> > Yes I have tried gcc 9.2.0 and the whole process fails in the tests
> > and no it will not compile as C90 code.
>
> Have you tried just not forcing strict compliance? Which is the way people normally build SQLite?

Using cygwin, I run,

$ i686-w64-mingw32-gcc -shared -static-libgcc sqlite3.c -o sqlite3.dll​

and that works for me.

josé
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: What is the C language standard to which sqlite conforms ?

Keith Medcalf
In reply to this post by Dennis Clarke

If using a GCC compiler, the dialect is -std=gnuXX where XX is the latest year supported by the compiler.  
In order these are: gnu89 gnu90, gnu9x, gnu99, gnu11, gnu1x, gnu17, gnu18, gnu19, gnu20, gnu2x

This also happens to be the default if you do not specify -std

The Source Code does NOT contain #ifdef's to "turn off" GNU extensions when a GNU compiler is being used, so if you are using a GNU compiler you MUST use it in a GNU compliant mode.  The actual version that is required when using a GNU compiler is probably gnu89, that is, ANSI C with GNU extensions.

--
The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume.

>-----Original Message-----
>From: sqlite-users <[hidden email]> On
>Behalf Of Dennis Clarke
>Sent: Tuesday, 19 November, 2019 06:29
>To: [hidden email]
>Subject: Re: [sqlite] What is the C language standard to which sqlite
>conforms ?
>
>On 11/19/19 12:32 AM, Scott Robison wrote:
>> On Mon, Nov 18, 2019 at 3:44 PM Dennis Clarke <[hidden email]>
>wrote:
>>
>>>
>>> Same question as a few days ago.
>>>
>>> This may have been asked many times before but always seems to be a
>>> valid question.  On some machines with different compilers I get good
>>> results using C99 strict compliance. On other machines, such as those
>>> running Red Hat Enterprise Linux, I get terrible results.
>>>
>>
>> Per https://www.sqlite.org/howtocompile.html it is "ANSI-C". C89 is the
>> ANSI-C standard, C90 is the first ISO-C standard. They are practically
>> identical.
>>
>> Note that it is not strict ANSI-C, since ANSI-C doesn't provide for 64
>bit
>> integers, and it does not provide for platform specific APIs or
>functions.
>> But as much as is possible, it is written to work with standard C as it
>has
>> existed for about 30 years now.
>>
>
>The code never passes its own test suite on Red Hat Enterprise Linux
>when compiled with strict C90 flags.  In fact, the process segfaults.
>Actually it is worse than that. The strict C90 flags cause the gcc
>compiler to fail entirely due to the use of "asm" in the code.
>
>Yes I have tried gcc 9.2.0 and the whole process fails in the tests
>and no it will not compile as C90 code.
>
>Dennis Clarke
>
>_______________________________________________
>sqlite-users mailing list
>[hidden email]
>http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users



_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: What is the C language standard to which sqlite conforms ?

Dennis Clarke
On 11/19/19 8:43 PM, Keith Medcalf wrote:
>
> If using a GCC compiler, the dialect is -std=gnuXX where XX is the latest year supported by the compiler.
> In order these are: gnu89 gnu90, gnu9x, gnu99, gnu11, gnu1x, gnu17, gnu18, gnu19, gnu20, gnu2x
>
> This also happens to be the default if you do not specify -std
>
> The Source Code does NOT contain #ifdef's to "turn off" GNU extensions when a GNU compiler is being used, so if you are using a GNU compiler you MUST use it in a GNU compliant mode.  The actual version that is required when using a GNU compiler is probably gnu89, that is, ANSI C with GNU extensions.
>

I was waiting for the right person to respond. You are the right person.
I generally, these days, wait until I see the names and voices that I
have heard over the past ten or twenty years and then I really do pay
attention. You Sir are the man today.  :)  So thank you.

So you are saying that the code base is C89 clean but one should not
or must not attempt to compile with a GCC compiler and specify a std
such as -std=iso9899:1999 because the codebase makes no attempt to
detect the GNU compiler?  I am confused.  Regardless my own experience
and understanding is that the sqlite code is so clean that I could print
it out onto the walls of a room and we have have a surgical theatre
ready for heart transplant.  However there is no such standard as "GNU
compliant" and there seems to be things in the codebase that are just
strange enough that I can not compile the code on a Red Hat Enterprise
Linux machine with gcc 9.2.0. Having said all that you are saying "don't
do that" and just let the code compile as is with a very few switches
but certainly not -std=foo. With sqlite-src-3300100 I can not get very
far due to the testsuite blowing up with a segfault :

# WARNING: This next test takes around 12 seconds
gmake: *** [Makefile:1256: tcltest] Segmentation fault (core dumped)

Now here I do want and need the ability to debug and thus my CFLAGS are:

CC=/opt/bw/gcc9/bin/gcc

CFLAGS=-std=iso9899:1999 -O0 -m64 -g -march=k8 -mtune=k8 \
-Wl,-rpath=/opt/bw/lib,--enable-new-dtags -fno-builtin \
-malign-double -mpc80

CPPFLAGS=-I/opt/bw/include -D_POSIX_PTHREAD_SEMANTICS \
-D_LARGEFILE64_SOURCE -D_TS_ERRNO -D_GNU_SOURCE

I can get a compile and never a test.

I think my real issue here is that I can get everything to compile
neatly on some other system such as good ol' strict POSIX Solaris 10
with the Oracle Studio 12.6 tools and that is with insanely strict
C99 compiler but can not get a good result on RHEL.  Which is maddening.
Even with a new shiney gcc.

Would love to hear your thoughts.


--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: What is the C language standard to which sqlite conforms ?

Warren Young
On Nov 19, 2019, at 7:06 PM, Dennis Clarke <[hidden email]> wrote:
>
> gmake: *** [Makefile:1256: tcltest] Segmentation fault (core dumped)



> CC=/opt/bw/gcc9/bin/gcc

You’re using a nonstandard compiler (i.e. not provided by Red Hat) with non-default options, but it’s SQLite at fault here?  Seems like quite a leap of logic to me.

Where did you get that compiler binary?  Or did you build it yourself?

I ask because a Google search for “/opt/bw/gcc9” turns up almost nothing.  I get only three results, one of which is your prior thread here.  Three!

> -march=k8 -mtune=k8

That’s kind of an old CPU.  Maybe try -mtune=native instead, unless you need the resulting binaries to be broadly portable.

Your symptom would be explained if you aren’t actually running this binary on a K8 compatible CPU.  If you don’t like -mtune=native, try dropping this and the -march options entirely.  If the symptom goes away, you’re building the binary for a CPU you don’t have.

And yes, this sort of problem can be code-dependent.  Some code will build and run under the wrong -mtune or -march options, where other code won’t, because the latter code causes the compiler to generate code that the other code doesn’t.

Code coverage can also play into it: I built binaries with the wrong option not long ago that ran and showed their help screens, but which core dumped when asked to do real work.  Changing the -march option fixed it.

> -malign-double -mpc80

Those are both the default on GCC with 64-bit CPUs.
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: What is the C language standard to which sqlite conforms ?

Dennis Clarke
On 11/20/19 2:26 AM, Warren Young wrote:

> On Nov 19, 2019, at 7:06 PM, Dennis Clarke <[hidden email]> wrote:
>>
>> gmake: *** [Makefile:1256: tcltest] Segmentation fault (core dumped)
>
> …
>
>> CC=/opt/bw/gcc9/bin/gcc
>
> You’re using a nonstandard compiler (i.e. not provided by Red Hat) with non-default options, but it’s SQLite at fault here?  Seems like quite a leap of logic to me.
>
> Where did you get that compiler binary?  Or did you build it yourself?
>

I think I know my way around building a production grade or release
  grade compiler. Thank you.

You do your research first.


--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: What is the C language standard to which sqlite conforms ?

Richard Hipp-3
In reply to this post by Dennis Clarke
On 11/19/19, Dennis Clarke <[hidden email]> wrote:

>
> CC=/opt/bw/gcc9/bin/gcc
>
> CFLAGS=-std=iso9899:1999 -O0 -m64 -g -march=k8 -mtune=k8 \
> -Wl,-rpath=/opt/bw/lib,--enable-new-dtags -fno-builtin \
> -malign-double -mpc80
>
> CPPFLAGS=-I/opt/bw/include -D_POSIX_PTHREAD_SEMANTICS \
> -D_LARGEFILE64_SOURCE -D_TS_ERRNO -D_GNU_SOURCE
>
> I can get a compile and never a test.

Maybe try compiling without all the superfluous options?  Does you
still get the failure then?

Perhaps tell us what the error is so that we can debug it?
--
D. Richard Hipp
[hidden email]
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: What is the C language standard to which sqlite conforms ?

Dennis Clarke
On 11/20/19 12:12 PM, Richard Hipp wrote:

> On 11/19/19, Dennis Clarke <[hidden email]> wrote:
>>
>> CC=/opt/bw/gcc9/bin/gcc
>>
>> CFLAGS=-std=iso9899:1999 -O0 -m64 -g -march=k8 -mtune=k8 \
>> -Wl,-rpath=/opt/bw/lib,--enable-new-dtags -fno-builtin \
>> -malign-double -mpc80
>>
>> CPPFLAGS=-I/opt/bw/include -D_POSIX_PTHREAD_SEMANTICS \
>> -D_LARGEFILE64_SOURCE -D_TS_ERRNO -D_GNU_SOURCE
>>
>> I can get a compile and never a test.
>
> Maybe try compiling without all the superfluous options?  Does you
> still get the failure then?
>
> Perhaps tell us what the error is so that we can debug it?
>

That email is out of date and I submitted the current situation more
recently here.

Here is how things look :


CC=/opt/bw/gcc9/bin/gcc

CFLAGS=-O0 -m64 -g -march=k8 -mtune=k8
-Wl,-rpath=/opt/bw/lib,--enable-new-dtags -fno-builtin -malign-double

CPPFLAGS=-I/opt/bw/include -D_POSIX_PTHREAD_SEMANTICS
-D_LARGEFILE64_SOURCE -D_TS_ERRNO

CXX=/opt/bw/gcc9/bin/g++

CXXFLAGS=-std=c++11 -O0 -m64 -g -march=k8 -mtune=k8
-Wl,-rpath=/opt/bw/lib,--enable-new-dtags -fno-builtin -malign-double

LC_COLLATE=C
LC_CTYPE=C
LC_MESSAGES=C
LC_MONETARY=C
LC_NUMERIC=C
LC_TIME=C

LDFLAGS=-L/opt/bw/lib -Wl,-rpath=/opt/bw/lib,--enable-new-dtags

LD_RUN_PATH=/opt/bw/lib

PATH=/opt/bw/bin:/opt/bw/sbin:/opt/bw/gcc9/bin:/usr/local/bin:/usr/local/sbin:/usr/sbin:/usr/bin:/sbin:/bin:/opt/schily/bin

PERL=/opt/bw/bin/perl

Nothing else of any significance and the build goes just fine with :

boe13$ ./configure --prefix=/opt/bw --enable-shared --enable-static \
 > --enable-readline --enable-threadsafe \
 > --enable-tempstore=yes --enable-debug \
 > --with-tcl=/opt/bw/lib

However the tests fail repeatedly with a code dump :

Time: walshared.test 26 ms
# WARNING: This next test takes around 12 seconds
gmake: *** [Makefile:1256: tcltest] Segmentation fault (core dumped)

boe13$ gdb ./testfixture ./testdir/core.8032
GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-100.el7
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from
/opt/bw/build/sqlite-src-3300100_rhel_74_3.10.0-693.el7.x86_64.006/testfixture...done.
[New LWP 8032]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by `./testfixture
/opt/bw/build/sqlite-src-3300100_rhel_74_3.10.0-693.el7.x86_64.00'.
Program terminated with signal 11, Segmentation fault.
#0  0x000000000043c71b in tvfsFileControl (pFile=0x1509af0, op=20,
pArg=0x7ffde61bc9f8)
     at
/opt/bw/build/sqlite-src-3300100_rhel_74_3.10.0-693.el7.x86_64.006/src/test_vfs.c:549
549       if( p->pScript && (p->mask&TESTVFS_FCNTL_MASK) ){
Missing separate debuginfos, use: debuginfo-install
glibc-2.17-196.el7.x86_64 libgcc-4.8.5-16.el7.x86_64
(gdb) where
#0  0x000000000043c71b in tvfsFileControl (pFile=0x1509af0, op=20,
pArg=0x7ffde61bc9f8)
     at
/opt/bw/build/sqlite-src-3300100_rhel_74_3.10.0-693.el7.x86_64.006/src/test_vfs.c:549
#1  0x000000000046c4e9 in sqlite3OsFileControl (id=0x1509af0, op=20,
pArg=0x7ffde61bc9f8) at sqlite3.c:22475
#2  0x000000000048a47e in databaseIsUnmoved (pPager=0x1509970) at
sqlite3.c:54928
#3  0x000000000048a59c in sqlite3PagerClose (pPager=0x1509970,
db=0x14fbb70) at sqlite3.c:54969
#4  0x000000000049bf12 in sqlite3BtreeClose (p=0x159ea10) at sqlite3.c:66134
#5  0x000000000054ebac in sqlite3LeaveMutexAndCloseZombie (db=0x14fbb70)
at sqlite3.c:157429
#6  0x000000000054eacc in sqlite3Close (db=0x14fbb70, forceZombie=0) at
sqlite3.c:157372
#7  0x000000000054eaf0 in sqlite3_close (db=0x14fbb70) at sqlite3.c:157385
#8  0x00000000004611cf in DbDeleteCmd (db=0x15bbab8)
     at
/opt/bw/build/sqlite-src-3300100_rhel_74_3.10.0-693.el7.x86_64.006/src/tclsqlite.c:528
#9  0x00007f9d19e18330 in Tcl_DeleteCommandFromToken (interp=0x1921c38,
cmd=0x1350f48)
     at /opt/bw/build/nist/tcl8.7a1/generic/tclBasic.c:3184
#10 0x00007f9d19e18179 in Tcl_DeleteCommand (interp=0x1921c38,
cmdName=0x13acd98 "db")
     at /opt/bw/build/nist/tcl8.7a1/generic/tclBasic.c:3045
#11 0x0000000000464d45 in DbObjCmd (cd=0x15bbab8, interp=0x1921c38,
objc=2, objv=0x14ded88)
     at
/opt/bw/build/sqlite-src-3300100_rhel_74_3.10.0-693.el7.x86_64.006/src/tclsqlite.c:2219
#12 0x00007f9d19e19e2a in Dispatch (data=0x107d5e0, interp=0x1921c38,
result=0)
     at /opt/bw/build/nist/tcl8.7a1/generic/tclBasic.c:4418
#13 0x00007f9d19e19eb7 in TclNRRunCallbacks (interp=0x1921c38, result=0,
rootPtr=0x0)
     at /opt/bw/build/nist/tcl8.7a1/generic/tclBasic.c:4451
#14 0x00007f9d19e1c815 in TclEvalObjEx (interp=0x1921c38,
objPtr=0x6161616161616161, flags=0, invoker=0xe87178, word=0)
     at /opt/bw/build/nist/tcl8.7a1/generic/tclBasic.c:6018
#15 0x00007f9d19f24152 in SlaveEval (interp=0xe832f8,
slaveInterp=0x1921c38, objc=1, objv=0xe871f0)
     at /opt/bw/build/nist/tcl8.7a1/generic/tclInterp.c:2826
#16 0x00007f9d19f20bac in NRInterpCmd (clientData=0x0, interp=0xe832f8,
objc=4, objv=0xe871d8)
     at /opt/bw/build/nist/tcl8.7a1/generic/tclInterp.c:885
#17 0x00007f9d19e19e2a in Dispatch (data=0x17f8bb0, interp=0xe832f8,
result=0)
     at /opt/bw/build/nist/tcl8.7a1/generic/tclBasic.c:4418
#18 0x00007f9d19e19eb7 in TclNRRunCallbacks (interp=0xe832f8, result=0,
rootPtr=0x186aa38)
     at /opt/bw/build/nist/tcl8.7a1/generic/tclBasic.c:4451
#19 0x00007f9d19e1c815 in TclEvalObjEx (interp=0xe832f8,
objPtr=0x6161616161616161, flags=0, invoker=0x0, word=0)
     at /opt/bw/build/nist/tcl8.7a1/generic/tclBasic.c:6018
#20 0x00007f9d19e1c7ae in Tcl_EvalObjEx (interp=0xe832f8,
objPtr=0x6161616161616161, flags=0)
     at /opt/bw/build/nist/tcl8.7a1/generic/tclBasic.c:5999
#21 0x00007f9d19e40160 in Tcl_TimeObjCmd (dummy=0x0, interp=0xe832f8,
objc=2, objv=0xe87000)
     at /opt/bw/build/nist/tcl8.7a1/generic/tclCmdMZ.c:4123
#22 0x00007f9d19e19e2a in Dispatch (data=0x144c260, interp=0xe832f8,
result=0)
     at /opt/bw/build/nist/tcl8.7a1/generic/tclBasic.c:4418
#23 0x00007f9d19e19eb7 in TclNRRunCallbacks (interp=0xe832f8, result=0,
rootPtr=0x0)
     at /opt/bw/build/nist/tcl8.7a1/generic/tclBasic.c:4451
#24 0x00007f9d19e19708 in Tcl_EvalObjv (interp=0xe832f8, objc=5,
objv=0xe86880, flags=2097168)
---Type <return> to continue, or q <return> to quit---
     at /opt/bw/build/nist/tcl8.7a1/generic/tclBasic.c:4181
#25 0x00007f9d19e1bbf6 in TclEvalEx (interp=0xe832f8,
     script=0x566360 <zMainloop.11226> "if {[llength $argv]>=1} {\nset
argv0 [lindex $argv 0]\nset argv [lrange $argv 1 end]\nsource $argv0\n}
else {\nset line {}\nwhile {![eof stdin]} {\nif {$line!=\"\"} {\nputs
-nonewline \"> \"\n} else {\nputs -nonewl"...,
     numBytes=430, flags=0, line=1, clNextOuter=0x0,
     outerScript=0x566360 <zMainloop.11226> "if {[llength $argv]>=1}
{\nset argv0 [lindex $argv 0]\nset argv [lrange $argv 1 end]\nsource
$argv0\n} else {\nset line {}\nwhile {![eof stdin]} {\nif {$line!=\"\"}
{\nputs -nonewline \"> \"\n} else {\nputs -nonewl"...)
     at /opt/bw/build/nist/tcl8.7a1/generic/tclBasic.c:5320
#26 0x00007f9d19e1afc4 in Tcl_EvalEx (interp=0xe832f8,
     script=0x566360 <zMainloop.11226> "if {[llength $argv]>=1} {\nset
argv0 [lindex $argv 0]\nset argv [lrange $argv 1 end]\nsource $argv0\n}
else {\nset line {}\nwhile {![eof stdin]} {\nif {$line!=\"\"} {\nputs
-nonewline \"> \"\n} else {\nputs -nonewl"...,
     numBytes=-1, flags=0) at
/opt/bw/build/nist/tcl8.7a1/generic/tclBasic.c:4985
#27 0x00007f9d19e1dc68 in Tcl_GlobalEval (interp=0xe832f8,
     command=0x566360 <zMainloop.11226> "if {[llength $argv]>=1} {\nset
argv0 [lindex $argv 0]\nset argv [lrange $argv 1 end]\nsource $argv0\n}
else {\nset line {}\nwhile {![eof stdin]} {\nif {$line!=\"\"} {\nputs
-nonewline \"> \"\n} else {\nputs -nonewl"...)
     at /opt/bw/build/nist/tcl8.7a1/generic/tclBasic.c:6983
#28 0x0000000000468e38 in main (argc=4, argv=0x7ffde61bd908)
     at
/opt/bw/build/sqlite-src-3300100_rhel_74_3.10.0-693.el7.x86_64.006/src/tclsqlite.c:4008
(gdb) quit
boe13$

So that tcl build was clean and works fine.

Not sure what else to say here.

Dennis

_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: What is the C language standard to which sqlite conforms ?

Richard Hipp-3
On 11/20/19, Dennis Clarke <[hidden email]> wrote:
>
> However the tests fail repeatedly with a code dump :
>

Unable to reproduce the problem.  What do you get when you run:

    ./testfixture test/walvfs.test

What version of TCL are you linking against?

For casual observers, please note that the segfault is in the test
harness, not in SQLite itself.  Probably it is an issue with the test
harness itself and not a problem with the SQLite core.  But we will
see...
--
D. Richard Hipp
[hidden email]
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: What is the C language standard to which sqlite conforms ?

Dennis Clarke
On 11/20/19 1:04 PM, Richard Hipp wrote:

> On 11/20/19, Dennis Clarke <[hidden email]> wrote:
>>
>> However the tests fail repeatedly with a code dump :
>>
>
> Unable to reproduce the problem.  What do you get when you run:
>
>      ./testfixture test/walvfs.test
>
> What version of TCL are you linking against?
>
> For casual observers, please note that the segfault is in the test
> harness, not in SQLite itself.  Probably it is an issue with the test
> harness itself and not a problem with the SQLite core.  But we will
> see...
>

Oh yes this is the test suite situation which actually stops the install
process. Sure I could blindly install with the knowledge from extensive
hours and a few years looking over the sqlite code. Sure. However a test
report is sort of essential.

This is linked against tcl8.7a1 wherein I did see :

Tests ended at Thu Nov 07 03:24:35 GMT 2019
all.tcl:        Total   31405   Passed  30187   Skipped 1218    Failed  0
Sourced 148 Test Files.
Number of tests skipped for each constraint:
         9       !ieeeFloatingPoint
         3       asyncPipeChan
         76      bigEndian
         5       bug-3057639
         49      dde
         4       dontCopyLinks
         63      emptyTest
         5       fullutf
         2       hasIsoLocale
         1       knownBadTest
         39      knownBug
         100     localeRegexp
         48      longIs32bit
         14      macosxFileAttr
         45      nonPortable
         5       notNetworkFilesystem
         1       obsolete
         4       readonlyAttr
         3       singleTestInterp
         1       testexprparser && !ieeeFloatingPoint
         7       testpreferstable
         1       testwinclock
         21      testwordend
         189     thread
         2       unthreaded
         2       wideBiggerThanInt
         504     win
         4       winVista

So that is flawless.  Also other software work has already proceeded
with that tcl.

Also :

boe13$ cd sqlite-src-3300100_rhel_74_3.10.0-693.el7.x86_64.006
boe13$ ls -lapb ./testfixture
-rwxr-xr-x. 1 dclarke devl 5426184 Nov 20 04:35 ./testfixture
boe13$ ldd ./testfixture
         linux-vdso.so.1 =>  (0x00007fff993b6000)
         libtcl8.7.so => /opt/bw/lib/libtcl8.7.so (0x00007fd8119bd000)
         libdl.so.2 => /lib64/libdl.so.2 (0x00007fd8117af000)
         libz.so.1 => /opt/bw/lib/libz.so.1 (0x00007fd811591000)
         libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fd811375000)
         libc.so.6 => /lib64/libc.so.6 (0x00007fd810fb1000)
         libm.so.6 => /lib64/libm.so.6 (0x00007fd810caf000)
         /lib64/ld-linux-x86-64.so.2 (0x0000560607599000)
boe13$
boe13$ ./testfixture test/walvfs.test
walvfs-1.0... Ok
walvfs-1.1... Ok
walvfs-1.2... Ok
walvfs-1.3... Ok
walvfs-2.0... Ok
walvfs-2.1... Ok
walvfs-2.2... Ok
walvfs-2.3... Ok
walvfs-3.0... Ok
walvfs-3.1... Ok
walvfs-3.2... Ok
walvfs-4.0... Ok
walvfs-4.1... Ok
walvfs-4.2... Ok
walvfs-5.0... Ok
walvfs-5.1... Ok
walvfs-5.2... Ok
walvfs-5.3... Ok
walvfs-5.3... Ok
walvfs-5.4... Ok
walvfs-5.5... Ok
walvfs-5.6... Ok
walvfs-6.0... Ok
walvfs-6.1... Ok
# WARNING: This next test takes around 12 seconds
walvfs-6.2... Ok
walvfs-7.0... Ok
walvfs-7.1... Ok
walvfs-8.0... Ok
walvfs-8.1... Ok
walvfs-8.2... Ok
walvfs-8.3... Ok
Segmentation fault (core dumped)
boe13$

Let's try that in the debugger :

boe13$ TERM=dumb gdb -q ./testfixture
Reading symbols from
/opt/bw/build/sqlite-src-3300100_rhel_74_3.10.0-693.el7.x86_64.006/testfixture...done.
(gdb) run test/walvfs.test
Starting program:
/opt/bw/build/sqlite-src-3300100_rhel_74_3.10.0-693.el7.x86_64.006/./testfixture
test/walvfs.test
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
walvfs-1.0... Ok
walvfs-1.1... Ok
walvfs-1.2... Ok
walvfs-1.3... Ok
walvfs-2.0... Ok
walvfs-2.1... Ok
walvfs-2.2... Ok
walvfs-2.3... Ok
walvfs-3.0... Ok
walvfs-3.1... Ok
walvfs-3.2... Ok
walvfs-4.0... Ok
walvfs-4.1... Ok
walvfs-4.2... Ok
walvfs-5.0... Ok
walvfs-5.1... Ok
walvfs-5.2... Ok
walvfs-5.3... Ok
walvfs-5.3... Ok
walvfs-5.4... Ok
walvfs-5.5... Ok
walvfs-5.6... Ok
walvfs-6.0... Ok
walvfs-6.1... Ok
# WARNING: This next test takes around 12 seconds
walvfs-6.2... Ok
walvfs-7.0... Ok
walvfs-7.1... Ok
walvfs-8.0... Ok
walvfs-8.1... Ok
walvfs-8.2... Ok
walvfs-8.3... Ok

Program received signal SIGSEGV, Segmentation fault.
0x000000000043c71b in tvfsFileControl (pFile=0xa03c80, op=20,
pArg=0x7fffffffd918)
     at
/opt/bw/build/sqlite-src-3300100_rhel_74_3.10.0-693.el7.x86_64.006/src/test_vfs.c:549
549       if( p->pScript && (p->mask&TESTVFS_FCNTL_MASK) ){
Missing separate debuginfos, use: debuginfo-install
glibc-2.17-196.el7.x86_64
(gdb) where
#0  0x000000000043c71b in tvfsFileControl (pFile=0xa03c80, op=20,
pArg=0x7fffffffd918)
     at
/opt/bw/build/sqlite-src-3300100_rhel_74_3.10.0-693.el7.x86_64.006/src/test_vfs.c:549
#1  0x000000000046c4e9 in sqlite3OsFileControl (id=0xa03c80, op=20,
pArg=0x7fffffffd918) at sqlite3.c:22475
#2  0x000000000048a47e in databaseIsUnmoved (pPager=0xa03b00) at
sqlite3.c:54928
#3  0x000000000048a59c in sqlite3PagerClose (pPager=0xa03b00,
db=0x9f5b20) at sqlite3.c:54969
#4  0x000000000049bf12 in sqlite3BtreeClose (p=0x976140) at sqlite3.c:66134
#5  0x000000000054ebac in sqlite3LeaveMutexAndCloseZombie (db=0x9f5b20)
at sqlite3.c:157429
#6  0x000000000054eacc in sqlite3Close (db=0x9f5b20, forceZombie=0) at
sqlite3.c:157372
#7  0x000000000054eaf0 in sqlite3_close (db=0x9f5b20) at sqlite3.c:157385
#8  0x00000000004611cf in DbDeleteCmd (db=0x98fa18)
     at
/opt/bw/build/sqlite-src-3300100_rhel_74_3.10.0-693.el7.x86_64.006/src/tclsqlite.c:528
#9  0x00007ffff79dd330 in Tcl_DeleteCommandFromToken (interp=0x7ec318,
cmd=0x9fe8a8)
     at /opt/bw/build/nist/tcl8.7a1/generic/tclBasic.c:3184
#10 0x00007ffff79dd179 in Tcl_DeleteCommand (interp=0x7ec318,
cmdName=0x903208 "db")
     at /opt/bw/build/nist/tcl8.7a1/generic/tclBasic.c:3045
#11 0x0000000000464d45 in DbObjCmd (cd=0x98fa18, interp=0x7ec318,
objc=2, objv=0x7efc18)
     at
/opt/bw/build/sqlite-src-3300100_rhel_74_3.10.0-693.el7.x86_64.006/src/tclsqlite.c:2219
#12 0x00007ffff79dee2a in Dispatch (data=0x979240, interp=0x7ec318,
result=0)
     at /opt/bw/build/nist/tcl8.7a1/generic/tclBasic.c:4418
#13 0x00007ffff79deeb7 in TclNRRunCallbacks (interp=0x7ec318, result=0,
rootPtr=0x0)
     at /opt/bw/build/nist/tcl8.7a1/generic/tclBasic.c:4451
#14 0x00007ffff79de708 in Tcl_EvalObjv (interp=0x7ec318, objc=5,
objv=0x7ef8a0, flags=2097168)
     at /opt/bw/build/nist/tcl8.7a1/generic/tclBasic.c:4181
#15 0x00007ffff79e0bf6 in TclEvalEx (interp=0x7ec318,
     script=0x566360 <zMainloop.11226> "if {[llength $argv]>=1} {\nset
argv0 [lindex $argv 0]\nset argv [lrange $argv 1 end]\nsource $argv0\n}
else {\nset line {}\nwhile {![eof stdin]} {\nif {$line!=\"\"} {\nputs
-nonewline \"> \"\n} else {\nputs -nonewl"...,
     numBytes=430, flags=0, line=1, clNextOuter=0x0,
     outerScript=0x566360 <zMainloop.11226> "if {[llength $argv]>=1}
{\nset argv0 [lindex $argv 0]\nset argv [lrange $argv 1 end]\nsource
$argv0\n} else {\nset line {}\nwhile {![eof stdin]} {\nif {$line!=\"\"}
{\nputs -nonewline \"> \"\n} else {\nputs -nonewl"...) at
/opt/bw/build/nist/tcl8.7a1/generic/tclBasic.c:5320
#16 0x00007ffff79dffc4 in Tcl_EvalEx (interp=0x7ec318,
     script=0x566360 <zMainloop.11226> "if {[llength $argv]>=1} {\nset
argv0 [lindex $argv 0]\nset argv [lrange $argv 1 end]\nsource $argv0\n}
else {\nset line {}\nwhile {![eof stdin]} {\nif {$line!=\"\"} {\nputs
-nonewline \"> \"\n} else {\nputs -nonewl"...,
     numBytes=-1, flags=0) at
/opt/bw/build/nist/tcl8.7a1/generic/tclBasic.c:4985
#17 0x00007ffff79e2c68 in Tcl_GlobalEval (interp=0x7ec318,
     command=0x566360 <zMainloop.11226> "if {[llength $argv]>=1} {\nset
argv0 [lindex $argv 0]\nset argv [lrange $argv 1 end]\nsource $argv0\n}
else {\nset line {}\nwhile {![eof stdin]} {\nif {$line!=\"\"} {\nputs
-nonewline \"> \"\n} else {\nputs -nonewl"...)
     at /opt/bw/build/nist/tcl8.7a1/generic/tclBasic.c:6983
#18 0x0000000000468e38 in main (argc=2, argv=0x7fffffffe398)
     at
/opt/bw/build/sqlite-src-3300100_rhel_74_3.10.0-693.el7.x86_64.006/src/tclsqlite.c:4008
(gdb)


In any case feels like a real problem.



--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional



_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: What is the C language standard to which sqlite conforms ?

Richard Hipp-3
On 11/20/19, Dennis Clarke <[hidden email]> wrote:
>
> In any case feels like a real problem.

I am unable to reproduce the problem here.  Can you run it under
valgrind to see if that provides any other clues?
--
D. Richard Hipp
[hidden email]
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: What is the C language standard to which sqlite conforms ?

Richard Hipp-3
On 11/20/19, Richard Hipp <[hidden email]> wrote:
> On 11/20/19, Dennis Clarke <[hidden email]> wrote:
>>
>> In any case feels like a real problem.
>
> I am unable to reproduce the problem here.  Can you run it under
> valgrind to see if that provides any other clues?

We have found a use-after-free problem in the test harness.  Testing
the patch now, and looking for related problems.

Apparently the ckmalloc()/ckfree() wrappers in TCL are interfering
with the ability of valgrind/ASAN to detect use-after-free errors.  I
don't understand that part, yet.

In any event, a patch to the test harness will appear on the website shortly.

And just to be clear:  This is a bug in the test harness, not in SQLite itself.

--
D. Richard Hipp
[hidden email]
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: What is the C language standard to which sqlite conforms ?

Warren Young
In reply to this post by Dennis Clarke
On Nov 19, 2019, at 8:43 PM, Dennis Clarke <[hidden email]> wrote:

>
> On 11/20/19 2:26 AM, Warren Young wrote:
>> On Nov 19, 2019, at 7:06 PM, Dennis Clarke <[hidden email]> wrote:
>>>
>>> gmake: *** [Makefile:1256: tcltest] Segmentation fault (core dumped)
>> …
>>> CC=/opt/bw/gcc9/bin/gcc
>> You’re using a nonstandard compiler (i.e. not provided by Red Hat) with non-default options, but it’s SQLite at fault here?  Seems like quite a leap of logic to me.
>> Where did you get that compiler binary?  Or did you build it yourself?
>
> I think I know my way around building a production grade or release
> grade compiler. Thank you.
>
> You do your research first.

Which publicly-accessible research would lead me to exonerate your local one-off toolchain?

You’re telling us that Extremely Popular Software with Extensive Test Suite fails with Extremely Popular C Compiler on Extremely Popular OS, but it’s definitely not happening because of some local weirdness?

Anyway, the SQLite 3.30.1 test suite runs to completion when built on CentOS 7.6 with the stock compiler, with this configuration:

    $ CFLAGS=-std=gnu99 ./configure --with-tcl=/usr/local/tcl-8.6.10
    $ make -j11 && make test
    SQLite 2019-10-10 20:19:45 18db032d05…
    0 errors out of 249395 tests on never.you.mind.example.com Linux 64-bit little-endian

The setting of gnu99 over iso9899:1999 is because the “asm” keyword isn’t part of ISO C, so you do have to allow GCC to use its GNU extensions to the language.  “gnu99” is my best guess at closest approach to ISO C99.

The local install of Tcl is necessary only because RHEL / CentOS 7 still ships Tcl 8.5, and the SQLite test suite requires 8.6.  I built it with all default options using the stock GCC, except of course that I set --prefix.
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: What is the C language standard to which sqlite conforms ?

Dennis Clarke
In reply to this post by Richard Hipp-3
On 11/20/19 3:45 PM, Richard Hipp wrote:
> On 11/20/19, Dennis Clarke <[hidden email]> wrote:
>>
>> In any case feels like a real problem.
>
> I am unable to reproduce the problem here.  Can you run it under
> valgrind to see if that provides any other clues?
>

I will give that a try.

Dennis
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: What is the C language standard to which sqlite conforms ?

Dennis Clarke
In reply to this post by Richard Hipp-3
On 11/20/19 1:04 PM, Richard Hipp wrote:

> On 11/20/19, Dennis Clarke <[hidden email]> wrote:
>>
>> However the tests fail repeatedly with a code dump :
>>
>
> Unable to reproduce the problem.  What do you get when you run:
>
>      ./testfixture test/walvfs.test
>
> What version of TCL are you linking against?
>
> For casual observers, please note that the segfault is in the test
> harness, not in SQLite itself.  Probably it is an issue with the test
> harness itself and not a problem with the SQLite core.  But we will
> see...
>

boe13$ valgrind --version
valgrind-3.15.0

boe13$ ldd testfixture
         linux-vdso.so.1 =>  (0x00007ffcc0bf0000)
         libtcl8.7.so => /opt/bw/lib/libtcl8.7.so (0x00007fb9c0949000)
         libdl.so.2 => /lib64/libdl.so.2 (0x00007fb9c073b000)
         libz.so.1 => /opt/bw/lib/libz.so.1 (0x00007fb9c051d000)
         libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fb9c0301000)
         libc.so.6 => /lib64/libc.so.6 (0x00007fb9bff3d000)
         libm.so.6 => /lib64/libm.so.6 (0x00007fb9bfc3b000)
         /lib64/ld-linux-x86-64.so.2 (0x0000556ca7690000)
boe13$
boe13$
boe13$ valgrind --leak-check=full ./testfixture test/walvfs.test
==44169== Memcheck, a memory error detector
==44169== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==44169== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info
==44169== Command: ./testfixture test/walvfs.test
==44169==
walvfs-1.0... Ok
walvfs-1.1... Ok
walvfs-1.2... Ok
walvfs-1.3... Ok
walvfs-2.0... Ok
walvfs-2.1... Ok
walvfs-2.2... Ok
walvfs-2.3... Ok
walvfs-3.0... Ok
walvfs-3.1... Ok
walvfs-3.2... Ok
walvfs-4.0... Ok
walvfs-4.1... Ok
walvfs-4.2... Ok
walvfs-5.0... Ok
walvfs-5.1... Ok
walvfs-5.2... Ok
walvfs-5.3... Ok
walvfs-5.3... Ok
walvfs-5.4... Ok
walvfs-5.5... Ok
walvfs-5.6... Ok
walvfs-6.0... Ok
walvfs-6.1... Ok
# WARNING: This next test takes around 12 seconds
walvfs-6.2... Ok
walvfs-7.0... Ok
walvfs-7.1... Ok
walvfs-8.0... Ok
walvfs-8.1... Ok
walvfs-8.2... Ok
walvfs-8.3... Ok
==44169== Invalid read of size 8
==44169==    at 0x43C5D8: tvfsFileControl (test_vfs.c:527)
==44169==    by 0x46C4E8: sqlite3OsFileControl (sqlite3.c:22475)
==44169==    by 0x48A47D: databaseIsUnmoved (sqlite3.c:54928)
==44169==    by 0x48A59B: sqlite3PagerClose (sqlite3.c:54969)
==44169==    by 0x49BF11: sqlite3BtreeClose (sqlite3.c:66134)
==44169==    by 0x54EBAB: sqlite3LeaveMutexAndCloseZombie (sqlite3.c:157429)
==44169==    by 0x54EACB: sqlite3Close (sqlite3.c:157372)
==44169==    by 0x54EAEF: sqlite3_close (sqlite3.c:157385)
==44169==    by 0x4611CE: DbDeleteCmd (tclsqlite.c:528)
==44169==    by 0x4E8032F: Tcl_DeleteCommandFromToken (tclBasic.c:3184)
==44169==    by 0x4E80178: Tcl_DeleteCommand (tclBasic.c:3045)
==44169==    by 0x464D44: DbObjCmd (tclsqlite.c:2219)
==44169==  Address 0x7693ed8 is 88 bytes inside a block of size 240 free'd
==44169==    at 0x4C2B27C: free (vg_replace_malloc.c:540)
==44169==    by 0x4E763DC: TclpFree (tclAlloc.c:722)
==44169==    by 0x4E8F8A4: Tcl_DbCkfree (tclCkalloc.c:651)
==44169==    by 0x4E8FA89: Tcl_Free (tclCkalloc.c:769)
==44169==    by 0x43E99F: testvfs_obj_del (test_vfs.c:1393)
==44169==    by 0x4E8032F: Tcl_DeleteCommandFromToken (tclBasic.c:3184)
==44169==    by 0x4E80178: Tcl_DeleteCommand (tclBasic.c:3045)
==44169==    by 0x43E610: testvfs_obj_cmd (test_vfs.c:1296)
==44169==    by 0x4E81E29: Dispatch (tclBasic.c:4418)
==44169==    by 0x4E81EB6: TclNRRunCallbacks (tclBasic.c:4451)
==44169==    by 0x4E81707: Tcl_EvalObjv (tclBasic.c:4181)
==44169==    by 0x4E83BF5: TclEvalEx (tclBasic.c:5320)
==44169==  Block was alloc'd at
==44169==    at 0x4C29EC5: malloc (vg_replace_malloc.c:309)
==44169==    by 0x4E763C2: TclpAlloc (tclAlloc.c:699)
==44169==    by 0x4E8F0E0: Tcl_DbCkalloc (tclCkalloc.c:408)
==44169==    by 0x4E8FA40: Tcl_Alloc (tclCkalloc.c:755)
==44169==    by 0x43EDAD: testvfs_cmd (test_vfs.c:1550)
==44169==    by 0x4E81E29: Dispatch (tclBasic.c:4418)
==44169==    by 0x4E81EB6: TclNRRunCallbacks (tclBasic.c:4451)
==44169==    by 0x4E81707: Tcl_EvalObjv (tclBasic.c:4181)
==44169==    by 0x4E83BF5: TclEvalEx (tclBasic.c:5320)
==44169==    by 0x4E82FC3: Tcl_EvalEx (tclBasic.c:4985)
==44169==    by 0x4E85C67: Tcl_GlobalEval (tclBasic.c:6983)
==44169==    by 0x468E37: main (tclsqlite.c:4008)
==44169==
==44169== Invalid read of size 8
==44169==    at 0x43C71B: tvfsFileControl (test_vfs.c:549)
==44169==    by 0x46C4E8: sqlite3OsFileControl (sqlite3.c:22475)
==44169==    by 0x48A47D: databaseIsUnmoved (sqlite3.c:54928)
==44169==    by 0x48A59B: sqlite3PagerClose (sqlite3.c:54969)
==44169==    by 0x49BF11: sqlite3BtreeClose (sqlite3.c:66134)
==44169==    by 0x54EBAB: sqlite3LeaveMutexAndCloseZombie (sqlite3.c:157429)
==44169==    by 0x54EACB: sqlite3Close (sqlite3.c:157372)
==44169==    by 0x54EAEF: sqlite3_close (sqlite3.c:157385)
==44169==    by 0x4611CE: DbDeleteCmd (tclsqlite.c:528)
==44169==    by 0x4E8032F: Tcl_DeleteCommandFromToken (tclBasic.c:3184)
==44169==    by 0x4E80178: Tcl_DeleteCommand (tclBasic.c:3045)
==44169==    by 0x464D44: DbObjCmd (tclsqlite.c:2219)
==44169==  Address 0x6161616161616181 is not stack'd, malloc'd or
(recently) free'd
==44169==
==44169==
==44169== Process terminating with default action of signal 11
(SIGSEGV): dumping core
==44169==  General Protection Fault
==44169==    at 0x43C71B: tvfsFileControl (test_vfs.c:549)
==44169==    by 0x46C4E8: sqlite3OsFileControl (sqlite3.c:22475)
==44169==    by 0x48A47D: databaseIsUnmoved (sqlite3.c:54928)
==44169==    by 0x48A59B: sqlite3PagerClose (sqlite3.c:54969)
==44169==    by 0x49BF11: sqlite3BtreeClose (sqlite3.c:66134)
==44169==    by 0x54EBAB: sqlite3LeaveMutexAndCloseZombie (sqlite3.c:157429)
==44169==    by 0x54EACB: sqlite3Close (sqlite3.c:157372)
==44169==    by 0x54EAEF: sqlite3_close (sqlite3.c:157385)
==44169==    by 0x4611CE: DbDeleteCmd (tclsqlite.c:528)
==44169==    by 0x4E8032F: Tcl_DeleteCommandFromToken (tclBasic.c:3184)
==44169==    by 0x4E80178: Tcl_DeleteCommand (tclBasic.c:3045)
==44169==    by 0x464D44: DbObjCmd (tclsqlite.c:2219)
==44169==
==44169== HEAP SUMMARY:
==44169==     in use at exit: 1,953,583 bytes in 13,488 blocks
==44169==   total heap usage: 106,175 allocs, 92,687 frees, 16,323,777
bytes allocated
==44169==
==44169== 1,024 bytes in 1 blocks are possibly lost in loss record 3,469
of 3,773
==44169==    at 0x4C29EC5: malloc (vg_replace_malloc.c:309)
==44169==    by 0x46CFCD: sqlite3MemMalloc (sqlite3.c:23047)
==44169==    by 0x428D34: faultsimMalloc (test_malloc.c:97)
==44169==    by 0x46DF7E: mallocWithAlarm (sqlite3.c:26889)
==44169==    by 0x46E018: sqlite3Malloc (sqlite3.c:26919)
==44169==    by 0x482C8C: pcache1Alloc (sqlite3.c:49204)
==44169==    by 0x48305B: sqlite3PageMalloc (sqlite3.c:49345)
==44169==    by 0x49BD19: allocateTempSpace (sqlite3.c:66061)
==44169==    by 0x49EEB5: btreeCursor (sqlite3.c:67779)
==44169==    by 0x49F04B: sqlite3BtreeCursor (sqlite3.c:67821)
==44169==    by 0x4C8F1D: sqlite3VdbeExec (sqlite3.c:87701)
==44169==    by 0x4BDE68: sqlite3Step (sqlite3.c:82300)
==44169==
==44169== LEAK SUMMARY:
==44169==    definitely lost: 0 bytes in 0 blocks
==44169==    indirectly lost: 0 bytes in 0 blocks
==44169==      possibly lost: 1,024 bytes in 1 blocks
==44169==    still reachable: 1,952,559 bytes in 13,487 blocks
==44169==         suppressed: 0 bytes in 0 blocks
==44169== Reachable blocks (those to which a pointer was found) are not
shown.
==44169== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==44169==
==44169== For lists of detected and suppressed errors, rerun with: -s
==44169== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 0 from 0)
Segmentation fault
boe13$

Hope that is helpful.


--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: What is the C language standard to which sqlite conforms ?

Richard Hipp-3
The solution is here: https://www.sqlite.org/src/info/0d1055a5da8274a5

--
D. Richard Hipp
[hidden email]
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
12