Probably a HPPA specific problem.
Created attachment 562978 [details] dev-scheme:guile-2.2.3:20190127-105304.log
/work/guile-2.2.3/libguile # gdb .libs/guile core GNU gdb (Gentoo 8.2.1 p1) 8.2.1 Copyright (C) 2018 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 "hppa2.0-unknown-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <https://bugs.gentoo.org/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Really redefine built-in command "frame"? (y or n) [answered Y; input not from terminal] Really redefine built-in command "thread"? (y or n) [answered Y; input not from terminal] Really redefine built-in command "start"? (y or n) [answered Y; input not from terminal] Reading symbols from .libs/guile...done. [New LWP 31355] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/libthread_db.so.1". Core was generated by `/var/tmp/portage/dev-scheme/guile-2.2.3/work/guile-2.2.3/libguile/.libs/guile -'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0xf8b53260 in vm_regular_engine (thread=0x416b1e00, vp=0x41722f78, registers=0xfab6cf48, resume=0x4) at vm-engine.c:566 566 ip = SCM_PROGRAM_CODE (FP_REF (0)); gdb> where #0 0xf8b53260 in vm_regular_engine (thread=0x416b1e00, vp=0x41722f78, registers=0xfab6cf48, resume=0x4) at vm-engine.c:566 #1 0xf8b54bc4 in scm_call_n (proc=0x41722f78, proc@entry=0x601, argv=argv@entry=0x0, nargs=0xf8b96400, nargs@entry=0x0) at vm.c:1257 #2 0xf8aa1a68 in scm_call_0 (proc=proc@entry=0x601) at eval.c:481 #3 0xf8ad0b98 in scm_primitive_load_path (args=<optimized out>) at load.c:1251 #4 0xf8abc378 in scm_apply_subr (sp=<optimized out>, nslots=<optimized out>) at gsubr.c:305 #5 0xf8b51648 in vm_regular_engine (thread=0x416b1e00, vp=0x41722f78, registers=0xfab6c988, resume=0x4) at vm-engine.c:784 #6 0xf8b54bc4 in scm_call_n (proc=0x41722f78, proc@entry=0x601, argv=argv@entry=0x0, nargs=0xf8b96400, nargs@entry=0x0) at vm.c:1257 #7 0xf8aa1a68 in scm_call_0 (proc=proc@entry=0x601) at eval.c:481 #8 0xf8ad0b98 in scm_primitive_load_path (args=<optimized out>) at load.c:1251 #9 0xf8ad1398 in scm_c_primitive_load_path (filename=filename@entry=0xf8b739e0 "ice-9/boot-9") at load.c:1267 #10 0xf8ac4818 in scm_load_startup_files () at init.c:249 #11 0xf8ac4f9c in scm_i_init_guile (base=base@entry=0xf8eeeec0) at init.c:534 #12 0xf8b3c8a4 in scm_i_init_thread_for_guile (base=0xf8eeeec0, dynamic_state=0xfc6861e4) at threads.c:586 #13 0xf8b3c8f0 in with_guile (base=0x41722f78, base@entry=0xf8eeeec0, data=0xfc6861e4, data@entry=0xfab6c4c8) at threads.c:654 #14 0xf8224114 in GC_call_with_stack_base (fn=fn@entry=0xf8b3c8c4 <with_guile>, arg=arg@entry=0xfab6c4c8) at /var/tmp/portage/dev-libs/boehm-gc-7.6.4/work/gc-7.6.4/misc.c:1949 #15 0xf8b3cd94 in scm_i_with_guile (dynamic_state=<optimized out>, data=0xfab6c4c8, func=0xf8ac45a4 <invoke_main_func>) at threads.c:704 #16 scm_with_guile (func=func@entry=0xf8ac45a4 <invoke_main_func>, data=data@entry=0xfab6c448) at threads.c:710 #17 0xf8ac48ac in scm_boot_guile (argc=0x6, argv=0xfc6861e4, main_func=<optimized out>, closure=<optimized out>) at init.c:323 #18 0x415858bc in main (argc=0x41722f78, argv=0xf8b96400 <jump_table_>) at guile.c:101
vm-engine.c is from guile-2.0*, I think.
(In reply to Jeroen Roovers from comment #3) > vm-engine.c is from guile-2.0*, I think. Never mind. Please ignore.
Looks like 2.2 overhauled the stack frame code. On PARISC the stack grows up.
Or it's an endian problem. https://trac.macports.org/ticket/54124
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=26854
Created attachment 598296 [details] build.log (2.2.4, ppc) Stumbled over that one too on ppc. guile-2.2.4 built with current stable toolchain.
/var/tmp/portage/dev-scheme/guile-2.2.6/work/guile-2.2.6 # gdb libguile/.libs/guile ../../work/guile-2.2.6/libguile/core GNU gdb (Gentoo 8.3.1 vanilla) 8.3.1 Copyright (C) 2019 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 "hppa2.0-unknown-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <https://bugs.gentoo.org/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Really redefine built-in command "frame"? (y or n) [answered Y; input not from terminal] Really redefine built-in command "thread"? (y or n) [answered Y; input not from terminal] Really redefine built-in command "start"? (y or n) [answered Y; input not from terminal] Reading symbols from libguile/.libs/guile... [New LWP 6545] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/libthread_db.so.1". Core was generated by `/var/tmp/portage/dev-scheme/guile-2.2.6/work/guile-2.2.6/libguile/.libs/guile -'. Program terminated with signal SIGSEGV, Segmentation fault. #0 vm_regular_engine (thread=0xf8e45e10, vp=0xf8e06f78, registers=0xfa07e288, resume=0x4) at vm-engine.c:567 567 ip = SCM_PROGRAM_CODE (FP_REF (0)); gdb> where #0 vm_regular_engine (thread=0xf8e45e10, vp=0xf8e06f78, registers=0xfa07e288, resume=0x4) at vm-engine.c:567 #1 0xf8523e98 in scm_call_n (proc=0xf8e45e10, argv=<optimized out>, nargs=0x20000000) at vm.c:1260 #2 0xf847305c in scm_call_0 (proc=<optimized out>) at eval.c:479 #3 0xf84a137c in scm_primitive_load_path (args=<optimized out>) at load.c:1251 #4 0xf848cefc in scm_apply_subr (sp=<optimized out>, nslots=<optimized out>) at gsubr.c:305 #5 0xf851d224 in vm_regular_engine (thread=0xf8e45e10, vp=0xf8e06f78, registers=0xfa07dd08, resume=0x4) at vm-engine.c:786 #6 0xf8523e98 in scm_call_n (proc=0xf8e45e10, argv=<optimized out>, nargs=0x20000000) at vm.c:1260 #7 0xf847305c in scm_call_0 (proc=<optimized out>) at eval.c:479 #8 0xf84a137c in scm_primitive_load_path (args=<optimized out>) at load.c:1251 #9 0xf84a1ba4 in scm_c_primitive_load_path (filename=<optimized out>) at load.c:1267 #10 0xf8495264 in scm_load_startup_files () at init.c:250 #11 0xf84959e8 in scm_i_init_guile (base=<optimized out>) at init.c:535 #12 0xf850c0a0 in scm_i_init_thread_for_guile (dynamic_state=0x20000000, base=0xf8565400 <jump_table_>) at threads.c:586 #13 scm_i_init_thread_for_guile (base=0xf8565400 <jump_table_>, dynamic_state=0x20000000) at threads.c:564 #14 0xf850c128 in with_guile (base=0x6, base@entry=<error reading variable: value has been optimized out>, data=0xf8565400 <jump_table_>, data@entry=<error reading variable: value has been optimized out>) at threads.c:654 #15 0xf751d358 in GC_call_with_stack_base (fn=<optimized out>, arg=<optimized out>) at /var/tmp/portage/dev-libs/boehm-gc-8.0.4/work/gc-8.0.4/extra/../misc.c:2106 #16 0xf850cb2c in scm_i_with_guile (dynamic_state=<optimized out>, data=<optimized out>, func=<optimized out>) at threads.c:704 #17 scm_with_guile (func=<optimized out>, data=<optimized out>) at threads.c:710 #18 0xf84952f8 in scm_boot_guile (argc=0x0, argv=0x6, main_func=0xf8e45e10, closure=0x20000000) at init.c:324 #19 0x42e69870 in main (argc=0x6, argv=0x20000000) at guile.c:101 gdb> t a a bt full Id Target Id Frame * 1 Thread 0xf8efe180 (LWP 6545) vm_regular_engine (thread=0xf8e45e10, vp=0xf8e06f78, registers=0xfa07e288, resume=0x4) at vm-engine.c:567
With -O0: #0 vm_regular_engine (thread=0xf8e45e00, vp=0xf8e07f78, registers=0xfa627f00, resume=0x0) at vm-engine.c:573 573 NEXT (0); gdb> where #0 vm_regular_engine (thread=0xf8e45e00, vp=0xf8e07f78, registers=0xfa627f00, resume=0x0) at vm-engine.c:573 #1 0xf85b355c in scm_call_n (proc=0xf8e22510, argv=0x0, nargs=0x0) at vm.c:1260 #2 0xf84851c4 in scm_call_0 (proc=0xf8e22510) at eval.c:479 #3 0xf84cf758 in scm_primitive_load_path (args=0xf8e2cff0) at load.c:1251 #4 0xf84b3708 in scm_apply_subr (sp=0xf8db3f30, nslots=0x2) at gsubr.c:305 #5 0xf8590e70 in vm_regular_engine (thread=0xf8e45e00, vp=0xf8e07f78, registers=0xfa626d40, resume=0x0) at vm-engine.c:786 #6 0xf85b355c in scm_call_n (proc=0xf8e17f18, argv=0x0, nargs=0x0) at vm.c:1260 #7 0xf84851c4 in scm_call_0 (proc=0xf8e17f18) at eval.c:479 #8 0xf84cf758 in scm_primitive_load_path (args=0xf8e11c50) at load.c:1251 #9 0xf84cf83c in scm_c_primitive_load_path (filename=0xf85e2f68 "ice-9/boot-9") at load.c:1267 #10 0xf84c17f4 in scm_load_startup_files () at init.c:250 #11 0xf84c233c in scm_i_init_guile (base=0xfa626908) at init.c:535 #12 0xf85840b8 in scm_i_init_thread_for_guile (base=0xfa626908, dynamic_state=0x0) at threads.c:586 #13 0xf8584304 in with_guile (base=0xfa626908, data=0xfa626888) at threads.c:654 #14 0xf751d358 in GC_call_with_stack_base (fn=<optimized out>, arg=<optimized out>) at /var/tmp/portage/dev-libs/boehm-gc-8.0.4/work/gc-8.0.4/extra/../misc.c:2106 #15 0xf8584540 in scm_i_with_guile (func=0xfa6267c0, data=0xf860ae24 <__gmp_set_memory_functions@got.plt>, dynamic_state=0xf86096a6 <*ABS*@got.plt+2>) at threads.c:704 Backtrace stopped: previous frame inner to this frame (corrupt stack?)
Unrelated.
https://buildd.debian.org/status/fetch.php?pkg=guile-2.2&arch=hppa&ver=2.2.6%2B1-1&stamp=1567471040&raw=1 Seems to work for Debian PARISC.
What about 2.2.6?
(In reply to Andreas Sturmlechner from comment #13) > What about 2.2.6? No change.
same on sparc
"I worked around the problem in Guile 2.2.6 by moving away prebuilt/32-bit-big-endian so the build doesn't use the prebuilt files; but the "bootstrap" part of the build is slow." Worth a try.
(In reply to Jeroen Roovers from comment #16) > "I worked around the problem in Guile 2.2.6 by moving away > prebuilt/32-bit-big-endian so the build doesn't use the prebuilt > files; but the "bootstrap" part of the build is slow." > > Worth a try. Doing mv prebuilt/32-bit-big-endian{.broken} || die gets me past that failure point. I can't really acknowledge that it makes the build significantly slower.
mv prebuilt/32-bit-big-endian{,.broken} || die obviously.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=01e5641789176f37506a2064ec2f555e66c961ef commit 01e5641789176f37506a2064ec2f555e66c961ef Author: Jeroen Roovers <jer@gentoo.org> AuthorDate: 2019-12-26 14:15:31 +0000 Commit: Jeroen Roovers <jer@gentoo.org> CommitDate: 2019-12-26 14:15:50 +0000 dev-scheme/guile: Do not use prebuilt/32-bit-big-endian Package-Manager: Portage-2.3.83, Repoman-2.3.20 Bug: https://bugs.gentoo.org/676468 Signed-off-by: Jeroen Roovers <jer@gentoo.org> dev-scheme/guile/guile-2.2.3.ebuild | 3 +++ dev-scheme/guile/guile-2.2.4.ebuild | 3 +++ dev-scheme/guile/guile-2.2.6.ebuild | 3 +++ 3 files changed, 9 insertions(+)
(In reply to Jeroen Roovers from comment #17) > Doing > > mv prebuilt/32-bit-big-endian{.broken} || die > > gets me past that failure point. I can't really acknowledge that it makes > the build significantly slower. It does slow down the build significantly, but that happens after reaching the (previous) failure point. Still, if that is the only way it will build. :-/
Yeah, looks like 'prebuilt' bytecode is now valid for 32-bit BE. It was also built on guile-2.2.3 for 2.2.6 but maybe it's fine. I don't see major bytecode changes. To be on a safe side I rebuilt 2.2.3 on sparc32 and attempted to disassemble just bootstrapped and prebuilt foreign.go file as an example: .../work/guile-2.2.3 $ meta/build-env guile -c '((@ (system vm disassembler) disassemble-file) "bootstrap/system/foreign.go")' && echo ok ... 1963 (make-short-immediate 0 2052) ;; #<unspecified> 1964 (return-values 2) ;; 1 value ok .../work/guile-2.2.3 $ meta/build-env guile -c '((@ (system vm disassembler) disassemble-file) "prebuilt/32-bit-big-endian.broken/system/foreign.go")' ... Disassembly of <unnamed function> at #x98: Backtrace: 9 (apply-smob/1 #<catch-closure ef2ddf00>) In ice-9/boot-9.scm: 705:2 8 (call-with-prompt _ _ #<procedure default-prompt-handle…>) In ice-9/eval.scm: 619:8 7 (_ #(#(#<directory (guile-user) ef2c9910>))) In ice-9/command-line.scm: 181:18 6 (_ #<input: string ef5a4f50>) In unknown file: 5 (eval ((@ (system vm disassembler) disassemble-file) #) #) In system/vm/disassembler.scm: 464:4 4 (disassemble-image _ _) In system/vm/debug.scm: 121:17 3 (for-each-elf-symbol _ #<procedure ef2e4be8 at system/v…>) In system/vm/disassembler.scm: 475:9 2 (_ _) 338:16 1 (disassemble-buffer #<output: file /dev/pts/0> #vu8(# …) …) 291:14 0 (compute-labels #vu8(127 69 76 70 1 2 1 255 0 0 0 0 0 …) …) system/vm/disassembler.scm:291:14: In procedure compute-labels: In procedure vector-ref: Value out of range: 3678 I think it's a confirmation of broken prebuilt bytecode.
Reported upstream as http://debbugs.gnu.org/cgi/bugreport.cgi?bug=38772
2.2.4/2.2.6 builds fine now on ppc with the latest ebuild to bootstrap instead of using pre-built binaries.
Hello, fellow PPC users, I'm a FreeBSD developer mainly doing PPC-related fixes. While removing the bootstrap works for us when building guile 2, guile 3.0.7 still breaks. Is your experience on Gentoo the same?
(In reply to Piotr Kubaj from comment #24) > Hello, fellow PPC users, > > I'm a FreeBSD developer mainly doing PPC-related fixes. > > While removing the bootstrap works for us when building guile 2, guile 3.0.7 > still breaks. > Is your experience on Gentoo the same? Hi! Dakon just discovered https://debbugs.gnu.org/cgi/bugreport.cgi?bug=45214 which might sort us out.
Thanks! Indeed, -Oresolve-primitives -Ocps fixes build issue for us.
This appears fixed on 2.2.7. Does this ticket also apply to the 3.x branch, since it is still masked? Or should that be separate?
(In reply to matoro from comment #27) > This appears fixed on 2.2.7. Does this ticket also apply to the 3.x branch, > since it is still masked? Or should that be separate? You can see here https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-scheme/guile/guile-3.0.8.ebuild#n46 that this issue is already fixed in 3.x.
(In reply to Piotr Kubaj from comment #28) > (In reply to matoro from comment #27) > > This appears fixed on 2.2.7. Does this ticket also apply to the 3.x branch, > > since it is still masked? Or should that be separate? > > You can see here > https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-scheme/guile/guile-3.0.8. > ebuild#n46 that this issue is already fixed in 3.x. Thanks! So, should this ticket still be open if we also have fixed it downstream for all our 32-bit BE platforms?
