On Wed, Apr 19, 2017 at 04:33:05PM -0700, Jacob Rosenthal wrote:
> On Wed, Apr 19, 2017 at 11:19 AM, marko kiiskila <ma...@runtime.io> wrote:
>
> > Just general comments, I hope I’m not saying things which are
> > too obvious.
> >
> More specific would be even better :) I dont think my gdb is up to par
>
> Either g_os_run_list or one of the task structures is getting smashed.
> > As you know you tasks beforehand, you can walk through them manually
> > to figure which one it is.
> >
> How do I know the tasks beforehand? I would guess something in imgr_upload
> is corrupting it? So print as that function starts and ends? How do I walk
> through them manually?
You probably only have two tasks ("main" and the BLE controller). My
first guess would be that the main stack is overflowing, since that is
used by both the host and newtmgr. An easy way to tell if this is the
case is:
1. Reproduce the crash with gdb running.
2. In gdb type:
x/32wx os_main_stack
The first several values printed should be 0xdeadbeef. If they are
something else, then you have a stack overflow. You should increase the
size of the main stack by adjusting the OS_MAIN_STACK_SIZE syscfg
setting (default=1024 words).
>
> >
> > Usually culprit is stack overflow, so once you find out which task
> > structure
> > is being corrupt, look for the stack just after that in memory.
> >
> > nm output piped to sort is your friend in locating that stack.
> >
> nm output?
The "nm" tool shows you the address and size of each symbol in an elf
file. I recommend passing the "-S" option to it so that the sizes are
included in the output.
Chris
