Skip to content

Uninitialized value use in Linker.c

I'm using the test linker_unload but I think this also happens in GHCi when loading .o files.

Valgrind output:

==3607== Conditional jump or move depends on uninitialised value(s)
==3607==    at 0x2E9BC4F: setOcInitialStatus (Linker.c:1307)
==3607==    by 0x2E9BD60: mkOc (Linker.c:1349)
==3607==    by 0x2E9C04F: preloadObjectFile (Linker.c:1506)
==3607==    by 0x2E9C107: loadObj_ (Linker.c:1540)
==3607==    by 0x2E9C182: loadObj (Linker.c:1559)
==3607==    by 0x23F51A5: ??? (in /home/omer/haskell/ghci_valgrind/linker_unload)

Basically we allocate a new ObjectCode in mkOc and pass it to setOcInitialStatus without initializing the status field. setOcInitialStatus then reads the field:

static void setOcInitialStatus(ObjectCode* oc) {
    if (oc->status == OBJECT_DONT_RESOLVE) // <--- reads uninitialized field
      return;

    if (oc->archiveMemberName == NULL) {
        oc->status = OBJECT_NEEDED;
    } else {
        oc->status = OBJECT_LOADED;
    }
}

setOcInitialStatus has two call sites, the other one being loadOc. Valgrind doesn't catch any errors in that call site, but even there it's really hard to see when/how/where the field is initialized.

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information