It would be my pleasure to get some light tossed on this ... so here is
a very clean compile ( no -std in CFLAGS at all on gcc 9.2.0 ) and the
tests look like so :
This is a test script error. Should now be fixed here:
https://sqlite.org/src/info/b0b655625cf491c8
What version of Tcl are you
On 24/11/62 06:18, Dennis Clarke wrote:
On 11/23/19 4:46 PM, Dan Kennedy wrote:
Some follow up and thank you all for looking at this.
Using this mornings trunk/current/head I do see the tests running well
with these little exceptions :
boe13$ pwd
/opt/bw/build/sqlite_20191121213415_rhel_
On 11/23/19 4:46 PM, Dan Kennedy wrote:
Some follow up and thank you all for looking at this.
Using this mornings trunk/current/head I do see the tests running well
with these little exceptions :
boe13$ pwd
/opt/bw/build/sqlite_20191121213415_rhel_74_3.10.0-693.el7.x86_64.006
... build cl
Some follow up and thank you all for looking at this.
Using this mornings trunk/current/head I do see the tests running well
with these little exceptions :
boe13$ pwd
/opt/bw/build/sqlite_20191121213415_rhel_74_3.10.0-693.el7.x86_64.006
... build clean as usual :-)
tests run nicely now u
On 11/21/19 5:15 PM, Dan Kennedy wrote:
On 22/11/62 00:06, Jens Alfke wrote:
On Nov 21, 2019, at 7:01 AM, Richard Hipp wrote:
The memset() just forces the bug to the surface in builds where the
ckmalloc()/ckfree() routines of TCL are using caching that prevents
valgrind/ASAN from seeing the
On 22/11/62 00:06, Jens Alfke wrote:
On Nov 21, 2019, at 7:01 AM, Richard Hipp wrote:
The memset() just forces the bug to the surface in builds where the
ckmalloc()/ckfree() routines of TCL are using caching that prevents
valgrind/ASAN from seeing the use-after-free. The memset() is not
par
> On Nov 21, 2019, at 7:01 AM, Richard Hipp wrote:
>
> The memset() just forces the bug to the surface in builds where the
> ckmalloc()/ckfree() routines of TCL are using caching that prevents
> valgrind/ASAN from seeing the use-after-free. The memset() is not
> part of the bug fixx itself, bu
On 11/21/19, Warren Young wrote:
> On Nov 21, 2019, at 3:54 AM, Richard Hipp wrote:
>>
>> The solution is here: https://www.sqlite.org/src/info/0d1055a5da8274a5
>
> memset before free? Why does that help?
The memset() just forces the bug to the surface in builds where the
ckmalloc()/ckfree() ro
On Nov 21, 2019, at 3:54 AM, Richard Hipp wrote:
>
> The solution is here: https://www.sqlite.org/src/info/0d1055a5da8274a5
memset before free? Why does that help?
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.
The solution is here: https://www.sqlite.org/src/info/0d1055a5da8274a5
--
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
On 11/20/19 1:04 PM, Richard Hipp wrote:
On 11/20/19, Dennis Clarke 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 obse
On 11/20/19 3:45 PM, Richard Hipp wrote:
On 11/20/19, Dennis Clarke 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
On Nov 19, 2019, at 8:43 PM, Dennis Clarke wrote:
>
> On 11/20/19 2:26 AM, Warren Young wrote:
>> On Nov 19, 2019, at 7:06 PM, Dennis Clarke wrote:
>>>
>>> gmake: *** [Makefile:1256: tcltest] Segmentation fault (core dumped)
>> …
>>> CC=/opt/bw/gcc9/bin/gcc
>> You’re using a nonstandard compile
On 11/20/19, Richard Hipp wrote:
> On 11/20/19, Dennis Clarke 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.
On 11/20/19, Dennis Clarke 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
d...@sqlite.org
___
sqlite-users mailing
On 11/20/19 1:04 PM, Richard Hipp wrote:
On 11/20/19, Dennis Clarke 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 obse
On 11/20/19, Dennis Clarke 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
On 11/20/19 12:12 PM, Richard Hipp wrote:
On 11/19/19, Dennis Clarke 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
On 11/19/19, Dennis Clarke 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_
On 11/20/19 2:26 AM, Warren Young wrote:
On Nov 19, 2019, at 7:06 PM, Dennis Clarke 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
On Nov 19, 2019, at 7:06 PM, Dennis Clarke 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
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
gt;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
>wrote:
>>
>>>
>>> Same question as a few days ago.
>>>
>>>
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
> On Nov 19, 2019, at 5:29 AM, Dennis Clarke 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
_
On 11/19/19 12:32 AM, Scott Robison wrote:
On Mon, Nov 18, 2019 at 3:44 PM Dennis Clarke 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
On Mon, Nov 18, 2019 at 3:44 PM Dennis Clarke 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
> On Nov 18, 2019, at 2:44 PM, Dennis Clarke 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 com
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 result
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
30 matches
Mail list logo
