Craig, you're right, there is a chance of "func" being used uninitialized, the function called does not set it in all cases. The duktape modules are joined into the duktape.c file, the separate sources are only kept for reference -- same as with mongoose. My toolchain is gcc version 5.2.0 (crosstool-NG crosstool-ng-1.22.0-98-g4638c4f) for the SPIRAM fix. Regarding my latest changes, you seem to build without SSL support, and I forgot some #ifdefs, will add them now. Regards, Michael Am 02.01.20 um 08:22 schrieb Craig Leres:
On 2019-12-29 05:32, Michael Balzer wrote:
yes, that looks like a compiler bug. It doesn't show with crosstool-ng-1.22.0-98-g4638c4f, so it seems that version does include some gcc fixes.
Actually I don't think it's necessarily a compiler bug. Looking more closely I see that it isn't directly assigned between when it's declared and the error line. Examining the code shows "func" is probably being updated as a side effect of this call:
if (DUK_LIKELY(duk__resolve_target_fastpath_check(thr, idx_func, &func, call_flags) != 0U)) {
The error goes away if func is initialized to NULL when it is declared (confusingly in components/duktape/src/duktape.c, not components/duktape/src-input/duk_js_call.c or components/duktape/src-separate/duk_js_call.c).
What toolchain version are you using? I have:
ice 1238 % xtensa-esp32-elf-c++ --version xtensa-esp32-elf-c++ (crosstool-NG crosstool-ng-1.22.0-80-g6c4433a5) 5.2.0
Which is what is specified if I following the links:
https://github.com/openvehicles/esp-idf https://docs.espressif.com/projects/esp-idf/en/stable/get-started/
https://docs.espressif.com/projects/esp-idf/en/stable/get-started/linux-setu...
Toolchain Setup
for 64-bit Linux:
https://dl.espressif.com/dl/xtensa-esp32-elf-linux64-1.22.0-80-g6c4433a-5.2....
Of course my version is built natively for FreeBSD.
I'll make a pull request for this. Meanwhile I updated again and changes committed today:
commit b1789e8792197826b1cec71ad0178b879cc2d709 Author: Michael Balzer <balzer@expeedo.de> Date: Wed Jan 1 19:08:03 2020 +0100
Webserver: extend /api/execute & loadcmd() by Javascript mode
breaks the compile for me, see appended. I'm currently on 9de393f4.
Craig
ice 439 % gmake Toolchain path: /home/ice/u0/leres/bin/xtensa-esp32-elf-gcc Toolchain version: crosstool-ng-1.22.0-80-g6c4433a5 Compiler version: 5.2.0 Python requirements from /home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/requirements.txt are satisfied.
App "ovms3" version: 3.2.008-54-g9de393f4-dirty CXX /home/ice/u0/leres/src/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build/ovms_script/src/ovms_script.o /home/ice/u0/leres/src/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/ovms_script/src/ovms_script.cpp: In member function 'bool DuktapeHTTPRequest::StartRequest(duk_context*)': /home/ice/u0/leres/src/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/ovms_script/src/ovms_script.cpp:1128:10: error: 'struct mg_connect_opts' has no member named 'ssl_ca_cert' opts.ssl_ca_cert = "*"; ^ /home/ice/u0/leres/src/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/ovms_script/src/ovms_script.cpp: In member function 'void DuktapeHTTPRequest::MongooseCallback(mg_connection*, int, void*)': /home/ice/u0/leres/src/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/ovms_script/src/ovms_script.cpp:1188:20: error: 'MG_SSL_ERROR' was not declared in this scope if (err == MG_SSL_ERROR) ^ gmake[1]: *** [/home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/make/component_wrapper.mk:290: src/ovms_script.o] Error 1 gmake: *** [/home/ice/u0/leres/esp/esp-idf/make/project.mk:552: component-ovms_script-build] Error 2
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26