[Ovmsdev] v3 hardware disconnecting from v2 server

[Tom Parker]

On 29/01/18 13:07, Mark Webb-Johnson wrote:
> The bigger issue is the PPP level, and I’m not sure how to reliably detect issues there. Also not sure if the issue you are seeing is at the TCP server connection level, or low level PPP transport. Do you know if you restart the v2 server module, but leave the simcom connection as it is, does that resolve it?

Stopping the v2 server causes a panic even when it has connected right 
after boot. The below stack trace is from current master. Looking at the 
code where it panics, it seems like the MetricCallbackList is corrupted 
somehow.

I commented out the MyMetrics.RegisterListener call in 
ovms_server_v2.cpp and got basically the same crash in 
OvmsEvents::DeregisterEvent so something strange is going on. I read the 
documentation for std::list and it looks like it's doing the right 
thing. Hmm... could the ec->m_caller == caller explode if the caller 
passed to RegisterEvent has been freed? My naive understanding of C++ 
would suggest no, because a pointer to invalid memory does not equal a 
pointer to valid memory, but I wouldn't be surprised if == does 
something other than pointer comparison sometimes. The caller is only 
accessed during deregister, so things would operate normally until you 
try to deregister.

I suppose it would have been quicker to recompile with gdb enabled than 
to stare at the code, but that's for tomorrow.

I did notice what looks like a memory leak, EventCallbackEntry objects 
are new'ed and added to the list in RegisterEvent, but they're only 
removed from the list in OvmsEvents::DeregisterEvent(). I think they 
should be delete'ed too?

I (55374) ovms-server-v2: Send MP-0 W0,0,0,0,0,0,0,0,0
I (55374) ovms-server-v2: Send MP-0 F3.0.0/factory/main build (idf 
v3.1-dev-217-g5bf85d0) Jan 30 2018 10:07:33,,5,1,NL,2degrees
OVMS > server v2 stop
Stopping OVMS Server V2 connection (oscv2)
Guru Meditation Error: Core  1 panic'ed (LoadProhibited)
. Exception was unhandled.
Register dump:
PC      : 0x40121a5a  PS      : 0x00060330  A0      : 0x8014fb4f A1      
: 0x3ffd9ce0
0x40121a5a: OvmsMetrics::DeregisterListener(char const*) at 
/vagrant/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./ovms_metrics.cpp:327

A2      : 0x3ffb6d90  A3      : 0x3f41749c  A4      : 0x3ffdfa1d A5      
: 0x3ffdb89c
A6      : 0x3ffdb8ac  A7      : 0x3ffdb8ac  A8      : 0x00000000 A9      
: 0x3ffd9cc0
A10     : 0x3ffdd244  A11     : 0x3ffdb904  A12     : 0x3ffd9cf0 A13     
: 0x3ffae8d8
A14     : 0x00000000  A15     : 0x00000000  SAR     : 0x00000018 
EXCCAUSE: 0x0000001c
EXCVADDR: 0x00000004  LBEG    : 0x400014fd  LEND    : 0x4000150d LCOUNT  
: 0xfffffff5

Backtrace: 0x40121a5a:0x3ffd9ce0 0x4014fb4c:0x3ffd9d00 
0x4014fbee:0x3ffd9d40 0x4014f117:0x3ffd9d60 0x4012ad9e:0x3ffd9d80 
0x4012ae91:0x3ffd9db0 0x4012ae83:0x3ffd9de0 0x4012ae83:0x3ffd9e10 
0x4012aeb9:0x3ffd9e40 0x401228b8:0x3ffd9e60 0x4012dbfd:0x3ffd9e80 
0x4012dc64:0x3ffd9ee0 0x4012292f:0x3ffd9f20 0x40122946:0x3ffd9f40 
0x40122e89:0x3ffd9f60 0x40125811:0x3ffd9f90 0x40125a09:0x3ffd9fc0 
0x40122d2d:0x3ffd9fe0 0x40122d3c:0x3ffda000 0x40125481:0x3ffda020
0x40121a5a: OvmsMetrics::DeregisterListener(char const*) at 
/vagrant/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./ovms_metrics.cpp:327
0x4014fb4c: OvmsServerV2::~OvmsServerV2() at 
/vagrant/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/ovms_server_v2/src/ovms_server_v2.cpp:1616
0x4014fbee: OvmsServerV2::~OvmsServerV2() at 
/vagrant/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/ovms_server_v2/src/ovms_server_v2.cpp:1625
0x4014f117: ovmsv2_stop(int, OvmsWriter*, OvmsCommand*, int, char const* 
const*) at 
/vagrant/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/ovms_server_v2/src/ovms_server_v2.cpp:1659 
(discriminator 1)
0x4012ad9e: OvmsCommand::Execute(int, OvmsWriter*, int, char const* 
const*) at 
/vagrant/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./ovms_command.cpp:83