bug#60487: string-ref segfaults with n < 0 on Guile 3.0.8

Ludovic Courtès <[email protected]>
Newsgroups gmane.lisp.guile.bugs
Message-ID <[email protected]>
Hi,

[email protected] skribis:

> The following code results in a segmentation fault on Guile
> 3.0.8-deb+3.0.8-2 (obtained from the Debian repositories):
>     (string-ref "my string" -3)

I can reproduce it with 3.0.8, where I get this backtrace:

--8<---------------cut here---------------start------------->8---
scheme@(guile-user)> (string-ref "my string" -3)

Thread 1 "guile" received signal SIGSEGV, Segmentation fault.
0x00007ffff7f419d9 in scm_is_values (x=<optimized out>) at values.h:30
30      values.h: No such file or directory.
(gdb) bt
#0  0x00007ffff7f419d9 in scm_is_values (x=<optimized out>) at values.h:30
#1  vm_debug_engine (thread=0x7ffff75c1d80) at vm-engine.c:974
#2  0x00007ffff7f4c5d9 in scm_call_n (proc=<optimized out>, argv=<optimized out>, nargs=5)
    at vm.c:1610
#3  0x00007ffff7eb8571 in scm_apply_0 (proc=#<program 7ffff5c4e960>, args=()) at eval.c:603
#4  0x00007ffff7f3dc8d in scm_throw (key=out-of-range, 
    args=<error reading variable: ERROR: Cannot access memory at address 0x0>0x7ffff2bb2c30)
    at throw.c:262
#5  0x00007ffff7f3dca9 in scm_ithrow (key=<optimized out>, args=<optimized out>, 
    no_return=<optimized out>) at throw.c:457
#6  0x00007ffff7eb5245 in scm_error_scm (key=key@entry=out-of-range, subr=<optimized out>, 
    message=message@entry="Value out of range ~S to< ~S: ~S", 
    args=args@entry=<error reading variable: ERROR: Cannot access memory at address 0x0>0x7ffff2bb2c70, data=data@entry=(4611686018427387901)) at error.c:90
#7  0x00007ffff7eb52a0 in scm_error (key=out-of-range, subr=0x0, message=<optimized out>, 
    args=<error reading variable: ERROR: Cannot access memory at address 0x0>0x7ffff2bb2c70, 
    rest=(4611686018427387901)) at error.c:62
#8  0x00007ffff7f02dd7 in range_error (bad_val=bad_val@entry=4611686018427387901, 
    min=min@entry=<error reading variable: ERROR: Cannot access memory at address 0x0>0x0, 
    max=#<bignum 7ffff2baeda0>) at numbers.c:6611
#9  0x00007ffff7f04dfb in scm_to_uint64 (arg=4611686018427387901) at integers.c:259
#10 0x00007ffff7f42215 in vm_debug_engine (thread=0x7ffff75c1d80) at vm-engine.c:1533
#11 0x00007ffff7f4c5d9 in scm_call_n (proc=<optimized out>, argv=<optimized out>, nargs=1)
    at vm.c:1610
#12 0x00007ffff7eb4457 in scm_primitive_eval (exp=<optimized out>, 
    exp@entry=((@ (ice-9 control) %) (begin (load-user-init) ((@ (ice-9 top-repl) top-repl)))))
    at eval.c:671
#13 0x00007ffff7eba4b6 in scm_eval (
    exp=((@ (ice-9 control) %) (begin (load-user-init) ((@ (ice-9 top-repl) top-repl)))), 
    module_or_state="#<struct module>" = {...}) at eval.c:705
#14 0x00007ffff7f1e3b6 in scm_shell (argc=1, argv=0x7fffffffd058) at script.c:357
--8<---------------cut here---------------end--------------->8---

Fortunately, this was fixed recently in
c0004442b7691f59a0e37869ef288eb26382ad9e.

Thanks!

Ludo’.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.