clisp-devel

Re: Build problem

[m_maass <m_...@we...>]

Dear all,

i have the same problem as Blake (12.3.2017),  with gcc and clang after
make check.

*** - handle_fault error2 ! address = 0xb00000050b9 not in
[0xb0000000000,0xb0000001098) !
SIGSEGV cannot be cured. Fault address = 0xb00000050b9.
GC count: 645
Space collected by GC: 942622064
Run time: 22 232000
Real time: 23 875937
GC time: 3 356000
Permanently allocated: 158648 bytes.
Currently in use: 6726592 bytes.
Free space: 1305988 bytes.
Makefile:25: die Regel für Ziel „tests“ scheiterte
make[1]: *** [tests] Speicherzugriffsfehler

Can someone give a hint?

Thanks

Re: Build problem

[Sam S. <sd...@gn...>]

Hi,

> * m_maass <z_znnff@jro.qr> [2017-03-15 12:01:52 +0100]:
>
> i have the same problem as Blake (12.3.2017),  with gcc and clang after
> make check.
>
> *** - handle_fault error2 ! address = 0xb00000050b9 not in
> [0xb0000000000,0xb0000001098) !
> SIGSEGV cannot be cured. Fault address = 0xb00000050b9.
> GC count: 645
> Space collected by GC: 942622064
> Run time: 22 232000
> Real time: 23 875937
> GC time: 3 356000
> Permanently allocated: 158648 bytes.
> Currently in use: 6726592 bytes.
> Free space: 1305988 bytes.
> Makefile:25: die Regel für Ziel „tests“ scheiterte
> make[1]: *** [tests] Speicherzugriffsfehler
>
> Can someone give a hint?

http://clisp.org/impnotes/clisp.html#bugs

-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1504
http://steingoldpsychology.com http://www.childpsy.net http://no2bds.org
http://jij.org http://mideasttruth.com http://think-israel.org
A language that does not change the way you think is not worth learning.

Re: Build problem

[Bruno H. <br...@cl...>]

Hi,

> i have the same problem as Blake (12.3.2017),  with gcc and clang after
> make check.
> 
> *** - handle_fault error2 ! address = 0xb00000050b9 not in
> [0xb0000000000,0xb0000001098) !

I'm seeing this as well, and not only on Linux/x86_64.

It's not a "classical" GC-safety bug: the DEBUG_GCSAFETY build does not
flag any violation of the GC-safety rules.

We will need additional tooling in order to track down this one.
I have some ideas (valdgrind, gcc -fsanitize, and others).
If you have other ideas how to isolate this kind of bug, please speak up!

Bruno

Re: Build problem

[<don...@is...>]

Could this be related to the MT problems?
I was thinking that possibly the failure in MT might be due to
choosing a different memory model than the one that was working
before, and that we might find out more by extending your memory
model test to try to build and run MT versions.

Bruno Haible writes:
 > Hi,
 > 
 > > i have the same problem as Blake (12.3.2017),  with gcc and clang after
 > > make check.
 > > 
 > > *** - handle_fault error2 ! address = 0xb00000050b9 not in
 > > [0xb0000000000,0xb0000001098) !
 > 
 > I'm seeing this as well, and not only on Linux/x86_64.
 > 
 > It's not a "classical" GC-safety bug: the DEBUG_GCSAFETY build does not
 > flag any violation of the GC-safety rules.
 > 
 > We will need additional tooling in order to track down this one.
 > I have some ideas (valdgrind, gcc -fsanitize, and others).
 > If you have other ideas how to isolate this kind of bug, please speak up!
 > 
 > Bruno

Re: Build problem

[Bruno H. <br...@cl...>]

Hi Don,

> Could this be related to the MT problems?
> I was thinking that possibly the failure in MT might be due to
> choosing a different memory model than the one that was working
> before, and that we might find out more by extending your memory
> model test to try to build and run MT versions.

For me, it crashes even without MT, and in different memory models:

Linux/x86_64:
  build-porting64-gcc-spvw_pure_blocks                 *** - APPLY: Too few arguments for #<STANDARD-GENERIC-FUNCTION COMPUTE-SLOTS>

Linux/arm:
build-porting32-gcc-spvw_pure_blocks/cbcstep3.log                KO Segmentation fault during streams tests

FreeBSD/i386:
build-porting32-gcc-wide/cbcstep3.log                             KO Signal 11

FreeBSD/x86_64:
build-porting64-gcc-generational_gc-multithread_gc/cbcstep3.log   Crash in steele7 tests
build-porting64-gcc-generational_gc-old_gc/cbcstep3.log           Crash in socket tests
build-porting64-gcc-safety0/cbcstep3.log                          Crash in steele7 tests
build-porting64-gcc-safety0-optimized/cbcstep3.log                Crash in steele7 tests

NetBSD/x86_64:
build-porting64-gcc-heapcodes-spvw_mixed_blocks/cbcstep3.log     Segmentation fault during path tests

OpenBSD/x86_64:
build-porting64-gcc-heapcodes/cbcstep3.log                        KO Segmentation fault during number tests
build-porting64-gcc-heapcodes-spvw_mixed_blocks/cbcstep3.log      KO Segmentation fault during number tests
build-porting64-gcc-heapcodes-spvw_pages/cbcstep3.log             KO Segmentation fault during number tests
build-porting64-gcc-one_free_bit_heapcodes/cbcstep3.log           KO Segmentation fault during number tests

Bruno

Re: Build problem

[Daniel J. <dan...@gm...>]

Which compiler version are you using? Did you upgrade it recently? Does it
also crash when compiled without optimisations (-O0) ?

Bruno Haible <br...@cl...> schrieb am Sa., 18. März 2017, 22:04:

> Hi Don,
>
> > Could this be related to the MT problems?
> > I was thinking that possibly the failure in MT might be due to
> > choosing a different memory model than the one that was working
> > before, and that we might find out more by extending your memory
> > model test to try to build and run MT versions.
>
> For me, it crashes even without MT, and in different memory models:
>
> Linux/x86_64:
>   build-porting64-gcc-spvw_pure_blocks                 *** - APPLY: Too
> few arguments for #<STANDARD-GENERIC-FUNCTION COMPUTE-SLOTS>
>
> Linux/arm:
> build-porting32-gcc-spvw_pure_blocks/cbcstep3.log                KO
> Segmentation fault during streams tests
>
> FreeBSD/i386:
> build-porting32-gcc-wide/cbcstep3.log                             KO
> Signal 11
>
> FreeBSD/x86_64:
> build-porting64-gcc-generational_gc-multithread_gc/cbcstep3.log   Crash in
> steele7 tests
> build-porting64-gcc-generational_gc-old_gc/cbcstep3.log           Crash in
> socket tests
> build-porting64-gcc-safety0/cbcstep3.log                          Crash in
> steele7 tests
> build-porting64-gcc-safety0-optimized/cbcstep3.log                Crash in
> steele7 tests
>
> NetBSD/x86_64:
> build-porting64-gcc-heapcodes-spvw_mixed_blocks/cbcstep3.log
>  Segmentation fault during path tests
>
> OpenBSD/x86_64:
> build-porting64-gcc-heapcodes/cbcstep3.log                        KO
> Segmentation fault during number tests
> build-porting64-gcc-heapcodes-spvw_mixed_blocks/cbcstep3.log      KO
> Segmentation fault during number tests
> build-porting64-gcc-heapcodes-spvw_pages/cbcstep3.log             KO
> Segmentation fault during number tests
> build-porting64-gcc-one_free_bit_heapcodes/cbcstep3.log           KO
> Segmentation fault during number tests
>
> Bruno
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> clisp-devel mailing list
> cli...@li...
> https://lists.sourceforge.net/lists/listinfo/clisp-devel
>