Hash of uninitialized bigarray

[yallop]

Running valgrind on a program that uses Lwt reveals a problem: values created by Lwt_bytes.create are stored in a weak hash table, and hashed en route, leading to reads of uninitialised memory, and diagnostics like this:

==26194== Conditional jump or move depends on uninitialised value(s)
==26194==    at 0x46825C: camlWeak__add_aux_1143 (weak.ml:193)
==26194==    by 0x41A404: camlLwt_io__make_1224 (lwt_io.ml:514)
==26194==    by 0x41E2D2: camlLwt_io__entry (lwt_io.ml:1289)
==26194==    by 0x405028: caml_program (in /tmp/lwt_bug/bug.native)
==26194==    by 0x48C15D: ??? (in /tmp/lwt_bug/bug.native)
==26194==  Uninitialised value was created by a heap allocation
==26194==    at 0x4C29C4F: malloc (vg_replace_malloc.c:299)
==26194==    by 0x47345A: caml_ba_alloc (in /tmp/lwt_bug/bug.native)
==26194==    by 0x473685: caml_ba_create (in /tmp/lwt_bug/bug.native)
==26194==    by 0x4208D7: camlBigarray__create_1100 (bigarray.ml:120)
==26194==    by 0x41E29A: camlLwt_io__entry (lwt_bytes.ml:32)
==26194==    by 0x405028: caml_program (in /tmp/lwt_bug/bug.native)
==26194==    by 0x48C15D: ??? (in /tmp/lwt_bug/bug.native)

[aantron]

Thanks. This wasn't causing any actual problems in programs using Lwt (see comment in patch), but removing the valgrind noise is worthwhile.

Do you, by chance, remember the command-line arguments you passed to ocaml(c|opt) and/or valgrind to get nice stack traces like that? I was compiling with -g, but got function names only for C frames from the runtime and external functions.

[yallop]

Thanks for the fix.

I don't have the test setup available now, but I'd expect passing -g through to both the OCaml compiler and the C compiler to be sufficient. I don't think valgrind needs any special flags here.