The following info will give you all the info you need
Well no, actually it isn't. As I said several times before
The romlog is much more useful with the core/main.bin (or core/main.dump) from the build that was running at the time of the crash. If you built it yourself, just posting the core/main.bin from that build will work. Otherwise, I can make you a build for testing from the chdk or chdkde source tree, but I need to know how the build you are currently using is configured.
Without that, your romlogs are pretty much useless. Of course, it is possible that even with this nothing useful be learned from the romlog. Don't know until we try.
Knowing what build you are using could also suggest other debugging options.
You now know all of the details. There are no more details be be had. Now can we finally move on to fixing it?
What do you mean "we" ?
You are welcome "move on to fixing it" any time.
If you want
me to fix it you need to understand that I do this in my spare time. I'm trying to
help you, but I won't necessarily be able to debug your problem. Debugging remotely is difficult in the best of times.
There are many things that you could do to narrow down the possible causes of the problem:
- try fudgeys suggestion
- try find any pattern in when the error occurs (how many shots/download cycles). Knowing whether it shows up completely randomly, or whether it gets increasingly common over time might be a clue.
- try running the same cycle, but not actually shooting. E.g. if you do .print('shoot') instead of shoot, does it still crash eventually ? You should be able to run this much faster than actual shooting. You can't do the delete, but you could still have the download and mode switch.
- monitor available memory on the camera with get_meminfo between shots
- hack some debug logging into the CHDK C code (in the ptp and script execution path). You can write to the camera console log, which will be captured when the crash occurs.