I tried to create corrupted DNG files by taking pictures manually around 1 sec exposure, with the "g1x-101a-1.3.0-3100-full" auto build from the download site and also with the custom build "g1x-101a-1.3.0-r3038" which I was running the TLapse script with and had the problems, but I couldn't reproduce it. It all seems fine.
Did you try it in continuous mode (standard and custom CHDK build) taking multiple pictures while saving DNG's? Try saving 5 or 10 dng files at exposures >1 second and see if any are corrupted.
I didn't look at your dng files with the time lapse program, but were all the corrupted ones exposed >1 second? Can you still see a picture in the dng, but just with weird colors and contrast? Were there any lines in the dng pictures?
Looks to me like the shot_histogram calculation and shot_histogram_delay are preventing CHDK from saving the DNG file before the firmware starts the process of conversion to JPEG.
That could be it, but there seems to be something different in the 101a build with exposures over 1 second in continuous mode. The shot meters aren't garbage, like a wrong raw buffer address. All 4 meters just get brighter, but their relative brightness rank to each other stays the same, like they're still reading the same picture. There are 4 meters, each measuring a different area of the picture. The brightness difference for <1 second shots and >1 second seems to be constant for an individual meter. Meter readings are in ev96. They all get brighter, but not by adding a constant ev96 value. It's looks more like the ev96 meter values are MULTIPLIED by a constant.
My guess at this point is that the 101a Canon firmware turns up the gain of the sensor by about 2 ev for exposures over 1 second in continuous mode. This would make continuous faster in low light, at the expense of higher noise. But with the G1X, they'd just be turning a 14 bit sensor into a 12 bit sensor as far as noise is concerned. The effect on the raw pixels would be non-linear, which would mess up the dng files. Canon would have to compensate for it when it produced its native raw files or jpg.
A test of this theory would be to set the exposure manually to 2 seconds, and take pictures in continuous mode (without DNG saving). It should take a shot about every 2.25 seconds. My theory predicts the rate will be faster, i.e. around 1.25 shots per second. This would be a pretty cool feature, especially if I can figure out how to compensate for it in the meter readings.
My time lapse script also works in single shot mode, with about a .75 seconds between shots instead of .25 in continuous mode. Will you try a running the script in single shot? See if you can get it to flutter in continuous, and then try it in single shot to see if the fluttering goes away.