std::string error

[mzimmers]

@kshegunov The app is already built in debug. The reason the trace is so human-unfriendly is that I can't run monitor (a big part of my testing is connecting/disconnecting line power to the device, which entails removal of the USB cable that the monitor would run on), so I'm just logging what I can to the 2nd UART on the device. But, I've used xtensa-esp32-elf-addr2line to determine the line of source code, and it's definitely at the creation/assignment of the string in the message object.

[kshegunov]

Do you at least have logging?
I'd love to see the output of something along those lines (or equivalent):

std::cerr << uintptr_t(m_params);
std::cerr << uintptr_t(m_params->nvs);
char * p  = m_params->nvs->getIpAddr(IP_ADDRESS)
std::cerr << uintptr_t(p);

[mzimmers]

Yes, I can get those. I'll do it first thing Wednesday when I return to the office.

[mzimmers]

Well...this is kind of embarrassing (and a little odd, too). I put in the telltales that kshegunov suggested, and...m_params had a value of 0. That's the embarrassing part, that I didn't check that myself.

Here's the odd part: the reason the value was 0 was because when I created the Message object, I passed the incorrect object type to the c'tor. A Message object is supposed to be created like this:

Message::Message(Tasks *params)
{
    m_params = params;
}

But I was creating it like this:

MsgType Worker::processMsg(Message &msg)
{
    MsgType mt = msg.getType();
    switch (mt)
    {
    ...
    case MSG_SILENCE_BUZZER:
        msgOut = new Message(msg);
        msgOut->buildSilenceAck();
        break;
...

Sheer sloppiness on my part, but...why didn't the compiler yell at me?

Anyway, thanks to everyone who looked at this.

[kshegunov]

@mzimmers said in std::string error:

Sheer sloppiness on my part, but...why didn't the compiler yell at me?

C++ (and naturally C) is notorious for its implicit conversions and many compilers happily give you just enough rope to hang yourself; A reference is almost the same as a pointer to some object, same for an integer and by extension an enum. My advice is to (almost) always declare the constructor explicit so you don't get into that kind of trouble.
E.g.:

class Message
{
public
    explicit Message(Tasks *);
};

[mzimmers]

@kshegunov that's good advice, but this was more than just a reference/pointer mismatch: they were referring to/pointing to 2 different object types. I'd expect C++ to have been stricter about that...

[kshegunov]

they were referring to/pointing to 2 different object types. I'd expect C++ to have been stricter about that...

It'd depend on the compiler really, but from the machine's point of view it's all the same. Everything is/is converted to an address to some region in memory. Type-safety is something people invented to have at least some idea about what we are working with, and I agree, the compiler should've warned you at least. But, well, as I said almost everything decays to void * and from there the step into the abyss is just tiny ... ;)