bug#32938: guile 2.2.4 crashes (u8-list->bytevector (make-bytevector 32 0))

[Josh Datko]

If you try to convert a bytevector, to a bytevector, using
u8-list->bytevector, guile crashes.

$ guile -q
GNU Guile 2.2.4
Copyright (C) 1995-2017 Free Software Foundation, Inc.

Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
This program is free software, and you are welcome to redistribute it
under certain conditions; type `,show c' for details.

Enter `,help' for help.
scheme@(guile-user)> (use-modules (rnrs bytevectors))
scheme@(guile-user)> (u8-list->bytevector (make-bytevector 32 0))
[1] 126190 abort (core dumped) guile -q


$ build-aux/config.guess
x86_64-pc-linux-gnu

This was the release version of guile downloaded from the site.

$ ./config.status --config
<<nothing>>

gdb output:

GNU Guile 2.2.4
Copyright (C) 1995-2017 Free Software Foundation, Inc.

Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
This program is free software, and you are welcome to redistribute it
under certain conditions; type `,show c' for details.

Enter `,help' for help.
scheme@(guile-user)> (use-modules (rnrs bytevectors))
scheme@(guile-user)> (u8-list->bytevector (make-bytevector 32))

Thread 1 "lt-guile" received signal SIGABRT, Aborted.
0x00007ffff74f6428 in __GI_raise (sig=***@entry=6)
at ../sysdeps/unix/sysv/linux/raise.c:54
54 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) backtrace
#0 0x00007ffff74f6428 in __GI_raise (sig=***@entry=6)
at ../sysdeps/unix/sysv/linux/raise.c:54
#1 0x00007ffff74f802a in __GI_abort () at abort.c:89
#2 0x00007ffff7ae7f72 in make_bytevector (
element_type=SCM_ARRAY_ELEMENT_TYPE_VU8, len=18446744073709551615)
at bytevectors.c:213
#3 scm_u8_list_to_bytevector (lst=0xa70640) at bytevectors.c:751
#4 0x00007ffff7b67961 in vm_debug_engine (thread=0x1f3ef,
vp=0x706f30, registers=0x6, resume=-145791960) at vm-engine.c:786
#5 0x00007ffff7b71802 in scm_call_n (proc=0x7ffff7fd9030,
argv=***@entry=0x7fffffffda88, nargs=***@entry=1) at vm.c:1257
#6 0x00007ffff7af28e7 in scm_primitive_eval (exp=***@entry=0x7befa0)
at eval.c:662
#7 0x00007ffff7af2943 in scm_eval (exp=0x7befa0,
module_or_state=***@entry=0x798140) at eval.c:696
#8 0x00007ffff7b3f4f0 in scm_shell (argc=1, argv=0x7fffffffe108)
at script.c:454
#9 0x00007ffff7b09cfd in invoke_main_func (body_data=0x7fffffffdfa0)
at init.c:340
#10 0x00007ffff7aeb68a in c_body (d=0x7fffffffdee0)
at continuations.c:422
#11 0x00007ffff7b6e78b in vm_regular_engine (thread=0x1f3ef,
vp=0x706f30, registers=0x6, resume=-145791960) at vm-engine.c:786
#12 0x00007ffff7b71802 in scm_call_n (proc=***@entry=0x6fc320,
argv=***@entry=0x0, nargs=***@entry=0) at vm.c:1257
#13 0x00007ffff7af1619 in scm_call_0 (proc=***@entry=0x6fc320)
at eval.c:481
#14 0x00007ffff7b60729 in catch (tag=***@entry=0x404, thunk=0x6fc320,
handler=0x6fc300, pre_unwind_handler=0x6fc2a0) at throw.c:137
#15 0x00007ffff7b60a95 in scm_catch_with_pre_unwind_handler (
key=***@entry=0x404, thunk=<optimized out>,
handler=<optimized out>, pre_unwind_handler=<optimized out>)
at throw.c:254
---Type <return> to continue, or q <return> to quit---
#16 0x00007ffff7b60c4f in scm_c_catch (tag=***@entry=0x404,
body=***@entry=0x7ffff7aeb680 <c_body>,
body_data=***@entry=0x7fffffffdee0,
handler=***@entry=0x7ffff7aeb920 <c_handler>,
handler_data=***@entry=0x7fffffffdee0,
pre_unwind_handler=***@entry=0x7ffff7aeb780
<pre_unwind_handler>, pre_unwind_handler_data=0x701b60) at throw.c:377
#17 0x00007ffff7aebc90 in scm_i_with_continuation_barrier (
body=***@entry=0x7ffff7aeb680 <c_body>,
body_data=***@entry=0x7fffffffdee0,
handler=***@entry=0x7ffff7aeb920 <c_handler>,
handler_data=***@entry=0x7fffffffdee0,
pre_unwind_handler=***@entry=0x7ffff7aeb780
<pre_unwind_handler>, pre_unwind_handler_data=0x701b60) at
continuations.c:360
#18 0x00007ffff7aebd75 in scm_c_with_continuation_barrier (
func=<optimized out>, data=<optimized out>) at continuations.c:456
#19 0x00007ffff7b5f1fc in with_guile (base=0x7fffffffdf40,
data=0x7fffffffdf70) at threads.c:661
#20 0x00007ffff726ac62 in GC_call_with_stack_base ()
from /usr/lib/x86_64-linux-gnu/libgc.so.1
#21 0x00007ffff7b5f5e8 in scm_i_with_guile (
dynamic_state=<optimized out>, data=0x7fffffffdf70,
func=0x7ffff7b09ce0 <invoke_main_func>) at threads.c:704
#22 scm_with_guile (func=***@entry=0x7ffff7b09ce0 <invoke_main_func>,
data=***@entry=0x7fffffffdfa0) at threads.c:710
#23 0x00007ffff7b09ec2 in scm_boot_guile (argc=***@entry=1,
argv=***@entry=0x7fffffffe108,
main_func=***@entry=0x400b00 <inner_main>,
closure=***@entry=0x0) at init.c:323
#24 0x000000000040098c in main (argc=1, argv=0x7fffffffe108)
at guile.c:101
(gdb)

[Mark H Weaver]

Post by Josh Datko
If you try to convert a bytevector, to a bytevector, using
u8-list->bytevector, guile crashes.
$ guile -q
GNU Guile 2.2.4
Copyright (C) 1995-2017 Free Software Foundation, Inc.
Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
This program is free software, and you are welcome to redistribute it
under certain conditions; type `,show c' for details.
Enter `,help' for help.
[1] 126190 abort (core dumped) guile -q

Indeed, the code in 'u8-list->bytevector' that's supposed to validate
that its argument is a list, is broken.

'u8-list->bytevector' uses the SCM_VALIDATE_LIST_COPYLEN macro to
validate the list and simultaneously compute its length. That macro
implicitly assumes that its third operand will be a variable of type
'long', because the result of 'scm_ilength' is assigned to it, and
'scm_ilength' returns a 'long'.

After storing the result to the variable, it checks to see if the result
is negative, which would indicate that the operand wasn't a proper list.

The bytevector operations that convert integer lists to bytevectors pass
a variable of type 'size_t' to SCM_VALIDATE_LIST_COPYLEN. Since
'size_t' is unsigned, the -1 result from 'scm_ilength' was interpreted
as ULONG_MAX instead.

Thanks for the report.

Mark

[Mark H Weaver]

Post by Josh Datko
If you try to convert a bytevector, to a bytevector, using
u8-list->bytevector, guile crashes.

Fixed in commit fe73fedab40cf716cc39139a61c078e2c9a2f37f on the
stable-2.2 branch. Thanks for the report!

Mark