Stack check failure with qemu_x86


Vakul Garg <vakul.garg@...>
 

Hi

 

I am running IPSP sample app using qemu_86 (on master branch).

I have enabled following to detect stack corruption.

 

+CONFIG_DEBUG=y

+CONFIG_STACK_USAGE=y

+CONFIG_STACK_SENTINEL=y

 

This results in stack check error.

I tried attaching gdb, but the qemu itself terminates resulting on closure of debug connection

 

Can someone give me pointers how to debug the same?

 

***** Stack Check Fail! *****

Current thread ID = 0x004035a0

Faulting segment:address = 0x0008:0x00003f6f

eax: 0x5be0cd19, ebx: 0xa54ff53a, ecx: 0x6a09e667, edx: 0x3c6ef372

esi: 0x1f83d9ab, edi: 0x510e527f, ebp: 0x9b05688c, esp: 0x0041dff8

eflags: 0x202

Terminate emulator due to fatal kernel error

 

 

Regards

 

Vakul

 


Luiz Augusto von Dentz
 

Hi Vakul,

On Thu, Dec 7, 2017 at 5:38 AM, Vakul Garg <vakul.garg@nxp.com> wrote:
Hi



I am running IPSP sample app using qemu_86 (on master branch).

I have enabled following to detect stack corruption.



+CONFIG_DEBUG=y

+CONFIG_STACK_USAGE=y

+CONFIG_STACK_SENTINEL=y



This results in stack check error.

I tried attaching gdb, but the qemu itself terminates resulting on closure
of debug connection



Can someone give me pointers how to debug the same?



***** Stack Check Fail! *****

Current thread ID = 0x004035a0

Faulting segment:address = 0x0008:0x00003f6f

eax: 0x5be0cd19, ebx: 0xa54ff53a, ecx: 0x6a09e667, edx: 0x3c6ef372

esi: 0x1f83d9ab, edi: 0x510e527f, ebp: 0x9b05688c, esp: 0x0041dff8

eflags: 0x202

Terminate emulator due to fatal kernel error
addr2line -e zephyr/zephyr.elf 0x00003f6f
/home/vudentz/git/zephyr-github/ext/lib/crypto/tinycrypt/source/hmac_prng.c:187

This is with samples/bluetooth/ipsp sample build with -DBOARD=qemu_x86





Regards



Vakul




_______________________________________________
Zephyr-users mailing list
Zephyr-users@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-users


--
Luiz Augusto von Dentz


Vakul Garg <vakul.garg@...>
 

Thanks.
I could resolve this issue on qemu_x86 by increasing MAIN_STACK_SIZE in the configuration.

I am not sure whether increasing stack size is required for my hardware board as well or is it only qemu_x86 which exhausted the stack and detected stack overflow.

I am debugging some issue on ARM based board (frdm-k64f) where I suspected corruption.
Does the stack check feature works on arm as well the same way as it worked over qemu_x86?
For the hardware board, zephyr/.config shows HW_STACK_PROTECTION=n.

-----Original Message-----
From: Luiz Augusto von Dentz [mailto:luiz.dentz@gmail.com]
Sent: Thursday, December 07, 2017 7:15 PM
To: Vakul Garg <vakul.garg@nxp.com>
Cc: zephyr-users@lists.zephyrproject.org
Subject: Re: [Zephyr-users] Stack check failure with qemu_x86

Hi Vakul,

On Thu, Dec 7, 2017 at 5:38 AM, Vakul Garg <vakul.garg@nxp.com> wrote:
Hi



I am running IPSP sample app using qemu_86 (on master branch).

I have enabled following to detect stack corruption.



+CONFIG_DEBUG=y

+CONFIG_STACK_USAGE=y

+CONFIG_STACK_SENTINEL=y



This results in stack check error.

I tried attaching gdb, but the qemu itself terminates resulting on
closure of debug connection



Can someone give me pointers how to debug the same?



***** Stack Check Fail! *****

Current thread ID = 0x004035a0

Faulting segment:address = 0x0008:0x00003f6f

eax: 0x5be0cd19, ebx: 0xa54ff53a, ecx: 0x6a09e667, edx: 0x3c6ef372

esi: 0x1f83d9ab, edi: 0x510e527f, ebp: 0x9b05688c, esp: 0x0041dff8

eflags: 0x202

Terminate emulator due to fatal kernel error
addr2line -e zephyr/zephyr.elf 0x00003f6f
/home/vudentz/git/zephyr-
github/ext/lib/crypto/tinycrypt/source/hmac_prng.c:187

This is with samples/bluetooth/ipsp sample build with -DBOARD=qemu_x86





Regards



Vakul




_______________________________________________
Zephyr-users mailing list
Zephyr-users@lists.zephyrproject.org
https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flis
ts.zephyrproject.org%2Fmailman%2Flistinfo%2Fzephyr-
users&data=02%7C01%
7Cvakul.garg%40nxp.com%7C20e3ff6b7a5f4e6bc3dd08d53d78aa01%7C68
6ea1d3bc
2b4c6fa92cd99c5c301635%7C0%7C0%7C636482510819985701&sdata=M
ZDhH8jJ73tT
ie6npumV7caNM3jtDFJoG1WA9gZtLIY%3D&reserved=0


--
Luiz Augusto von Dentz


Boie, Andrew P
 

There's no need to enable the stack sentinel on this target.

qemu_x86, by default, has MMU-assisted stack overflow protection enabled.

Unless you can reproduce this only when the sentinel is enabled? In which case this is a very interesting situation, please let me know.

 

In GDB you can set a breakpoint on _SysFatalErrorHandler() to debug when issues happen, all fatal exceptions go through there.

 

Andrew

 

From: zephyr-users-bounces@... [mailto:zephyr-users-bounces@...] On Behalf Of Vakul Garg
Sent: Wednesday, December 6, 2017 11:39 PM
To: zephyr-users@...
Subject: [Zephyr-users] Stack check failure with qemu_x86

 

Hi

 

I am running IPSP sample app using qemu_86 (on master branch).

I have enabled following to detect stack corruption.

 

+CONFIG_DEBUG=y

+CONFIG_STACK_USAGE=y

+CONFIG_STACK_SENTINEL=y

 

This results in stack check error.

I tried attaching gdb, but the qemu itself terminates resulting on closure of debug connection

 

Can someone give me pointers how to debug the same?

 

***** Stack Check Fail! *****

Current thread ID = 0x004035a0

Faulting segment:address = 0x0008:0x00003f6f

eax: 0x5be0cd19, ebx: 0xa54ff53a, ecx: 0x6a09e667, edx: 0x3c6ef372

esi: 0x1f83d9ab, edi: 0x510e527f, ebp: 0x9b05688c, esp: 0x0041dff8

eflags: 0x202

Terminate emulator due to fatal kernel error

 

 

Regards

 

Vakul

 


Vakul Garg <vakul.garg@...>
 

The stack check failure shows up with only stack sentinel enabled on qemu_x86 in my case.


- Vakul


From: Boie, Andrew P <andrew.p.boie@...>
Sent: Monday, December 11, 2017 10:37:38 PM
To: Vakul Garg; zephyr-users@...
Subject: RE: Stack check failure with qemu_x86
 

There's no need to enable the stack sentinel on this target.

qemu_x86, by default, has MMU-assisted stack overflow protection enabled.

Unless you can reproduce this only when the sentinel is enabled? In which case this is a very interesting situation, please let me know.

 

In GDB you can set a breakpoint on _SysFatalErrorHandler() to debug when issues happen, all fatal exceptions go through there.

 

Andrew

 

From: zephyr-users-bounces@... [mailto:zephyr-users-bounces@...] On Behalf Of Vakul Garg
Sent: Wednesday, December 6, 2017 11:39 PM
To: zephyr-users@...
Subject: [Zephyr-users] Stack check failure with qemu_x86

 

Hi

 

I am running IPSP sample app using qemu_86 (on master branch).

I have enabled following to detect stack corruption.

 

+CONFIG_DEBUG=y

+CONFIG_STACK_USAGE=y

+CONFIG_STACK_SENTINEL=y

 

This results in stack check error.

I tried attaching gdb, but the qemu itself terminates resulting on closure of debug connection

 

Can someone give me pointers how to debug the same?

 

***** Stack Check Fail! *****

Current thread ID = 0x004035a0

Faulting segment:address = 0x0008:0x00003f6f

eax: 0x5be0cd19, ebx: 0xa54ff53a, ecx: 0x6a09e667, edx: 0x3c6ef372

esi: 0x1f83d9ab, edi: 0x510e527f, ebp: 0x9b05688c, esp: 0x0041dff8

eflags: 0x202

Terminate emulator due to fatal kernel error

 

 

Regards

 

Vakul

 


Andy Gross
 

On 8 December 2017 at 00:08, Vakul Garg <vakul.garg@nxp.com> wrote:
Thanks.
I could resolve this issue on qemu_x86 by increasing MAIN_STACK_SIZE in the configuration.

I am not sure whether increasing stack size is required for my hardware board as well or is it only qemu_x86 which exhausted the stack and detected stack overflow.

I am debugging some issue on ARM based board (frdm-k64f) where I suspected corruption.
Does the stack check feature works on arm as well the same way as it worked over qemu_x86?
For the hardware board, zephyr/.config shows HW_STACK_PROTECTION=n.
The k64f does support stack protection. You just need to configure it
for use by setting HW_STACK_PROTECTION in your prj.conf. The QEMU ARM
target does not support MPU stack protection. Changes in both the
Zephyr ARM code and the qemu code are required (feature support and
bug fixes).