Re: [Openocd-development] segfault in cortex_m3_assert_reset

[Øyvind H. <oyv...@zy...>]

On Tue, Jan 25, 2011 at 2:17 PM, Andreas Fritiofson
<and...@gm...> wrote:
> Mathias:
> I built in a fresh out-of-tree directory, and reran bootstrap every
> time. See test.sh script. Anyway I found the bug, the patch I posted
> solves it for me. Since the stack was corrupted, technically, anything
> could have happened. It was just magically consistent during my
> bisection.
>
> All:
> Finding the bug got me thinking. All this error propagation code that
> is all over the place:
> retval = jtag_queue_foo(&bar); if (retval != ERROR_OK) return retval;
>
> What happens if a queue operation fails and the function returns
> without having executed any previously queued reads? Those reads are
> often to stack allocated variables that goes out of scope if we
> return. Is the queue discarded if there's an error? Otherwise the will
> be massive stack corruption when a subsequent operation executes the
> queue.

Check the source... I think this is broken as you describe. Note that
error propagation will happen most often when  propagating errors
on callbacks, so it would not surprise me at all to see OpenOCD crashing
in this case. Should be fixed as a matter of cleanliness even if it has
not been observed.

> Also, what are the possible failure modes for the queue operations? Is
> there any way they can fail other than out-of-memory? Maybe it's not
> the best solution to error check every individual queue operation.
> Maybe the queue operations should be transactional, so that either all
> or none of a set of related operations are added to the queue. Only
> the transaction as a whole would need to be error checked.

There is a "execute queue, but do not clear the error"  capability.

A single queue is "transactional", there is no concept of multiple queues
being merged. Basically the OpenOCD code generally postpones executing
a queue for as long as possible, i.e. until some data must be read into
a local variable or the result must be used in execution.


-- 
Øyvind Harboe

Can Zylin Consulting help on your project?

US toll free 1-866-980-3434 / International +47 51 87 40 27

http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger and flash programmer