am I running out of heap?

[ESP_Angus]

1. I recently moved to v3.2 of the IDF. I'm not sure I did this entirely correctly. First I tried doing an unzip, but somewhere along the line I got an error message telling me that I had to install via git, so I attempted to do so. It's very possible that I made a mistake using git. Is there some consistency check I can perform to tell me whether my IDF install is OK?

V3.2 is not yet released, so I'm guessing you mean the "master branch" which is currently development towards V3.2 (some more documentation on versioning is in the works). Master branch does require use of git.

You can use these git commands to update anything which may need updating, and then check the version you have:

Code: Select all

cd $IDF_PATH
git submodule update --init --recursive
git describe --tags --dirty

If the last command outputs a version that ends in "-dirty", use this command to see what is different in your local version:

Code: Select all

git status

2. I have several tasks running, which communicate through a data structure that contains pointers to each object in the tasks. Each task makes liberal use of routines in other task's primary object. (I can provide an example of this tomorrow.) Am I correct in assuming that all tasks share a common address space? (If not, I don't see how one task could overrun another task's heap.) I think my approach is valid, but I've never done it this way before, so I'm somewhat wary.

Yes, all tasks in the ESP32 share a common address space. They are like threads in a "big operating system" process.

Bear in mind that it it is still possible for a task to overrun one of its own buffers, though. Although if you're passing buffers between tasks, this increases the chance of some kind of race condition which causes an overrun.

[mzimmers]

Thanks Angus. I followed your instructions regarding git, and it looks like I'm OK with my IDF.

I used the heap checker to isolate the problem to a string assignment. Here's a code fragment; the offending line is noted near the end:

Code: Select all

void Worker::worker_task(TaskParams *params)
{
    Message *msgOut;
    system_event_t *scanResults = nullptr;
    string s;

    rc = xQueueReceiveFromISR(m_queueScanDone, &scanResults, &w);
    msgOut->formatScanResults(*scanResults, s);
}
void Message::formatScanResults(system_event_t results, string &str)
{
    char c_str[512];
    string l_str;

    sprintf(c_str, "Number of access points found: %d.\n",
            results.event_info.scan_done.number);
    l_str.append(c_str);

    uint16_t apCount = results.event_info.scan_done.number;
    if (apCount != 0)
    {
        wifi_ap_record_t *list = new wifi_ap_record_t[apCount];

        ESP_ERROR_CHECK(esp_wifi_scan_get_ap_records(&apCount, list));
        for (int i = 0; i < apCount; i++)
        {
            sprintf(c_str, "MAC = ");
            l_str.append(c_str);
            mac_itoa(list[i].bssid, c_str);
            l_str.append(c_str);

            sprintf(c_str, ", ssid = %s, rssi = %d", list[i].ssid, list[i].rssi);
            //        printf(", authmode=%s", authmode);
            l_str.append(c_str);
            l_str.append("\n");
        }
        delete[] list;
    }
    m_params->worker->checkHeap(11);
    str = l_str;											// ***** this is what's corrupting heap *****
    m_params->worker->checkHeap(12);
}

I realize that this isn't exactly an ESP issue at this point, but...can anyone see something wrong with my string assignment?

Thanks...

[chegewara]

If I would have to guess I would say it's too small stack.

[fly135]

If I would have to guess I would say it's too small stack.

I was thinking of commenting on the wisdom (or lack of) wrt putting big parameters on the stack, but he wasn't reporting a stack overflow error. Not sure if it's possible to overflow the stack and it show up as heap corruption.

John A

[mzimmers]

Before I began looking at heap problems, I experimented with doubling the task's stack size...no difference.

[mzimmers]

I was thinking of commenting on the wisdom (or lack of) wrt putting big parameters on the stack, but he wasn't reporting a stack overflow error. Not sure if it's possible to overflow the stack and it show up as heap corruption.

John A

What big parameters are you referring to? One is a pointer; the other a reference (which I believe is handed like a pointer under the skin).

[chegewara]

I think i have this error usually when i have too small stack ( but i may be wrong now):

multi_heap.c

EDIT You can easy test it with uxTaskGetStackHighWaterMark

[fly135]

What big parameters are you referring to? One is a pointer; the other a reference (which I believe is handed like a pointer under the skin).

The first parameter is a dereferenced pointer, which means you are putting a copy of the data structure on the stack. And you have a local var on the stack that's 512 bytes. Neither are necessarily a problem, but stack space on the esp32 does eat up precious internal memory.

John

[chegewara]

multi_heap.c

This means that one variable is overwritten by other variable (i guess), at least partially. Like i said, try with HighWaterMark or change Heap corruption detection (Basic (no poisoning)) in menuconfig to Comprehensive.

[mzimmers]

What big parameters are you referring to? One is a pointer; the other a reference (which I believe is handed like a pointer under the skin).

The first parameter is a dereferenced pointer, which means you are putting a copy of the data structure on the stack. And you have a local var on the stack that's 512 bytes. Neither are necessarily a problem, but stack space on the esp32 does eat up precious internal memory.

John

Yeah, you're right. I forgot that the struct will be passed by value. I doubt that's a problem, but your point about the char buffer is a reasonable concern. I'll change that. Thanks...