Redefining for-each makes STklos crash (?)

[jpellegrini]

Hi @egallesio !

Look what happened:

stklos> (for-each write '(1 2 3))
123stklos> (print write '(1 2 3))
#[primitive write](1 2 3)
stklos> (define for-each print)
;; for-each
stklos> for-each
Received a SIGSGV signal.
Try to augment stack size (--stack-size option).
If the problem persists, send a mail to <[email protected]>

I suppose that the code that accesses variable values uses whatever the current version of for-each is. Or is this something else?
If it helps, here's the stacktrace (from gdb):

stklos> for-each

Thread 1 "stklos" received signal SIGSEGV, Segmentation fault.
hash_string (string=0x7fff0001001b <error: Cannot access memory at address 0x7fff0001001b>) at hash.c:87
87	  for (c = *string; c ; c = *string++) {
(gdb) where
#0  hash_string (string=0x7fff0001001b <error: Cannot access memory at address 0x7fff0001001b>) at hash.c:87
#1  0x000055555558194f in hash_get_variable (h=0x7ffff7f86f58, v=0x7ffff3ed1720, index=0x7fffffffc39c) at hash.c:350
#2  0x00005555555819df in STk_hash_get_variable (h=0x7ffff7f86f58, v=0x7ffff3ed1720) at hash.c:361
#3  0x0000555555579485 in STk_lookup (symbol=0x7ffff3ed1720, env=0x7ffff7f86f30, ref=0x7fffffffc4b0, err_if_unbound=0) at env.c:697
#4  0x00005555555abee7 in run_vm (vm=0x7ffff7f90f00) at vm.c:1030
#5  0x00005555555aa6a7 in STk_C_apply (func=0x7ffff3c2cd70, nargs=1) at vm.c:508
#6  0x00005555555b1e5d in STk_raise_exception (cond=0x7ffff3dd0d80) at vm.c:1895
#7  0x0000555555577704 in STk_raise (obj=0x7ffff3dd0d80) at cond.c:471
#8  0x00005555555b15eb in run_vm (vm=0x7ffff7f90f00) at vm.c:1796
#9  0x00005555555aa6a7 in STk_C_apply (func=0x7ffff3c31c30, nargs=1) at vm.c:508
#10 0x00005555555b1e5d in STk_raise_exception (cond=0x7ffff3dd0d80) at vm.c:1895
#11 0x000055555557a012 in STk_error (format=0x5555555c96c8 "bad function ~S. Cannot be applied") at error.c:193
#12 0x00005555555b1bfb in run_vm (vm=0x7ffff7f90f00) at vm.c:1843
#13 0x00005555555aa6a7 in STk_C_apply (func=0x7ffff3c31d20, nargs=0) at vm.c:508
#14 0x00005555555aab94 in STk_call_for_values (prod=0x7ffff3c31d20) at vm.c:612
#15 0x00005555555b15eb in run_vm (vm=0x7ffff7f90f00) at vm.c:1796
#16 0x00005555555aa6a7 in STk_C_apply (func=0x7ffff3c31e60, nargs=0) at vm.c:508
#17 0x00005555555aab94 in STk_call_for_values (prod=0x7ffff3c31e60) at vm.c:612
#18 0x00005555555b15eb in run_vm (vm=0x7ffff7f90f00) at vm.c:1796
#19 0x00005555555b297a in STk_boot_from_C () at vm.c:2235
#20 0x000055555559fe2c in main (argc=0, argv=0x7fffffffdf60) at stklos.c:241

Also, I tried this:

stklos> (define (new-for-each . args) (print 'NEW-FOR-EACH) (apply for-each args))
;; new-for-each
stklos> (new-for-each print '(-1 -2 -3))
NEW-FOR-EACH
-1
-2
-3
stklos> (define for-each new-for-each)
;; for-each
stklos> (new-for-each print '(-1 -2 -3))

Thread 1 "stklos" received signal SIGSEGV, Segmentation fault.
hash_string (string=0x7fff0001001b <error: Cannot access memory at address 0x7fff0001001b>) at hash.c:87
87	  for (c = *string; c ; c = *string++) {

That should definitely have worked...

[jpellegrini]

Ah - the same happens with pair?. It seems that the REPL uses the current version of pair? in the STklos module:

stklos> (define pair? -)
#[condition &error-message 139738675920896]: `(bold red)' is a bad number

[egallesio]

Hello @jpellegrini ,

I'm trying to correct this problem, and it is not so simple (Iit implies numerous modifications in the library). More news, when I have finished.

[jpellegrini]

I'm trying to correct this problem, and it is not so simple (Iit implies numerous modifications in the library). More news, when I have finished.

Ok, no problem!

[egallesio]

Hi @jpellegrini,

I think I have (finally) finished with this issue. Correcting it necessitates a big reorganization of the lib files, and nearly all the modification I made during the rewriting ends most of the time with a corrupted boot image that obliged me to restart from a previous version. Hence, the time, it took to do fix the Issue.

Anyway, it seems to be OK now.However, I will commit the bug fix with the new macros, since I have started to work on my current version and back porting it to the Github version, would be too long.

[jpellegrini]

Hi @egallesio !

I see the new macro code was pushed! That's great! 🎆

And I see also that there is a fix to this issue. I'll check my implementation of SRFI-125 (which is where this issue first appeared) and get back to tell if it works now.

[egallesio]

Hi Jeronimo,

Yes it should work now. Tel me.

[jpellegrini]

I have re-written SRFI-125 without using the "current binding of" Scheme symbols, and it doesn't override them until they're exported, so that works fine.

Also, STklos doesn't crash anymore when for-each is redefined. And all examples in this issue work as expected... So I think we can close this one. #368 however could still be an issue (maybe?) I'll take a better look at that one