[racket] runiing racket 6.1.1 under valgrind

Discussion:

Sergey Pinaev

2015-02-27 10:56:52 UTC

hi.
i'm trying to run racket (v6.1.1.8) under valgrind.
(valgrind --num-callers=24 --vex-iropt-register-updates=allregs-at-each-insn --tool=memcheck --trace-children=yes /var/tmp/racket/bin/racket)

but racket segfaults when scheme_handle_stack_overflow
calls scheme_longjmpup(&scheme_overflow_jmp->cont)
because scheme_overflow_jmp is NULL at this moment.
full backtrace (as told by valgrind):

==18730== Invalid read of size 8
==18730== at 0x4F63897: scheme_longjmpup (setjmpup.c:633)
==18730== by 0x4CB3B06: scheme_handle_stack_overflow (eval.c:489)
==18730== by 0x4FD0A01: scheme_thread_block (thread.c:4969)
==18730== by 0x4FCEF8A: scheme_out_of_fuel (thread.c:4434)
==18730== by 0x4DFBD80: reverse_prim (list.c:1357)
==18730== by 0x4DFBB1D: scheme_reverse (list.c:1321)
==18730== by 0x4F95F04: scheme_lookup_prefab_type (struct.c:5408)
==18730== by 0x4FC2E70: scheme_init_thread_places (thread.c:632)
==18730== by 0x4C94356: place_instance_init (env.c:533)
==18730== by 0x4C938A6: scheme_engine_instance_init (env.c:305)
==18730== by 0x4C93714: scheme_basic_env (env.c:226)
==18730== by 0x406CCD: ??? (in /var/tmp/racket/bin/racket)
==18730== by 0x4071D8: ??? (in /var/tmp/racket/bin/racket)
==18730== by 0x4C4A53E: do_main_stack_setup (salloc.c:198)
==18730== by 0x4C4A5B1: scheme_main_stack_setup (salloc.c:310)
==18730== by 0x4070DD: ??? (in /var/tmp/racket/bin/racket)
==18730== by 0x4070A6: main (in /var/tmp/racket/bin/racket)
==18730== Address 0x8 is not stack'd, malloc'd or (recently) free'd
==18730==
SIGSEGV MAPERR si_code 1 fault on addr 0x8

if i modify place_instance_init() to call scheme_create_overflow()
after scheme_init_overflow() - things getting more worse.
valgrind complaints about:

==22609== Invalid read of size 8
==22609== at 0x501B9DB: block_cache_compact (block_cache.c:325)
==22609== by 0x501D216: mmu_should_compact_page (vm.c:191)
==22609== by 0x5027F94: do_heap_compact (newgc.c:4112)
==22609== by 0x5029BBA: garbage_collect (newgc.c:4912)
==22609== by 0x501DFDF: collect_now (newgc.c:985)
==22609== by 0x501ED08: allocate_slowpath (newgc.c:1375)
==22609== by 0x501EE82: allocate (newgc.c:1439)
==22609== by 0x501F2AF: GC_malloc_atomic (newgc.c:1557)
==22609== by 0x4F62F1D: scheme_copy_stack (setjmpup.c:298)
==22609== by 0x4F6364A: scheme_setjmpup_relative (setjmpup.c:556)
==22609== by 0x4CB3781: scheme_handle_stack_overflow (eval.c:447)
==22609== by 0x4FD0A09: scheme_thread_block (thread.c:4969)
==22609== by 0x4CE2775: scheme_really_create_overflow (fun.c:1087)
==22609== by 0x4CE2A7D: scheme_create_overflow (fun.c:1147)
==22609== by 0x4C94360: place_instance_init (env.c:534)
==22609== by 0x4C938A6: scheme_engine_instance_init (env.c:305)
==22609== by 0x4C93714: scheme_basic_env (env.c:226)
==22609== by 0x406CCD: ??? (in /var/tmp/racket/bin/racket)
==22609== by 0x4071D8: ??? (in /var/tmp/racket/bin/racket)
==22609== by 0x4C4A53E: do_main_stack_setup (salloc.c:198)
==22609== by 0x4C4A5B1: scheme_main_stack_setup (salloc.c:310)
==22609== by 0x4070DD: ??? (in /var/tmp/racket/bin/racket)
==22609== by 0x4070A6: main (in /var/tmp/racket/bin/racket)
==22609== Address 0x5ac2290 is 8 bytes after a block of size 104 alloc'd
==22609== at 0x4A069EE: malloc (vg_replace_malloc.c:270)
==22609== by 0x501ABA2: ofm_malloc (newgc.c:335)
==22609== by 0x501ABD5: ofm_malloc_zero (newgc.c:342)
==22609== by 0x501B312: block_cache_create (block_cache.c:65)
==22609== by 0x501D038: mmu_create (vm.c:101)
==22609== by 0x5025423: NewGC_initialize (newgc.c:2942)
==22609== by 0x5025533: init_type_tags_worker (newgc.c:2976)
==22609== by 0x5025831: GC_construct_child_gc (newgc.c:3026)
==22609== by 0x5025AF2: GC_switch_out_master_gc (newgc.c:3092)
==22609== by 0x4C9388B: scheme_engine_instance_init (env.c:297)
==22609== by 0x4C93714: scheme_basic_env (env.c:226)
==22609== by 0x406CCD: ??? (in /var/tmp/racket/bin/racket)
==22609== by 0x4071D8: ??? (in /var/tmp/racket/bin/racket)
==22609== by 0x4C4A53E: do_main_stack_setup (salloc.c:198)
==22609== by 0x4C4A5B1: scheme_main_stack_setup (salloc.c:310)
==22609== by 0x4070DD: ??? (in /var/tmp/racket/bin/racket)
==22609== by 0x4070A6: main (in /var/tmp/racket/bin/racket)

and after that racket eats cpu and memory till killed by OOM killer.
looking at strace - all that it is do - writing (and reading) all
alphabet characters one by one to pipe.

any ideas?

Отправлено моей секретаршей из моего Bentley с моего Vertu

--
Sergey Pinaev <***@jet.msk.su>
____________________
Racket Users list:
http://list

Matthew Flatt

2015-02-27 15:00:34 UTC

Permalink

That's as far as I've ever gotten with memcheck. Racket manipulates the
C stack in ways that are far outside of what is supposed to be allowed,
and I think it confuses Valgrind. I don't know if there's a way to tell
Valgrind to allow this behavior and/or to give up on checking
operations related to the stack, but I didn't find one in the little
time I spent looking before.

Post by Sergey Pinaev
hi.
i'm trying to run racket (v6.1.1.8) under valgrind.
(valgrind --num-callers=24 --vex-iropt-register-updates=allregs-at-each-insn
--tool=memcheck --trace-children=yes /var/tmp/racket/bin/racket)
but racket segfaults when scheme_handle_stack_overflow
calls scheme_longjmpup(&scheme_overflow_jmp->cont)
because scheme_overflow_jmp is NULL at this moment.
==18730== Invalid read of size 8
==18730== at 0x4F63897: scheme_longjmpup (setjmpup.c:633)
==18730== by 0x4CB3B06: scheme_handle_stack_overflow (eval.c:489)
==18730== by 0x4FD0A01: scheme_thread_block (thread.c:4969)
==18730== by 0x4FCEF8A: scheme_out_of_fuel (thread.c:4434)
==18730== by 0x4DFBD80: reverse_prim (list.c:1357)
==18730== by 0x4DFBB1D: scheme_reverse (list.c:1321)
==18730== by 0x4F95F04: scheme_lookup_prefab_type (struct.c:5408)
==18730== by 0x4FC2E70: scheme_init_thread_places (thread.c:632)
==18730== by 0x4C94356: place_instance_init (env.c:533)
==18730== by 0x4C938A6: scheme_engine_instance_init (env.c:305)
==18730== by 0x4C93714: scheme_basic_env (env.c:226)
==18730== by 0x406CCD: ??? (in /var/tmp/racket/bin/racket)
==18730== by 0x4071D8: ??? (in /var/tmp/racket/bin/racket)
==18730== by 0x4C4A53E: do_main_stack_setup (salloc.c:198)
==18730== by 0x4C4A5B1: scheme_main_stack_setup (salloc.c:310)
==18730== by 0x4070DD: ??? (in /var/tmp/racket/bin/racket)
==18730== by 0x4070A6: main (in /var/tmp/racket/bin/racket)
==18730== Address 0x8 is not stack'd, malloc'd or (recently) free'd
==18730==
SIGSEGV MAPERR si_code 1 fault on addr 0x8
if i modify place_instance_init() to call scheme_create_overflow()
after scheme_init_overflow() - things getting more worse.
==22609== Invalid read of size 8
==22609== at 0x501B9DB: block_cache_compact (block_cache.c:325)
==22609== by 0x501D216: mmu_should_compact_page (vm.c:191)
==22609== by 0x5027F94: do_heap_compact (newgc.c:4112)
==22609== by 0x5029BBA: garbage_collect (newgc.c:4912)
==22609== by 0x501DFDF: collect_now (newgc.c:985)
==22609== by 0x501ED08: allocate_slowpath (newgc.c:1375)
==22609== by 0x501EE82: allocate (newgc.c:1439)
==22609== by 0x501F2AF: GC_malloc_atomic (newgc.c:1557)
==22609== by 0x4F62F1D: scheme_copy_stack (setjmpup.c:298)
==22609== by 0x4F6364A: scheme_setjmpup_relative (setjmpup.c:556)
==22609== by 0x4CB3781: scheme_handle_stack_overflow (eval.c:447)
==22609== by 0x4FD0A09: scheme_thread_block (thread.c:4969)
==22609== by 0x4CE2775: scheme_really_create_overflow (fun.c:1087)
==22609== by 0x4CE2A7D: scheme_create_overflow (fun.c:1147)
==22609== by 0x4C94360: place_instance_init (env.c:534)
==22609== by 0x4C938A6: scheme_engine_instance_init (env.c:305)
==22609== by 0x4C93714: scheme_basic_env (env.c:226)
==22609== by 0x406CCD: ??? (in /var/tmp/racket/bin/racket)
==22609== by 0x4071D8: ??? (in /var/tmp/racket/bin/racket)
==22609== by 0x4C4A53E: do_main_stack_setup (salloc.c:198)
==22609== by 0x4C4A5B1: scheme_main_stack_setup (salloc.c:310)
==22609== by 0x4070DD: ??? (in /var/tmp/racket/bin/racket)
==22609== by 0x4070A6: main (in /var/tmp/racket/bin/racket)
==22609== Address 0x5ac2290 is 8 bytes after a block of size 104 alloc'd
==22609== at 0x4A069EE: malloc (vg_replace_malloc.c:270)
==22609== by 0x501ABA2: ofm_malloc (newgc.c:335)
==22609== by 0x501ABD5: ofm_malloc_zero (newgc.c:342)
==22609== by 0x501B312: block_cache_create (block_cache.c:65)
==22609== by 0x501D038: mmu_create (vm.c:101)
==22609== by 0x5025423: NewGC_initialize (newgc.c:2942)
==22609== by 0x5025533: init_type_tags_worker (newgc.c:2976)
==22609== by 0x5025831: GC_construct_child_gc (newgc.c:3026)
==22609== by 0x5025AF2: GC_switch_out_master_gc (newgc.c:3092)
==22609== by 0x4C9388B: scheme_engine_instance_init (env.c:297)
==22609== by 0x4C93714: scheme_basic_env (env.c:226)
==22609== by 0x406CCD: ??? (in /var/tmp/racket/bin/racket)
==22609== by 0x4071D8: ??? (in /var/tmp/racket/bin/racket)
==22609== by 0x4C4A53E: do_main_stack_setup (salloc.c:198)
==22609== by 0x4C4A5B1: scheme_main_stack_setup (salloc.c:310)
==22609== by 0x4070DD: ??? (in /var/tmp/racket/bin/racket)
==22609== by 0x4070A6: main (in /var/tmp/racket/bin/racket)
and after that racket eats cpu and memory till killed by OOM killer.
looking at strace - all that it is do - writing (and reading) all
alphabet characters one by one to pipe.
any ideas?
Отправлено моей секретаршей из моего Bentley с моего Vertu
--
____________________
http://lists.racket-lang.org/users

____________________
Racket Users list:
http://lists.ra

Matthew Flatt

2015-03-13 17:32:26 UTC

Permalink

On Fri, 27 Feb 2015 08:00:34 -0700

Post by Matthew Flatt
That's as far as I've ever gotten with memcheck. Racket manipulates the
C stack in ways that are far outside of what is supposed to be allowed,
and I think it confuses Valgrind. I don't know if there's a way to tell
Valgrind to allow this behavior and/or to give up on checking
operations related to the stack, but I didn't find one in the little
time I spent looking before.

this is "--vex-iropt-register-updates=allregs-at-each-insn" for.
and i'm talking here about bug in racket. scheme_handle_stack_overflow()
called before scheme_overflow_jmp is initialised.

Ah, I finally see what you mean, and I've had it backwards: Valgrind is
confusing Racket about the stack, not the other way around.

Thanks!

I was able to make Racket run in Valgrind on Linux with the following
changes:

* In "eval.c", disable

# ifdef LINUX_FIND_STACK_BASE
bnd = adjust_stack_base(bnd);
# endif

That's where Valgrind confuses Racket, because it (understandably)
puts the stack in a different location than the executable state
says.

* In "newgc.c", disable generational GC by changing the
initialization

newgc->generations_available = 1;

to 0. Write barriers implemented by mprotect() and signal handlers
don't interact well with Valgrind; I'm not sure exactly why, but
it's not surprising.

* Initialize some `epoll_event` structures in "thread.c" with

memset(&ev, 0, sizeof(ev))

in obvious places. I don't think the lack of initialization reflects
a bug; I think Valgrind just has to be conservative about memory
sent to a syscall. It's a good idea to initialize, anyway.

* Disable the use of libunwind by undefining MZ_USE_DWARF_LIBUNWIND in
"jitstack.c". I'm not entirely certain, but I think that memcheck
doesn't know that program headers should count as initialized.

With those changes, memcheck effectively detects that

mmu_should_compact_page(gc->mmu, work->mmu_src_block)

in "newgc.c" is missing an ampersand before the second argument. The
mistake won't cause any crashes, but it could reduce performance.

I think there's probably more to get out of memcheck, but I'm pausing
here to revisit on another day.

____________________
Racket Users list:
http://lists.racket-lang.org/users

Sergey Pinaev

2015-02-27 10:54:36 UTC

Permalink