Problems when trying to update esp-idf and toolchain to version 8.2 (the latest) #263
Comments
|
Bold attempt. Hint: enable the gdb stub so you can inspect registers and parameters on the crash. |
|
I'm still developing this and I'm using OVMSV3 as a base. Now that ESP-IDF V4 has been released I'm trying to completely transition to it, but it's not as simple.
Solution:I made the map private inside of the class (actually, I removed the class entirely and moved everything inside OvmsCommand.
It's difficult to explain, so please follow me. In my code, I noticed that the first library that tries to register a new command is pcp.cpp, this line here m_root.RegisterCommand("help", "Ask for help", help, "", 0, 0, false);
m_root.RegisterCommand("exit", "End console session", cmd_exit, "", 0, 0, false);
OvmsCommand* cmd_log = MyCommandApp.RegisterCommand("log","LOG framework");
cmd_log->RegisterCommand("file", "Start logging to specified file", log_file, "[<vfspath>]\nDefault: config log[file.path]", 0, 1);
cmd_log->RegisterCommand("open", "Start file logging", log_open);
cmd_log->RegisterCommand("close", "Stop file logging", log_close);
cmd_log->RegisterCommand("status", "Show logging status", log_status);
cmd_log->RegisterCommand("expire", "Expire old log files", log_expire, "[<keepdays>]", 0, 1);
OvmsCommand* level_cmd = cmd_log->RegisterCommand("level", "Set logging level", NULL, "$C [<tag>]", 0, 0, false);
level_cmd->RegisterCommand("verbose", "Log at the VERBOSE level (5)", log_level , "[<tag>]", 0, 1);
level_cmd->RegisterCommand("debug", "Log at the DEBUG level (4)", log_level , "[<tag>]", 0, 1);
level_cmd->RegisterCommand("info", "Log at the INFO level (3)", log_level , "[<tag>]", 0, 1);
level_cmd->RegisterCommand("warn", "Log at the WARN level (2)", log_level , "[<tag>]", 0, 1, false);
level_cmd->RegisterCommand("error", "Log at the ERROR level (1)", log_level , "[<tag>]", 0, 1, false);
level_cmd->RegisterCommand("none", "No logging (0)", log_level , "[<tag>]", 0, 1, false);
monitor = cmd_log->RegisterCommand("monitor", "Monitor log on this console", log_monitor , "[$C]");
monitor_yes = monitor->RegisterCommand("yes", "Monitor log", log_monitor);
monitor->RegisterCommand("no", "Don't monitor log", log_monitor);
m_root.RegisterCommand("enable","Enter secure mode (enable access to all commands)", enable, "[<password>]", 0, 1, false);
m_root.RegisterCommand("disable","Leave secure mode (disable access to most commands)", disable);And those commands are registered during the creation of the constructor here. The problem:
When I saw this, I initially thought that the map or even m_root had something to do with it. But the program was compiling successfully and the code didn't seem wrong to me. So, I decided to trace things a little bit more and observe what was happening during the creation of those commands inside of m_root. I replaced the OvmsCommandApp::RegisterCommand(...) with the following code: OvmsCommand *OvmsCommandApp::RegisterCommand(const char *name, const char *title, void (*execute)(int, OvmsWriter *, OvmsCommand *, int, const char *const *),
const char *usage, int min, int max, bool secure)
{
OvmsCommand *test = m_root.RegisterCommand(name, title, execute, usage, min, max, secure);
printf("\n---START---\n");
int i = 0;
for (const auto &x : m_root.m_children)
{
// Just show me what's in the map
printf("%d) key is: %s \n- title: %s \n- name: %s\n", i, x.first.c_str(), x.second->m_title, x.second->m_name);
i++; // Nothing personal here :)
}
printf("\n---END---\n");
return test;
}and everything got clearer on the next run. What's happeningm_children is populated with all the commands, I can see them getting registered and appended one after the other. [...] previous console logs...
---START---
0) key is: boot
- title: BOOT framework
- name: boot
1) key is: event
- title: EVENT framework
- name: event
2) key is: metrics <--- Notice metrics. It's inside m_root already
- title: METRICS framework
- name: metrics
3) key is: notify
- title: NOTIFICATION framework
- name: notify
4) key is: power
- title: Power control
- name: power
---END---
I (947) command: Initialising COMMAND (1000) <--- Look at this here! The previous content seems to be gone.
---START---
0) key is: exit
- title: End console session
- name: exit
1) key is: help
- title: Ask for help
- name: help
2) key is: log
- title: LOG framework
- name: log
<---- where are metrics and the other commands?
---END---
I (969) config: Initialising CONFIG (1400)
---START---
0) key is: disable
- title: Leave secure mode (disable access to most commands)
- name: disable
1) key is: enable
- title: Enter secure mode (enable access to all commands)
- name: enable
2) key is: exit
- title: End console session
- name: exit
3) key is: help
- title: Ask for help
- name: help
4) key is: log
- title: LOG framework
- name: log
5) key is: store
- title: STORE framework
- name: store
---END---Thoughts and considerationsI have spent a lot of time looking for the reasons why the constructor gets called with such a delay. Why despite having registered OvmsCommandApp as global MyCommandApp is this happening? I mean: shouldn't the OvmsCommandApp constructor be called immediately when I ask to register a command? |
|
The OvmsCommand code has mostly not been written by me, but I think I can answer your questions.
The issue you're relating to has to do with virtual object destruction. If OvmsCommandMap was virtual and would need to be addressable using a std::map pointer, that would not be working. But it isn't, and it's never even accessed through a pointer. It's just a functional extension to std::map only used within OvmsCommand. So there's nothing wrong with that and it doesn't need a fix.
Init priorities are also logged in brackets from the constructors during the boot process: The OvmsCommandApp constructor must not be delayed by the compiler until the first use, it must obey the init priority as defined, as the boot process depends on the order. And of course there must be no calls to RegisterCommand() before the instantiation. So if you don't have this exact order in your boot log or see some entries having a second creation log entry, something is probably broken with your compiler or build setup. In a normal boot, the OvmsCommandApp constructor itself is the first to call RegisterCommand(), with the first command registered being "help": Regards, |
|
@dexterbg thank you so much for clarifying this. Regarding the last question, yes, I did notice that something was wrong with the I noticed that this rule seems to be ignored on esp-idf v4 as it is, or at least not with my current configuration. I think I'll try to get some more details about this to the esp-idf guys. It doesn't look like so, but many things have changed from V3 to V4, especially after they decided to move to CMake. Best regards, |
|
Thanks for taking this, Michael. I am the author of code deriving from std::map, but the first comment from Fabrizio today was not forwarded to me by email as is usually the case, so I didn't know about it until I saw the email resulting from Michael's reply. I did get an email for Fabrizio's second comment today. |
|
I can confirm this will now be fixed by the next commit of esp-idf as reported here. |
|
Hello Fabrizio, Are you still actively working on this? How far are you now? Thanks, |
|
Hi @eddyv19 I don't feel like I'm actively working on this since I am busy with my academic studies in this field. |
|
Hi, yeah i am interested. Is the work that you have done so far accessible somewhere? How far did you get? Is it compiling with the updated libraries and tools. |
|
Hi, despite being OVMS codebase Open Source, the code I've been working on is not accessible. It's been developed as a private repo for a custom project which unfortunately I can not share. I'm sorry about that. I want to clarify that my version of the code is not currently supporting any of the OVMS components. They have been disabled permanently (we don't need them). When I started this, I was as new as you to the OVMS codebase, and I have to say that if you want to develop a new project based on this, you will probably have to work quite hard to get this working on esp-idf 4.x. It might not be worth it depending on your requirements. |
|
Fabrizio: Do you have anything you can share with us? Eddy: I want to see this happen. I've been working on building the esp-2020r1 toolchain on FreeBSD (a lot of weekends effort over the last month) and am very close to finishing this part. |
|
The original poster has indicated he will not be able to contribute his changes back to the project. That is disappointing, but understandable. I have raised a new GitHub issue for further discussions regarding this: Moving OVMS to latest ESP-IDF framework #360 |
Hi everyone, I'm fairly new to esp-idf as well as c++. I'm trying to use the Open Source OVMS3 as a base for a personal project. I'm sorry if I came here to ask about this, I hope that some good developer can enlighten me.
The problem: the current version of esp-idf is quite old
I've noticed that you are using an old version of both the toolchain and the compiler (v 5.2 if I remember correctly), and that's why I've spent quite some time trying to implement all the changes that you have made to the stock esp-idf components to make it work with this version.
What I'm trying to achieve:
I want to get OVMS to work with the most updated version of esp-idf, respectively with:
The code compiles, but panics on boot
Unfortunately, I got stuck and now I can't really understand why when I flash my ESP32 with the updated code I get this segmentation fault:
Now, please notice that due to the changes I've made to OVMS the lines are no longer matching those of the original OVMS. However, from what I see, there is a problem when the software loads MDNS.
After some tracing, the problematic line seems to be this:
Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/ovms_events.cpp
Line 218 in d16a731
The text was updated successfully, but these errors were encountered: