Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Get Qt Extensions
  • Unsolved
Collapse
Brand Logo
  1. Home
  2. Special Interest Groups
  3. C++ Gurus
  4. std::string error
Forum Updated to NodeBB v4.3 + New Features

std::string error

Scheduled Pinned Locked Moved Solved C++ Gurus
27 Posts 4 Posters 6.2k Views 2 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • hskoglundH hskoglund

    Hmm maybe some of the pointers when calling are bad, if you log them, say something like:

    void Message::buildSilenceAck()
    {
        string s;
    
        s.clear();
        ESP_LOGI(TAG, "params = %d",(int) m_params);
        ESP_LOGI(TAG, "m_params->nvs = %d",(int) m_params->nvs);
        s.append(m_params->nvs->getIpAddr(IP_ADDRESS));
    
    mzimmersM Offline
    mzimmersM Offline
    mzimmers
    wrote on last edited by
    #18

    @hskoglund I've done that. The pointers seem fine, and the getIpAddr() routine executes successfully.

    Weird problem, I know.

    1 Reply Last reply
    0
    • mzimmersM mzimmers

      I can't output the result -- the error occurs as I'm trying to execute that line.

      The error is known in the ESP32 world as a "Guru Meditation Error," and about all I get with my current debugging resources is this:

      Guru Meditation Error: Core  0 panic'ed (LoadProhibited). Exception was unhandled.
      Core 0 register dump:
      PC      : 0x400e1bae  PS      : 0x00060230  A0      : 0x800dd03d  A1      : 0x3ffebf80
      A2      : 0x3fff17c4  A3      : 0x3fff0ef0  A4      : 0x3fff17c4  A5      : 0x3fff17c8
      A6      : 0x00000000  A7      : 0x3fff0ef4  A8      : 0x00000000  A9      : 0x3ffebf30
      A10     : 0x73d2d9f0  A11     : 0x73d2d9f0  A12     : 0x00000000  A13     : 0x0000001f
      A14     : 0x00000001  A15     : 0x00000005  SAR     : 0x00000004  EXCCAUSE: 0x0000001c
      EXCVADDR: 0x00000010  LBEG    : 0x400014fd  LEND    : 0x4000150d  LCOUNT  : 0xfffffffd
      
      Backtrace: 0x400e1bae:0x3ffebf80 0x400dd03a:0x3ffec040 0x400dd48d:0x3ffec290 0x400de12b:0x3ffec730 0x400de197:0x3ffec780
      

      This is very likely what the Linux world refers to as a segmentation fault. Sorry I can't give better information; the debugging tools are the weak point of ESP32 development (IMO).

      kshegunovK Offline
      kshegunovK Offline
      kshegunov
      Moderators
      wrote on last edited by
      #19

      @mzimmers said in std::string error:

      This is very likely what the Linux world refers to as a segmentation fault.

      More like kernel panic, looking at the dump. Ordinary segfaults are handled by the kernel and don't usually dump the CPU registers. Are you sure you have enough memory on that device? One'd observe a similar thing on desktop if swapping is disabled and there's a syscall that can't free up memory (or the memory is corrupt at the point of the system call). Funnily I currently get similar dumps, but that's because my CPU is buggy.

      Read and abide by the Qt Code of Conduct

      kshegunovK 1 Reply Last reply
      1
      • kshegunovK kshegunov

        @mzimmers said in std::string error:

        This is very likely what the Linux world refers to as a segmentation fault.

        More like kernel panic, looking at the dump. Ordinary segfaults are handled by the kernel and don't usually dump the CPU registers. Are you sure you have enough memory on that device? One'd observe a similar thing on desktop if swapping is disabled and there's a syscall that can't free up memory (or the memory is corrupt at the point of the system call). Funnily I currently get similar dumps, but that's because my CPU is buggy.

        kshegunovK Offline
        kshegunovK Offline
        kshegunov
        Moderators
        wrote on last edited by
        #20

        PS.
        A quick look here (see error code 28) leads me to believe you have dereferencing of an invalid pointer (or a call to a function through an invalid address) due to EXCVADDR holding nonsense; so I'm back to my original assumption. It's going to be hard without debug info to trace this down, but could you try to build this application in debug mode so at least you can get a more human(e) backtrace?

        Read and abide by the Qt Code of Conduct

        mzimmersM 1 Reply Last reply
        0
        • kshegunovK kshegunov

          PS.
          A quick look here (see error code 28) leads me to believe you have dereferencing of an invalid pointer (or a call to a function through an invalid address) due to EXCVADDR holding nonsense; so I'm back to my original assumption. It's going to be hard without debug info to trace this down, but could you try to build this application in debug mode so at least you can get a more human(e) backtrace?

          mzimmersM Offline
          mzimmersM Offline
          mzimmers
          wrote on last edited by
          #21

          @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.

          kshegunovK 1 Reply Last reply
          0
          • mzimmersM 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.

            kshegunovK Offline
            kshegunovK Offline
            kshegunov
            Moderators
            wrote on last edited by kshegunov
            #22

            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);
            

            Read and abide by the Qt Code of Conduct

            1 Reply Last reply
            0
            • mzimmersM Offline
              mzimmersM Offline
              mzimmers
              wrote on last edited by
              #23

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

              1 Reply Last reply
              1
              • mzimmersM Offline
                mzimmersM Offline
                mzimmers
                wrote on last edited by
                #24

                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.

                kshegunovK 1 Reply Last reply
                0
                • mzimmersM 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.

                  kshegunovK Offline
                  kshegunovK Offline
                  kshegunov
                  Moderators
                  wrote on last edited by kshegunov
                  #25

                  @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 *);
                  };
                  

                  Read and abide by the Qt Code of Conduct

                  mzimmersM 1 Reply Last reply
                  1
                  • kshegunovK 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 *);
                    };
                    
                    mzimmersM Offline
                    mzimmersM Offline
                    mzimmers
                    wrote on last edited by
                    #26

                    @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...

                    kshegunovK 1 Reply Last reply
                    0
                    • mzimmersM 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...

                      kshegunovK Offline
                      kshegunovK Offline
                      kshegunov
                      Moderators
                      wrote on last edited by
                      #27

                      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 ... ;)

                      Read and abide by the Qt Code of Conduct

                      1 Reply Last reply
                      1

                      • Login

                      • Login or register to search.
                      • First post
                        Last post
                      0
                      • Categories
                      • Recent
                      • Tags
                      • Popular
                      • Users
                      • Groups
                      • Search
                      • Get Qt Extensions
                      • Unsolved