heap corruption any idea?

snahmad75
Posts: 445
Joined: Wed Jan 24, 2018 6:32 pm

heap corruption any idea?

Postby snahmad75 » Mon Apr 08, 2019 2:23 pm

Hi,

Kindly help in diagnosis. when I delete my big application object before esp_restart(); then I get this trace.

CORRUPT HEAP: Bad head at 0x3ffcfe24. Expected 0xabba1234 got 0x00000001
assertion "head != NULL" failed: file "C:/Work/library/esp32/master/esp-idf/components/heap/multi_heap_poisoning.c", line 214, function: multi_heap_free
abort() was called at PC 0x400da49b on core 0
0x400da49b: __assert_func at /home/jeroen/esp8266/esp32/newlib_xtensa-2.2.0-bin/newlib_xtensa-2.2.0/xtensa-esp32-elf/newlib/libc/stdlib/../../../.././newlib/libc/stdlib/assert.c:63 (discriminator 8)


Backtrace: 0x40093cb4:0x3ffba3e0 0x40093f01:0x3ffba400 0x400da49b:0x3ffba420 0x400999e3:0x3ffba450 0x400855ce:0x3ffba470 0x40085ee2:0x3ffba490 0x40085f99:0x3ffba4e0 0x400f1e01:0x3ffba500 0x40122d8d:0x3ffba520 0x40122e32:0x3ffba540 0x4010d18d:0x3ffba560 0x4010ed85:0x3ffba
580 0x4010ed92:0x3ffba5a0 0x400d78ee:0x3ffba5c0 0x400d9e59:0x3ffba5e0 0x400d24cc:0x3ffba960 0x40097be5:0x3ffba980
0x40093cb4: invoke_abort at C:/Work/library/esp32/master/esp-idf/components/esp32/panic.c:680

0x40093f01: abort at C:/Work/library/esp32/master/esp-idf/components/esp32/panic.c:680

0x400da49b: __assert_func at /home/jeroen/esp8266/esp32/newlib_xtensa-2.2.0-bin/newlib_xtensa-2.2.0/xtensa-esp32-elf/newlib/libc/stdlib/../../../.././newlib/libc/stdlib/assert.c:63 (discriminator 8)

0x400999e3: multi_heap_free at C:/Work/library/esp32/master/esp-idf/components/heap/multi_heap_poisoning.c:370

0x400855ce: heap_caps_free at C:/Work/library/esp32/master/esp-idf/components/heap/heap_caps.c:351

0x40085ee2: trace_free at C:/Work/library/esp32/master/esp-idf/components/heap/heap_trace.c:351

0x40085f99: __wrap_free at C:/Work/library/esp32/master/esp-idf/components/heap/heap_trace.c:399

0x400f1e01: operator delete(void*) at /builds/idf/crosstool-NG/.build/src/gcc-5.2.0/libstdc++-v3/libsupc++/del_op.cc:46

User avatar
fly135
Posts: 606
Joined: Wed Jan 03, 2018 8:33 pm
Location: Orlando, FL

Re: heap corruption any idea?

Postby fly135 » Mon Apr 08, 2019 2:52 pm

"Bad head at 0x3ffcfe24"

If you search the IDF for "head != NULL" and look at the ones that are an assert in the heap section, you will see the function "verify_allocated_region" is finding the header to the allocated region has been overwritten and the sanity check "(head->head_canary != HEAD_CANARY_PATTERN)" fails. So either 0x3ffcfe24 is a random bad number (doesn't look like it), or the block of memory allocated before 0x3ffcfe24 has buggy code that's writing an 0x00000001 past the end of it's memory (most likely).

snahmad75
Posts: 445
Joined: Wed Jan 24, 2018 6:32 pm

Re: heap corruption any idea?

Postby snahmad75 » Mon Apr 08, 2019 9:37 pm

fly135 wrote:
Mon Apr 08, 2019 2:52 pm
"Bad head at 0x3ffcfe24"

If you search the IDF for "head != NULL" and look at the ones that are an assert in the heap section, you will see the function "verify_allocated_region" is finding the header to the allocated region has been overwritten and the sanity check "(head->head_canary != HEAD_CANARY_PATTERN)" fails. So either 0x3ffcfe24 is a random bad number (doesn't look like it), or the block of memory allocated before 0x3ffcfe24 has buggy code that's writing an 0x00000001 past the end of it's memory (most likely).
Thanks for reply. I will investigate who allocated at 0x3ffcfe24 address

User avatar
fly135
Posts: 606
Joined: Wed Jan 03, 2018 8:33 pm
Location: Orlando, FL

Re: heap corruption any idea?

Postby fly135 » Mon Apr 08, 2019 11:54 pm

snahmad75 wrote:
Mon Apr 08, 2019 9:37 pm
Thanks for reply. I will investigate who allocated at 0x3ffcfe24 address
The allocated address where the problem is from is probably the one before 0x3ffcfe24. That's the block that's writing past the end and overwriting the next allocation information.

snahmad75
Posts: 445
Joined: Wed Jan 24, 2018 6:32 pm

Re: heap corruption any idea?

Postby snahmad75 » Tue Apr 09, 2019 6:10 pm

It looks like related with C++ 11 std::recursive_mutex.

Now I change to std::mutex. It is working now.

snahmad75
Posts: 445
Joined: Wed Jan 24, 2018 6:32 pm

Re: heap corruption any idea?

Postby snahmad75 » Tue Apr 09, 2019 6:37 pm

Sorry. I am wrong.

C++ list remove.

getting this error any idea?

(63079) W2K: Exit TCPDataEndPoint::close(port=60003)
I (63085) W2K: TCPDataEndPoint::~TCPDataEndPoint
I (63090) W2K: Enter SocketDataEndPoint::~SocketDataEndPoint(formatter_id_=1)
I (63098) W2K: Enter BDTPDeserialiser::~BDTPDeserialiser()
I (63104) W2K: Exit BDTPDeserialiser::~BDTPDeserialiser()
I (63110) W2K: Enter CanPacketCircularFifo::~CanPacketCircularFifo capacity_=5000
I (63134) W2K: Exit CanPacketCircularFifo::~CanPacketCircularFifo capacity_=5000
I (63136) W2K: Exit SocketDataEndPoint::~SocketDataEndPoint
I (63137) W2K: UDPDataEndPoint::~UDPDataEndPoint
I (63143) W2K: Enter SocketDataEndPoint::~SocketDataEndPoint(formatter_id_=0)
I (63155) W2K: Exit SocketDataEndPoint::~SocketDataEndPoint
I (63157) W2K: TCPDataEndPoint::~TCPDataEndPoint
I (63162) W2K: Enter SocketDataEndPoint::~SocketDataEndPoint(formatter_id_=1)
I (63170) W2K: Enter BDTPDeserialiser::~BDTPDeserialiser()
I (63176) W2K: Exit BDTPDeserialiser::~BDTPDeserialiser()
I (63182) W2K: Enter CanPacketCircularFifo::~CanPacketCircularFifo capacity_=5000
I (63205) W2K: Exit CanPacketCircularFifo::~CanPacketCircularFifo capacity_=5000
I (63208) W2K: Exit SocketDataEndPoint::~SocketDataEndPoint
Guru Meditation Error: Core 0 panic'ed (StoreProhibited). Exception was unhandled.
Core 0 register dump:
PC : 0x400992d9 PS : 0x00060e30 A0 : 0x80098e88 A1 : 0x3ffbc8f0
0x400992d9: uxListRemove at C:/Work/library/esp32/master/esp-idf/components/freertos/list.c:214

A2 : 0x3ffece1c A3 : 0x00000000 A4 : 0x3ffbb8b0 A5 : 0x00000000
A6 : 0x3ffbb998 A7 : 0x3ffbba20 A8 : 0xfefefefe A9 : 0xfefefefe
A10 : 0xfefefefe A11 : 0x3ffbc910 A12 : 0x00000001 A13 : 0x00000001
A14 : 0x00060e20 A15 : 0x00000000 SAR : 0x00000020 EXCCAUSE: 0x0000001d
EXCVADDR: 0xfefeff06 LBEG : 0x4009ca04 LEND : 0x4009ca32 LCOUNT : 0x00000000
0x4009ca04: memcpy at /home/jeroen/esp8266/esp32/newlib_xtensa-2.2.0-bin/newlib_xtensa-2.2.0/xtensa-esp32-elf/newlib/libc/machine/xtensa/../../../../.././newlib/libc/machine/xtensa/memcpy.S:168

0x4009ca32: memcpy at /home/jeroen/esp8266/esp32/newlib_xtensa-2.2.0-bin/newlib_xtensa-2.2.0/xtensa-esp32-elf/newlib/libc/machine/xtensa/../../../../.././newlib/libc/machine/xtensa/memcpy.S:201


Backtrace: 0x400992d9:0x3ffbc8f0 0x40098e85:0x3ffbc910 0x40098f57:0x3ffbc950 0x400977a9:0x3ffbc980
0x400992d9: uxListRemove at C:/Work/library/esp32/master/esp-idf/components/freertos/list.c:214

0x40098e85: prvProcessReceivedCommands at C:/Work/library/esp32/master/esp-idf/components/freertos/timers.c:736

0x40098f57: prvTimerTask at C:/Work/library/esp32/master/esp-idf/components/freertos/timers.c:546 (discriminator 1)

0x400977a9: vPortTaskWrapper at C:/Work/library/esp32/master/esp-idf/components/freertos/port.c:355 (discriminator 1)

ESP_Angus
Posts: 2344
Joined: Sun May 08, 2016 4:11 am

Re: heap corruption any idea?

Postby ESP_Angus » Tue Apr 09, 2019 11:42 pm

Hi snahmad,

Do you have Comprehensive heap checking turned on?

This value - 0xfefefefe - turns up in a few of your register dumps, as well as 0xfefeff06 (0xfefefefe + 8). If Comprehensive heap checking is turned on, the value 0xfefefefe indicates a "Use after free" bug - one part of your code is freeing some data but a pointer to this data is still around, and is being used later by some other part of your code.

In this case it looks like the freed data is related to a FreeRTOS Timer structure?

You can read more about Comprehensive heap checking here:
https://docs.espressif.com/projects/esp ... nsive-mode

snahmad75
Posts: 445
Joined: Wed Jan 24, 2018 6:32 pm

Re: heap corruption any idea?

Postby snahmad75 » Wed Apr 10, 2019 10:34 am

This looks to be related with hardware timer I am using hardware timer and start and stop it and delete it.

I do stop

Code: Select all

ARLErrorCode_e HardwareTimer::stop ()
{
	ACDTRACEF(ES_NoError, "HardwareTimer::stopping");

	std::lock_guard<std::mutex> lock(_observer_mutex_);
	for (s32 i = 0; i < size_; i++) {
		observers_[i] = nullptr;
	}
	size_ = 0;
	if (__started) {
		
		if (xTimerStop(__timer, portMAX_DELAY) != pdPASS) {
			ACDTRACEF(ES38_DEVICE_DRIVER_ERROR, "xTimerStop error \n");
			return ES38_DEVICE_DRIVER_ERROR;
		}

		xTimerDelete(__timer, portMAX_DELAY);
		__timer = NULL;
		
		__started = false;
		ACDTRACEF(ES_NoError, "HardwareTimer::stopped");
	}

	return ES_NoError;
}
I (36032) W2K: HardwareTimer::stopping
I (36034) W2K: HardwareTimer::stopped
Guru Meditation Error: Core 0 panic'ed (StoreProhibited). Exception was unhandled.
Core 0 register dump:
PC : 0x40096669 PS : 0x00060430 A0 : 0x80096277 A1 : 0x3ffbc850
0x40096669: uxListRemove at C:/Work/library/esp32/master/esp-idf/components/freertos/list.c:214

A2 : 0x3ffe3ed4 A3 : 0x00000000 A4 : 0x3ffbb7b0 A5 : 0x00000000
A6 : 0x3ffbb8b8 A7 : 0x00000000 A8 : 0xfefefefe A9 : 0xfefefefe
A10 : 0xfefefefe A11 : 0x3ffbc870 A12 : 0x3ffbc920 A13 : 0x00000001
A14 : 0x000000fe A15 : 0x00000000 SAR : 0x0000001b EXCCAUSE: 0x0000001d
EXCVADDR: 0xfefeff06 LBEG : 0x40099b3c LEND : 0x40099b6a LCOUNT : 0x00000000
0x40099b3c: memcpy at /home/jeroen/esp8266/esp32/newlib_xtensa-2.2.0-bin/newlib_xtensa-2.2.0/xtensa-esp32-elf/newlib/libc/machine/xtensa/../../../../.././newlib/libc/machine/xtensa/memcpy.S:168

0x40099b6a: memcpy at /home/jeroen/esp8266/esp32/newlib_xtensa-2.2.0-bin/newlib_xtensa-2.2.0/xtensa-esp32-elf/newlib/libc/machine/xtensa/../../../../.././newlib/libc/machine/xtensa/memcpy.S:201


Backtrace: 0x40096669:0x3ffbc850 0x40096274:0x3ffbc870
0x40096669: uxListRemove at C:/Work/library/esp32/master/esp-idf/components/freertos/list.c:214

0x40096274: prvProcessReceivedCommands at C:/Work/library/esp32/master/esp-idf/components/freertos/timers.c:736
(inlined by) prvTimerTask at C:/Work/library/esp32/master/esp-idf/components/freertos/timers.c:546

snahmad75
Posts: 445
Joined: Wed Jan 24, 2018 6:32 pm

Re: heap corruption any idea?

Postby snahmad75 » Wed Apr 10, 2019 2:40 pm

Still hardware timer crash.

ore 0 register dump:
PC : 0x40096645 PS : 0x00060430 A0 : 0x80096253 A1 : 0x3ffbc840
0x40096645: uxListRemove at C:/Work/library/esp32/master/esp-idf/components/freertos/list.c:214

A2 : 0x3ffed928 A3 : 0x00000000 A4 : 0x3ffbb7a0 A5 : 0x00000000
A6 : 0x3ffbb858 A7 : 0x00000000 A8 : 0xfefefefe A9 : 0xfefefefe
A10 : 0xfefefefe A11 : 0x3ffbc860 A12 : 0x3ffbc910 A13 : 0x00000001
A14 : 0x000000fe A15 : 0x00000000 SAR : 0x0000001b EXCCAUSE: 0x0000001d
EXCVADDR: 0xfefeff06 LBEG : 0x40099b18 LEND : 0x40099b46 LCOUNT : 0x00000000
0x40099b18: memcpy at /home/jeroen/esp8266/esp32/newlib_xtensa-2.2.0-bin/newlib_xtensa-2.2.0/xtensa-esp32-elf/newlib/libc/machine/xtensa/../../../../.././newlib/libc/machine/xtensa/memcpy.S:168

0x40099b46: memcpy at /home/jeroen/esp8266/esp32/newlib_xtensa-2.2.0-bin/newlib_xtensa-2.2.0/xtensa-esp32-elf/newlib/libc/machine/xtensa/../../../../.././newlib/libc/machine/xtensa/memcpy.S:201


Backtrace: 0x40096645:0x3ffbc840 0x40096250:0x3ffbc860
0x40096645: uxListRemove at C:/Work/library/esp32/master/esp-idf/components/freertos/list.c:214

0x40096250: prvProcessReceivedCommands at C:/Work/library/esp32/master/esp-idf/components/freertos/timers.c:736
(inlined by) prvTimerTask at C:/Work/library/esp32/master/esp-idf/components/freertos/timers.c:546

snahmad75
Posts: 445
Joined: Wed Jan 24, 2018 6:32 pm

Re: heap corruption any idea?

Postby snahmad75 » Wed Apr 10, 2019 9:05 pm

It looks like related with hardware time not stop properly.

I will investigate

Who is online

Users browsing this forum: Google [Bot], Pedro Hugo PSC and 114 guests