[Ovmsdev] V3 progress
Stephen Casner
casner at acm.org
Thu Oct 12 03:01:32 HKT 2017
I see now why we had not already seen this crash that Tom hit. In the
ovms_script code, the printf() function properly mallocs a buffer, but
puts() and write() do not. So the scripts that have been running
without crashing so far must have invoked routines that only did
printf() or ESP_LOG (which goes to console_logger() that also does
malloc). So, if the OVMS Server V2 code had done printf() rather than
puts() the crash would not have happened. Tom's change to ESP_LOG
is also a valid fix, but could be changed to printf() if the prefix
applied by ESP_LOG is not desired.
As proposed, I will change the script code to use BufferedShell and
also change how console_logger() is done so I can remove the
problematic OvmsConsole::Log() function. Then puts() will work again,
too.
-- Steve
On Wed, 11 Oct 2017, Stephen Casner wrote:
> On Wed, 11 Oct 2017, Mark Webb-Johnson wrote:
>
> > I think this double-free may be related to the new event script
> > system Steve and I have been working on (in preparation for SMS,
> > etc).
> >
> > @steve: That seems to be on 'free(event.buffer)' at
> > ovms_console.cpp:215. One of those nasty 'passing around pointers,
> > and who is responsible for freeing' issues, I guess. Can you try to
> > reproduce the fault?
>
> The OvmsConsole::Log(char* message) function expects to be called with
> a message allocated from the heap (usually by vasprintf()). It was
> originally implemented to be called only from OvmsCommandApp::Log() as
> it iterated over all the registered consoles and gave each a separate
> copy of the message. Thus it was not valid for the script code to
> call MyUsbConsole->Log() directly. I had not recognized this before.
>
> I need to go to bed now, but will study this more tomorrow. This
> OvmsConsole::Log(char* message) function isn't used for the logging of
> messages on consoles anymore since I created the LogBuffers class and
> added OvmsConsole::Log(LogBuffers* message) to handle the console
> logging more efficiently. The solution may be to remove the problem
> Log() function completely and proceed with revising your script code
> to use the new BufferedShell mechanism, presuming that you are OK with
> it.
>
> -- Steve
>
> >
> > Thanks, Mark.
> >
> > > On 11 Oct 2017, at 1:52 PM, Tom Parker <tom at carrott.org> wrote:
> > >
> > > On 11/10/17 13:02, Mark Webb-Johnson wrote:
> > >> Tom,
> > >>
> > >> I think your problem is sdkconfig. That has settings for partition table, fat filesystem, and timer task stack size; all three of your issues.
> > >>
> > >> Can you try to diff your sdkconfig against sdkconfig.default (which contains all the custom settings)? Or just copy sdkconfig.default over your sdkconfig, and then adjust appropriately for what you need custom? You'll need to 'make menuconfig' to confirm things, then I suggest 'make clean' and 'make flash' to flash everything (partition table, bootloader, etc).
> > >
> > > That worked! My sdkconfig was quite far from the default.
> > >
> > > Your untested scripts recommendation didn't work as they need to be stored in the events directory, this works:
> > >
> > > vfs mkdir /store/events
> > > vfs mkdir /store/events/system.start
> > > vfs append "wifi mode client <ssid>" /store/events/system.start/startmeup
> > > vfs append "vehicle module NL" /store/events/system.start/startmeup
> > > vfs mkdir /store/events/network.up
> > > vfs append "server v2 start" /store/events/network.up/startmeup
> > >
> > >
> > > With these in place I get a reboot loop:
> > >
> > > I (5822) event: ip: 192.168.43.92, mask: 255.255.255.0, gw: 192.168.43.1
> > > I (5822) ovms-mdns: Launching MDNS service
> > > I (5832) script: Running script /store/events/network.up/startmeup
> > > Launching OVMS Server V2 connection (oscv2)/home/ubuntu/esp/esp-idf/components/freertos/./heap_regions.c:368 (vPortFreeTagged)- assert failed!
> > > abort() was called at PC 0x40085f8f on core 1
> > > 0x40085f8f: vPortFreeTagged at /home/ubuntu/esp/esp-idf/components/freertos/./heap_regions.c:410
> > >
> > > Backtrace: 0x40088680:0x3ffebe80 0x4008877f:0x3ffebea0 0x40085f8f:0x3ffebec0 0x40088cd1:0x3ffebee0 0x40081f89:0x3ffebf00 0x4000bec7:0x3ffebf20 0x400eff2a:0x3ffebf40 0x400eff54:0x3ffebf70 0x400efcc0:0x3ffebf90
> > > 0x40088680: invoke_abort at /home/ubuntu/esp/esp-idf/components/esp32/./panic.c:519
> > > 0x4008877f: abort at /home/ubuntu/esp/esp-idf/components/esp32/./panic.c:519
> > > 0x40085f8f: vPortFreeTagged at /home/ubuntu/esp/esp-idf/components/freertos/./heap_regions.c:410
> > > 0x40088cd1: vPortFree at /home/ubuntu/esp/esp-idf/components/esp32/./heap_alloc_caps.c:323
> > > 0x40081f89: _free_r at /home/ubuntu/esp/esp-idf/components/newlib/./syscalls.c:32
> > > 0x400eff2a: _ZN11OvmsConsole7ServiceEv at /vagrant/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./ovms_console.cpp:215
> > > 0x400eff54: _ZThn296_N11OvmsConsole7ServiceEv at ??:?
> > > 0x400efcc0: _ZN8TaskBase4TaskEPv at /vagrant/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./task_base.cpp:119
> > >
> > > Rebooting...
> > >
> > > If I remove the network.up/startmeup file (the file that starts the v2 server client) then it starts up ok and when I start the v2 client manually, it connects to the v2 server and everything works. I tried using the ticker.60 event and got the same crash so it's not a race condition with the wifi startup.
> > >
> > > The cause is a double free by the looks of it, and if I comment out the writer->puts called in the v2 server start function, things work:
> > >
> > > diff --git a/vehicle/OVMS.V3/components/ovms_server_v2/src/ovms_server_v2.cpp b/vehicle/OVMS.V3/components/ovms_server_v2/src/ovms_server_v2.cpp
> > > index 106269e..d1ee797 100644
> > > --- a/vehicle/OVMS.V3/components/ovms_server_v2/src/ovms_server_v2.cpp
> > > +++ b/vehicle/OVMS.V3/components/ovms_server_v2/src/ovms_server_v2.cpp
> > > @@ -515,7 +515,7 @@ void ovmsv2_start(int verbosity, OvmsWriter* writer, OvmsCommand* cmd, int argc,
> > > {
> > > if (MyOvmsServerV2 == NULL)
> > > {
> > > - writer->puts("Launching OVMS Server V2 connection (oscv2)");
> > > + // writer->puts("Launching OVMS Server V2 connection (oscv2)");
> > > MyOvmsServerV2 = new OvmsServerV2("oscv2");
> > > }
> > > }
> > >
> > >
> > > The ESP_LOGI in OvmsServerV2::OvmsServerV2 also gets called, in this code path but doesn't need to be commented out.
> > >
> > > Progress!
> > > _______________________________________________
> > > OvmsDev mailing list
> > > OvmsDev at lists.teslaclub.hk
> > > http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
> >
> > _______________________________________________
> > OvmsDev mailing list
> > OvmsDev at lists.teslaclub.hk
> > http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
> >
> >
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
More information about the OvmsDev
mailing list