[racket] runiing racket 6.1.1 under valgrind

At Mon, 2 Mar 2015 09:25:40 +0300, Sergey Pinaev wrote:
> On Fri, 27 Feb 2015 08:00:34 -0700
> Matthew Flatt <mflatt at cs.utah.edu> wrote:
> 
> > 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.