[Ovmsdev] version 3.2.007: Crash on boot
dexter at expeedo.de
Thu Dec 12 02:29:19 HKT 2019
good example why not to use addr2line: I think that result is wrong. a2l uses gdb which gives:
balzer at leela:~/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3> a2l tmp/3.2.007.ovms3.elf 0x400d5e4c:0x3ffc5c40 0x7ffffffd:0x3ffc5c90
Using elf file: tmp/3.2.007.ovms3.elf
0x400d5e4c is in CAN_rxtask(void*) (/home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/can/src/can.cpp:730).
726 } while (loop);
729 case CAN_txcallback:
730 msg.body.bus->TxCallback(&msg.body.frame, true);
732 case CAN_txfailedcallback:
733 msg.body.bus->TxCallback(&msg.body.frame, false);
…and that actually makes sense and matches the register dump.
If I read the gdb disassembly correctly, A10 = msg.body.bus, so Greg's got a CAN_txcallback msg without a bus.
Hardening the rxtask against null here would probably avoid the crash, but I don't see yet how that could be possible.
Both esp32can and mcp2515 set the bus field to their object addresses, which cannot be null.
Am 11.12.19 um 13:45 schrieb Mark Webb-Johnson:
> Can’t get a2l working at the moment. The addr2line gives:
> addr2line -e 3.2.007.ovms3.elf 0x400d5e4c:0x3ffc5c40 0x7ffffffd:0x3ffc5c90
> That is:
> void canbus::LogInfo(CAN_log_type_t type, const char* text)
> MyCan.LogInfo(this, type, text); <—— HERE
> ELF is at:
> Regards, Mark.
>> On 11 Dec 2019, at 5:20 PM, Michael Balzer <dexter at expeedo.de <mailto:dexter at expeedo.de>> wrote:
>> Greg uses your build, the crash point seems to be consistent, can you post the a2l on this?
>> PS: Greg, would you mind switching to EAP to beta test future releases?
>> Am 11.12.19 um 04:33 schrieb Greg D.:
>>> Hi folks,
>>> Well, the module updated to 3.2.007 last night. I just checked on it,
>>> and it appears that it didn't exactly survive. Crashed while running
>>> the autoconfig script. Log with two cycles attached.
>>> I tried renaming the /store/events directory to /store/was_events since
>>> it seems like Duktape was getting in the way, but that didn't resolve
>>> the crash. I manually enabled wifi so I could manage the module, and
>>> moved it back to 3.2.005 from the other partition. Seems stable again.
>>> The car is going into the Service Center tomorrow (the perennial issue
>>> with 1146 alerts), so I need to have the module stable so that I can
>>> keep an eye on it. Going to leave it on 3.2.005 for now, unless someone
>>> has a quick fix in the next few hours...
>>> Otherwise, any ideas for troubleshooting after I get the car back back
>>> (hopefully end of day)?
>>> OvmsDev mailing list
>>> OvmsDev at lists.openvehicles.com
>> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
>> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>> OvmsDev mailing list
>> OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OvmsDev