Everyone, I can now reproduce the corrupted heap crashes on branch "master" as well, and would like to know if anyone else can reproduce these as well. To replicate, change the script component to launch the duktape task on core 0. Then start the below test script (from "Branch for-v3.3 network issues" thread). The heap corruption will occur within a few seconds. It will happen at different places, where a free() call is made. With duktape (and the script) running on core 1, no heap corruption occurs with branch "master". It's present with branch "for-v3.3" then only, and it needs much longer script runtime to occur. I have no idea yet how this can depend on the core we're running on. I'm open to suggestions what to try to narrow this down. I've disabled all auto start components and file logging, i.e. the module runs without a vehicle and without networking. Next would be to exclude components from the build. Regards, Michael Am 19.09.21 um 09:53 schrieb Michael Balzer:
The corrupt heap crashes might be something else, up to now I only saw them with the for-v3.3 branch. I'm currently trying to reproduce one of these on "master". Unfortunately gdb cannot handle them, the call stack also seems to be corrupted.
Here's a new version of the script that logs progress so you don't need to enable event logging:
// Setup: script eval 'testcnt=0; PubSub.subscribe("usr.testev", function(ev) { var ms=Number(ev.substr(11))||10; if (++testcnt % (3*1000/ms) == 0) print(ev + ": " + testcnt); OvmsEvents.Raise("usr.testev."+ms, ms); })'
// Start with 10 ms interval: script eval 'testcnt=0; OvmsEvents.Raise("usr.testev.10")'
// Check status: script eval 'print("testcnt: " + testcnt + "\n")'
// Stop: script eval 'PubSub.unsubscribe("usr.testev")'
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26