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. 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. Regards, Andreas On Tue, Jan 25, 2011 at 9:11 AM, Mathias K. <kes...@freenet.de> wrote: > Hello, > > > i had the same error a while ago. Try to clean your repository (make > distclean) and recompile the > source. > > > Regards, > > Mathias > > Am 24.01.2011 23:08, schrieb Andreas Fritiofson: >> Hi all, >> >> Has anyone else problem with segfaults on current git? As soon as I >> issue a reset, openocd dies. This is with a STM32 target. Same result >> with both rlink and a jtagkey interface. Bisection was successful and >> pointed to commit '8f93c0a3... target: do not expose error numbers to >> users' by Øyvind. Unfortunately, that patch seems very much unrelated. >> >> I suspect it's a 64-bit issue, because I've traced it to rbx >> (containing a pointer) getting trashed (some of the high 32 bits set) >> during the call to mem_ap_read_atomic_u32 in cortex_m3_assert_reset >> (cortex_m3.c:932), which causes the segfault later when it >> dereferences the pointer. >> >> My setup is as follows: >> $ uname -srvm >> Linux 2.6.32-27-generic #49-Ubuntu SMP Thu Dec 2 00:51:09 UTC 2010 x86_64 >> $ gcc -v >> gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5) >> >> I attach the git bisect test script that gave the following log: >> >> git bisect start >> # good: [c24087d33ec75144ec5f579142152d8eb5ce50c9] config: fix >> luminary jtag config >> git bisect good c24087d33ec75144ec5f579142152d8eb5ce50c9 >> # bad: [a72741818431d693e48b0f016258be0fec1f79da] stellaris: >> automatically generate and update device IDs >> git bisect bad a72741818431d693e48b0f016258be0fec1f79da >> # good: [56d9ee779d5d744822e5957c98c0d61ce3fc44a9] flash: print flash >> bank name on flash info cmd >> git bisect good 56d9ee779d5d744822e5957c98c0d61ce3fc44a9 >> # bad: [d356034f03eb60fd4e8b3537bd979d9e7e5e25f8] svf: implement sleep >> for RUNTEST min_time >> git bisect bad d356034f03eb60fd4e8b3537bd979d9e7e5e25f8 >> # bad: [21a1c6ec33f87b6285e47ad6597cd49ad89a9485] NAND/TCL: fix >> segfault on syntax error >> git bisect bad 21a1c6ec33f87b6285e47ad6597cd49ad89a9485 >> # bad: [eea91f71f918caa5e4ef571c76f60c579533b0f6] warning: fix warning >> where GCC didn't catch a doubly declared global structure >> git bisect bad eea91f71f918caa5e4ef571c76f60c579533b0f6 >> # good: [7cd2617384f4ac620c468343c1f2009fbfa2fc79] initial SWD >> transport (SWD infrastructure #2) >> git bisect good 7cd2617384f4ac620c468343c1f2009fbfa2fc79 >> # bad: [4f9a9b8ebae8425eda3a71ccb782789cd3b8f6b7] warnings: use more >> 'const' for char * >> git bisect bad 4f9a9b8ebae8425eda3a71ccb782789cd3b8f6b7 >> # bad: [8f93c0a3fe29313945a63b3f2154baef70acd796] target: do not >> expose error numbers to users >> git bisect bad 8f93c0a3fe29313945a63b3f2154baef70acd796 >> >> >> >> _______________________________________________ >> Openocd-development mailing list >> Openocd-development@lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/openocd-development > > _______________________________________________ > Openocd-development mailing list > Openocd-development@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/openocd-development > _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
