Kynan and I came along to the MySQL camp, and thru a quirk of fate pretty much ended up running it (the person who was meant to be running it got injured on the first day and had to go off to hospital). In return we wrote the Google Code blog post about the event. Pretty cool, huh?
Apparently this behaviour has bothered me in the past as well, and I didn't realize until I googled just now for an answer... I've never really thought to hard about this, but it turns out that bash's return code checking for pipelines is rather dumb. Specifically, bash checks the return code of the last command in the pipeline, not the entire pipeline. For example: mikal@mstill:~$ exit 1 | exit 2 mikal@mstill:~$ echo $? 2 We get the return code of the last process in the pipeline. Perhaps fair enough... Then again: mikal@mstill:~$ exit 1 | exit 0 mikal@mstill:~$ echo $? 0 Here we get the return code of the final process again, which masks the error in the first process from being reported. You can get the return codes of all processes in the pipe like this: mikal@mstill:~$ exit 1 | exit 2 mikal@mstill:~$ echo ${PIPESTATUS[@]} 1 2 And then if you assume that the sum of all return codes will report if an error occurred: mikal@mstill:~$ exit 1 | exit 0 mikal@mstill:~$ expr `echo ${PIPESTATUS[@]} | sed 's/ / + /g'` 1 Which is evil, but does what I want. Is there a less evil way of doing this?
So, your code leaks and you need a technique for finding what object you're leaking, so grab a couple of addresses at random and dump them. Chances are, they're the object your leaking. This technique is so sexy in it's beauty. [icbm: home]