CRiSP Weblog

Spent days trying to debug and understand dtrace with this line:

inline struct psinfo_t  *curpsinfo = ((struct ps_info_t *) `curproc);          

I was following the type casting and type comparing code.

Eventually I spotted a stray underscore.

Can you spot it?

#include #include #include #include

int main(int argc, char **argv) { int fd; Elf *elf; int err;

elf_version(EV_CURRENT); fd = open(argv[1], O_RDONLY); elf = elf_begin(fd, ELF_C_READ, NULL); err = elf_cntl(elf, ELF_C_FDREAD);

printf("elf=%p err=%d\n", elf, err); }

Interestingly, the elf_cntl tries to do a malloc(-1) but fails. Seems to be a buggy libelf.a on Ubuntu 10.04 - it forgets to fstat() the original file and ends up thinking the size of the file is ~0.

Annoying, valgrind catches this (complains of a silly malloc(-1)), but doesnt tell you where this happens, despite it being ever so important.

I spent much of the week chasing an issue in why the usdt/c example wouldnt compile or build. I hadnt really changed anything in this area, yet an invalid simple.o was being created (invalid in an ELF sense).

I tracked down a partial reason to be that in calling libelf.a, the enum's we pick up from the elf.h header file(s) didnt agree with what libelf.a was expecting. (Very weird - looks like the Solaris elf header and Linux header dont agree).

What I dont understand is why this suddenly hit. I am thinking one of my Ubuntu updates caused a discrepancy to the header and libraries, and I have been chasing my tail.

Early on in dtrace/linux evolution, I did a bunch of work to dt_link.c to all USDT probes to work, and I was happy with my changes. Just now, I reverted all of them, and my USDT problems went away.

Something fishy is going on here - so I urge caution when I do the next distro. It maybe my build environment is polluted/broken and that may cause differences between what I observe and what dtrace users see on their systems.