Re: [Openocd-development] STM32 reset halt segfault on Mac OS X
Steve Bennett wrote: > > on Mac OS libusb seems to behave bit erratically > > Yes. This is a known problem. Hm, please give more details? Some bugs are being fixed in libusb-1.0 for Mac OS, so hopefully it's one of them, but maybe not? //Peter ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] STM32 reset halt segfault on Mac OS X
On 01/12/2010, at 2:42 PM, Piotr Esden-Tempski wrote: > Hi ho, > > On Nov 30, 2010, at 2:31 PM, Steve Bennett wrote: > >> On 01/12/2010, at 7:44 AM, Piotr Esden-Tempski wrote: >> >>> >>> On Nov 30, 2010, at 1:04 PM, Piotr Esden-Tempski wrote: On Nov 30, 2010, at 12:03 PM, Steve Bennett wrote: > On 01/12/2010, at 12:12 AM, Edgar Grimberg wrote: > >> On Tue, Nov 30, 2010 at 1:02 PM, Øyvind Harboe >> wrote: >>> 32 vs. 64 bit problem? >> >> Wouldn't that be interesting? :) >> Are there Linux 64 users out there that can try it out? > > I note that Domen Puncer is having a similar problem. > Also looks like 64 bit from the stack trace. > > Piotr, can you try building 32 bit? > Something like: > > ./configure ... CFLAGS="-arch i386 -O0 -g" Yes sir! I just tested the newest version in git of oocd with -m32 on Mac OS X Snow leopard and it does NOT crash. So it is definitely a 64 bit problem here. Thanks for pointing that out! I will try to find a 64bit linux machine and see if I get the same error there. (maybe also someone else can take a stab at it?) >>> >>> Ok I just tested on 64bit ubuntu linux machine. And "sadly" it works there. >>> :( So the only way to trigger the segfault currently is running 64 bit >>> openocd binary on Snow Leopard. :( >> >> Are you able to run under valgrind on 64bit linux and mac? >> Could be the problem is still there but doesn't show up. >> >> Also, on mac, do you have an installed version of Jim (e.g. >> /usr/local/include/jim-config.h)? >> I wonder if it could be conflicting... Excellent debugging! > > Here we go. :) > > I cleaned up truthfully after every build. (stow helps :) ) So dangling > jim-config.h was not present. Good. > > I generated two valgrind outputs, one for the failing Mac OS 64 bit version > and the working Linux 64bit version. I was unable to run valgrind on the Mac > OS 32bit binary though because valgrind refuses doing that being 64bit itself > and me being too lazy to fight with it too much. (I may try to fight with it > at a later time but... well) :) > > So attached you find the two valgrind outputs. > > So beside the fact that on Mac OS libusb seems to behave bit erratically and > on linux Yes. This is a known problem. > Jim seems to be having fun leaking memory (but maybe that is just the charm > of every interpreter in general :) ) No, that is a real memory leak in Jim. Thanks for finding that one. Will be fixed shortly. > what is drawing my attention is buf_set_buf. This function seems to be > copying bit by bit data from the jtag buffer to the output as far as I > understand. I don't know the implications of it but it is copying data into > the buffer created by jtag_build_buffer that is assuming some alignment of > memory things and the bit by bit copy code is probably also assuming things. > I did not have much time to look into that code but what I found so far is > that linux malloc does not assure memory alignment. The Mac OS API assures > double word 16byte memory alignment in the darwin malloc returns. I am again > not sure what that means to the openocd code but maybe there is something > wrong with these assumptions? ... Definitely that needs more investigation. I'm not sure. Could be just that ft2232_read_scan() isn't filling the whole buffer. Although the buffer was allocated with calloc() so it should be initialised to 0. Perhaps someone more knowledgeable could look at that. Possibly defining _DEBUG_JTAG_IO_ would help. > > Maybe you guys have some new ideas where to poke next. I will continue poking > as time permits. But as I can compile using -m32 my efforts may slow down a > little. :) If the above isn't the problem, there could be problems around command_unknown() interp->cmdPrivData = c->jim_handler_data; return (*c->jim_handler)(interp, count, start); Setting cmdPrivData explicitly is probably not a good idea. I'm concerned that there is some 32/64 bit alignment issue or truncation happening somewhere in there. Not sure yet. The way openocd interfaces with jim is a bit convoluted. Cheers, Steve -- µWeb: Embedded Web Framework - http://uweb.workware.net.au/ WorkWare Systems Pty Ltd W: www.workware.net.au P: 0434 921 300 E: ste...@workware.net.au F: 07 3102 9221 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] STM32 reset halt segfault on Mac OS X
On 01/12/2010, at 7:44 AM, Piotr Esden-Tempski wrote: > > On Nov 30, 2010, at 1:04 PM, Piotr Esden-Tempski wrote: >> On Nov 30, 2010, at 12:03 PM, Steve Bennett wrote: >> >>> On 01/12/2010, at 12:12 AM, Edgar Grimberg wrote: >>> On Tue, Nov 30, 2010 at 1:02 PM, Øyvind Harboe wrote: > 32 vs. 64 bit problem? Wouldn't that be interesting? :) Are there Linux 64 users out there that can try it out? >>> >>> I note that Domen Puncer is having a similar problem. >>> Also looks like 64 bit from the stack trace. >>> >>> Piotr, can you try building 32 bit? >>> Something like: >>> >>> ./configure ... CFLAGS="-arch i386 -O0 -g" >> >> >> Yes sir! I just tested the newest version in git of oocd with -m32 on Mac OS >> X Snow leopard and it does NOT crash. So it is definitely a 64 bit problem >> here. >> >> Thanks for pointing that out! >> >> I will try to find a 64bit linux machine and see if I get the same error >> there. (maybe also someone else can take a stab at it?) > > Ok I just tested on 64bit ubuntu linux machine. And "sadly" it works there. > :( So the only way to trigger the segfault currently is running 64 bit > openocd binary on Snow Leopard. :( Are you able to run under valgrind on 64bit linux and mac? Could be the problem is still there but doesn't show up. Also, on mac, do you have an installed version of Jim (e.g. /usr/local/include/jim-config.h)? I wonder if it could be conflicting... -- µWeb: Embedded Web Framework - http://uweb.workware.net.au/ WorkWare Systems Pty Ltd W: www.workware.net.au P: 0434 921 300 E: ste...@workware.net.au F: 07 3102 9221 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] STM32 reset halt segfault on Mac OS X
On 01/12/2010, at 7:04 AM, Piotr Esden-Tempski wrote: > Hi, > > On Nov 30, 2010, at 12:03 PM, Steve Bennett wrote: > >> On 01/12/2010, at 12:12 AM, Edgar Grimberg wrote: >> >>> On Tue, Nov 30, 2010 at 1:02 PM, Øyvind Harboe >>> wrote: 32 vs. 64 bit problem? >>> >>> Wouldn't that be interesting? :) >>> Are there Linux 64 users out there that can try it out? >> >> I note that Domen Puncer is having a similar problem. >> Also looks like 64 bit from the stack trace. >> >> Piotr, can you try building 32 bit? >> Something like: >> >> ./configure ... CFLAGS="-arch i386 -O0 -g" > > > Yes sir! I just tested the newest version in git of oocd with -m32 on Mac OS > X Snow leopard and it does NOT crash. So it is definitely a 64 bit problem > here. Great. That's a start. Now to work out what the problem is on 64bit. > > Thanks for pointing that out! > > I will try to find a 64bit linux machine and see if I get the same error > there. (maybe also someone else can take a stab at it?) > > Cheers Esden > > -- > Blog: http://www.esden.net > Projects: > http://open-bldc.org > http://paparazziuav.org > http://github.org/esden/floss-jtag > http://github.org/esden/summon-arm-toolchain > > ___ > Openocd-development mailing list > Openocd-development@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/openocd-development -- µWeb: Embedded Web Framework - http://uweb.workware.net.au/ WorkWare Systems Pty Ltd W: www.workware.net.au P: 0434 921 300 E: ste...@workware.net.au F: 07 3102 9221 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] STM32 reset halt segfault on Mac OS X
On Nov 30, 2010, at 1:04 PM, Piotr Esden-Tempski wrote: > On Nov 30, 2010, at 12:03 PM, Steve Bennett wrote: > >> On 01/12/2010, at 12:12 AM, Edgar Grimberg wrote: >> >>> On Tue, Nov 30, 2010 at 1:02 PM, Øyvind Harboe >>> wrote: 32 vs. 64 bit problem? >>> >>> Wouldn't that be interesting? :) >>> Are there Linux 64 users out there that can try it out? >> >> I note that Domen Puncer is having a similar problem. >> Also looks like 64 bit from the stack trace. >> >> Piotr, can you try building 32 bit? >> Something like: >> >> ./configure ... CFLAGS="-arch i386 -O0 -g" > > > Yes sir! I just tested the newest version in git of oocd with -m32 on Mac OS > X Snow leopard and it does NOT crash. So it is definitely a 64 bit problem > here. > > Thanks for pointing that out! > > I will try to find a 64bit linux machine and see if I get the same error > there. (maybe also someone else can take a stab at it?) Ok I just tested on 64bit ubuntu linux machine. And "sadly" it works there. :( So the only way to trigger the segfault currently is running 64 bit openocd binary on Snow Leopard. :( Cheers Esden -- Blog: http://www.esden.net Projects: http://open-bldc.org http://paparazziuav.org http://github.org/esden/floss-jtag http://github.org/esden/summon-arm-toolchain PGP.sig Description: This is a digitally signed message part ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] STM32 reset halt segfault on Mac OS X
Hi, On Nov 30, 2010, at 12:03 PM, Steve Bennett wrote: > On 01/12/2010, at 12:12 AM, Edgar Grimberg wrote: > >> On Tue, Nov 30, 2010 at 1:02 PM, Øyvind Harboe >> wrote: >>> 32 vs. 64 bit problem? >> >> Wouldn't that be interesting? :) >> Are there Linux 64 users out there that can try it out? > > I note that Domen Puncer is having a similar problem. > Also looks like 64 bit from the stack trace. > > Piotr, can you try building 32 bit? > Something like: > > ./configure ... CFLAGS="-arch i386 -O0 -g" Yes sir! I just tested the newest version in git of oocd with -m32 on Mac OS X Snow leopard and it does NOT crash. So it is definitely a 64 bit problem here. Thanks for pointing that out! I will try to find a 64bit linux machine and see if I get the same error there. (maybe also someone else can take a stab at it?) Cheers Esden -- Blog: http://www.esden.net Projects: http://open-bldc.org http://paparazziuav.org http://github.org/esden/floss-jtag http://github.org/esden/summon-arm-toolchain PGP.sig Description: This is a digitally signed message part ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] STM32 reset halt segfault on Mac OS X
On 01/12/2010, at 12:12 AM, Edgar Grimberg wrote: > On Tue, Nov 30, 2010 at 1:02 PM, Øyvind Harboe > wrote: >> 32 vs. 64 bit problem? > > Wouldn't that be interesting? :) > Are there Linux 64 users out there that can try it out? I note that Domen Puncer is having a similar problem. Also looks like 64 bit from the stack trace. Piotr, can you try building 32 bit? Something like: ./configure ... CFLAGS="-arch i386 -O0 -g" -- µWeb: Embedded Web Framework - http://uweb.workware.net.au/ WorkWare Systems Pty Ltd W: www.workware.net.au P: 0434 921 300 E: ste...@workware.net.au F: 07 3102 9221 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] STM32 reset halt segfault on Mac OS X
> Do you think it's reproducible on a dummy jtag driver? If yes, I can > give it a try later on today. I don't think I can reproduce without the interface and target. I tried just with the dummy driver, but I don't think I reach the faulty part of the code. ./configure --enable-maintainer-mode --enable-dummy make openocd -f ./tcl/interface/dummy.cfg -f ./tcl/target/stm32.cfg Of course, openocd cannot connect to the target, "reset halt" fails with a nice error message, and no crash. > reset halt JTAG scan chain interrogation failed: all ones Check JTAG interface, timings, target power, etc. Trying to use configured scan chain anyway... stm32.cpu: IR capture error; saw 0x0f not 0x01 Bypassing JTAG setup events due to errors Invalid ACK 0x7 in JTAG-DP transaction examine-fails: -107 Command handler execution failed in procedure 'reset' Polling target failed, GDB will be halted. Polling again in 6300ms ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] STM32 reset halt segfault on Mac OS X
On Tue, Nov 30, 2010 at 1:02 PM, Øyvind Harboe wrote: > 32 vs. 64 bit problem? Wouldn't that be interesting? :) Are there Linux 64 users out there that can try it out? Edgar ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] STM32 reset halt segfault on Mac OS X
32 vs. 64 bit problem? -- Øyvind Harboe Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 63 25 00 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] STM32 reset halt segfault on Mac OS X
On Nov 30, 2010, at 12:28 AM, Edgar Grimberg wrote: >> Also if there are other Mac OS X users out there. It would be nice if they >> could try to compile the newest revision >> of openocd and see if they also get this kind of a crash to confirm that it >> has nothing to do with my setup? >> Because it is weird that the problem seems to be present since a while >> already and no one reported it until now. :) > > Do you think it's reproducible on a dummy jtag driver? If yes, I can > give it a try later on today. > > Edgar I have no idea how to use the dummy driver to connect to a dummy cortex-m3 processor. Because the segfault is being triggered by some of the arm code. But maybe if someone tells me how to use the dummy driver I may find out if I can trigger the error using that. Then I can confirm that it is testable using the dummy driver. Thanks for the offer. :) Cheers Esden -- Blog: http://www.esden.net Projects: http://open-bldc.org http://paparazziuav.org http://github.org/esden/floss-jtag http://github.org/esden/summon-arm-toolchain PGP.sig Description: This is a digitally signed message part ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] STM32 reset halt segfault on Mac OS X
> Also if there are other Mac OS X users out there. It would be nice if they > could try to compile the newest revision > of openocd and see if they also get this kind of a crash to confirm that it > has nothing to do with my setup? > Because it is weird that the problem seems to be present since a while > already and no one reported it until now. :) Do you think it's reproducible on a dummy jtag driver? If yes, I can give it a try later on today. Edgar ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] STM32 reset halt segfault on Mac OS X
On Nov 29, 2010, at 11:10 PM, Øyvind Harboe wrote: >> Thanks will try that next. I also dissected the commits and found out that >> the bug got introduced with commit: >> 3b68a708c2b039d9b091608eccb2206725742a47 ADIv5: remove ATOMIC/COMPOSITE >> interface mode >> >> In the previous revision everything works and with this one it stops working >> for me. > > Good catch! > > Unfortunately that's a pretty big commit. The next thing I could > suggest in terms of bisection would be to create a working > branch and split that commit as many times as possible and > do a bisect on that branch... Allright, so I did that and applying the attached patch to revision ecff73 exposes the problem. But I have the feeling that it is not the core reason for this problem. This only exposes it. I think that it has something to do with memory corruption in openocd. The core dump appears in cortex_m3_assert_reset and the patch changes scan_inout_check_u32 that in my unknowing eyes does not seem to touch anything related to that. But I don't have enough insight in the openocd codebase. So maybe David who wrote the patch has some kind of an explanation to what is happening. Also if there are other Mac OS X users out there. It would be nice if they could try to compile the newest revision of openocd and see if they also get this kind of a crash to confirm that it has nothing to do with my setup? Because it is weird that the problem seems to be present since a while already and no one reported it until now. :) Cheers Esden -- Blog: http://www.esden.net Projects: http://open-bldc.org http://paparazziuav.org http://github.org/esden/floss-jtag http://github.org/esden/summon-arm-toolchain patch-mac_os_crash_exposure.diff Description: Binary data PGP.sig Description: This is a digitally signed message part ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] STM32 reset halt segfault on Mac OS X
> Thanks will try that next. I also dissected the commits and found out that > the bug got introduced with commit: > 3b68a708c2b039d9b091608eccb2206725742a47 ADIv5: remove ATOMIC/COMPOSITE > interface mode > > In the previous revision everything works and with this one it stops working > for me. Good catch! Unfortunately that's a pretty big commit. The next thing I could suggest in terms of bisection would be to create a working branch and split that commit as many times as possible and do a bisect on that branch... -- Øyvind Harboe Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 63 25 00 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] STM32 reset halt segfault on Mac OS X
Hi, On Nov 29, 2010, at 4:24 PM, Antonio Borneo wrote: >> I did some more poking. Maybe it will be useful. As this seems to be a >> memory problem I thought maybe electric-fence will tell us something useful. >> So I compiled oocd with libefence, and this is what I get: >> > Try also "valgrind". > My understanding on electric-fence is that it uses MMU to set page > access permission. This method cannot set anything smaller that the > page size. > So, if you malloc a buffer of 1 byte, you get a full page with R/W permission. > Valgrind, instead, is a x86 (or PPC on old MAC) simulator. It catch > every memory access outside the range return by malloc. > > Antonio Thanks will try that next. I also dissected the commits and found out that the bug got introduced with commit: 3b68a708c2b039d9b091608eccb2206725742a47 ADIv5: remove ATOMIC/COMPOSITE interface mode In the previous revision everything works and with this one it stops working for me. Cheers Esden -- Blog: http://www.esden.net Projects: http://open-bldc.org http://paparazziuav.org http://github.org/esden/floss-jtag http://github.org/esden/summon-arm-toolchain PGP.sig Description: This is a digitally signed message part ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] STM32 reset halt segfault on Mac OS X
> I did some more poking. Maybe it will be useful. As this seems to be a memory > problem I thought maybe electric-fence will tell us something useful. So I > compiled oocd with libefence, and this is what I get: > Try also "valgrind". My understanding on electric-fence is that it uses MMU to set page access permission. This method cannot set anything smaller that the page size. So, if you malloc a buffer of 1 byte, you get a full page with R/W permission. Valgrind, instead, is a x86 (or PPC on old MAC) simulator. It catch every memory access outside the range return by malloc. Antonio ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] STM32 reset halt segfault on Mac OS X
On Nov 29, 2010, at 3:19 PM, Piotr Esden-Tempski wrote:
>
> On Nov 29, 2010, at 12:39 PM, Øyvind Harboe wrote:
>
>> Better.
>>
>> Could you try HEAD w/master branch?
>>
>>> #0 0x000100073314 in mem_ap_read_atomic_u32 (dap=0x10032f540,
>>> address=1, value=0x10032e800) at arm_adi_v5.c:214
>>
>> => this doesn't point to anything sensible, it's the tailend of the fn.
>>
>> Also try w/-O0
>>
>> CFLAGS="-O0 -g" configure ...
>> make clean
>> make
>
>
> I did that but it does not change anything. It is still failing at the same
> line. For more context maybe this helps. This is the signal I get:
> Program received signal EXC_BAD_ACCESS, Could not access memory.
> Reason: 13 at address: 0x
> 0x00010007325c in mem_ap_read_atomic_u32 (dap=0x10032f540, address=1,
> value=0x10032e800) at arm_adi_v5.c:214
>
> Also I stepped through the code and this is what is happening:
> jim_target_reset (interp=0x100308c90, argc=3, argv=0x7fff5fbfc9d8) at
> target.c:4321
> cortex_m3_assert_reset (target=0x10032e950) at cortex_m3.c:921
> mem_ap_read_atomic_u32 (dap=0x10032f7b0, address=3758157296,
> value=0x10032f6b0) at arm_adi_v5.c:209
> dap_run (dap=0x10032f7b0) at arm_adi_v5.h:337
> jtag_dp_run (dap=0x10032f7b0) at adi_v5_jtag.c:435
> jtagdp_transaction_endcheck (dap=0x10032f7b0) at adi_v5_jtag.c:222
> jtag_dp_run (dap=0x10032f7b0) at adi_v5_jtag.c:436
> dap_run (dap=0x10032f7b0) at arm_adi_v5.h:339
> mem_ap_read_atomic_u32 (dap=0x10032f7b0, address=3758157296,
> value=0x10032f6b0) at arm_adi_v5.c:214
>
> these calls work correctly in that order each calling the next. As soon as
> dap_run returns the mem_ap_read_atomic_u32 function wants to return the
> dap_run value but failes with the memory access error quoted before. I have
> never seen such wired behavior before.
I did some more poking. Maybe it will be useful. As this seems to be a memory
problem I thought maybe electric-fence will tell us something useful. So I
compiled oocd with libefence, and this is what I get:
Starting program: /opt/mine/bin/openocd -f interface/flossjtag.cfg -f
board/open-bldc.cfg
Reading symbols for shared libraries . done
Electric Fence 2.1 Copyright (C) 1987-1998 Bruce Perens.
ElectricFence Aborting: free(1003061b0): address not from malloc().
Program received signal SIGILL, Illegal instruction.
0x7fff82ac8616 in __kill ()
(gdb) bt
#0 0x7fff82ac8616 in __kill ()
#1 0x00012ec8 in EF_Abort (pattern=0x10012a2a8 "free(%a): address not
from malloc().") at print.c:137
#2 0x00012596 in free (address=0x1003061b0) at efence.c:699
#3 0x0001000e0301 in SetListFromAny (interp=0x100403e40,
objPtr=0x1005e4fc0) at jim.c:5453
#4 0x0001000e0c29 in Jim_ListLength (interp=0x100403e40,
objPtr=0x1005e4fc0) at jim.c:5728
#5 0x0001000edde5 in Jim_ProcCoreCommand (interp=0x100403e40, argc=4,
argv=0x7fff5fbff240) at jim.c:11775
#6 0x0001000e86b7 in Jim_EvalObj (interp=0x100403e40,
scriptObjPtr=0x100415fc0) at jim.c:9422
#7 0x0001000e8fd3 in Jim_Eval_Named (interp=0x100403e40,
script=0x10012dd48 "\n\n\nproc alias {name args} {\n\tset prefix $args\n\tproc
$name args prefix {\n\t\ttailcall {*}$prefix {*}$args\n\t}\n}\n\n\nproc lambda
{arglist args} {\n\tset name [ref {} function lambda.finalizer]\n\ttailcall
proc $"..., filename=0x10012dd3b "stdlib.tcl", lineno=1) at jim.c:9661
#8 0x000100101a18 in Jim_stdlibInit (interp=0x100403e40) at jim-stdlib.c:7
#9 0x0001000f4124 in Jim_InitStaticExtensions (interp=0x100403e40) at
jim-load-static-exts.c:10
#10 0x0001000d1363 in command_init (startup_tcl=0x10012fd80 "# Defines
basic Tcl procs that must exist for OpenOCD scripts to work.\n#\n# Embedded
into OpenOCD executable\n#\n\n\n# We need to explicitly redirect this to the
OpenOCD command\n# as Tcl defines the exit p"..., interp=0x100403e40) at
command.c:1338
#11 0x000139dc in setup_command_handler (interp=0x0) at openocd.c:267
#12 0x00013ae1 in openocd_main (argc=5, argv=0x7fff5fbff488) at
openocd.c:314
#13 0x00013153 in main (argc=5, argv=0x7fff5fbff488) at main.c:42
I have no clue about the internals of Jim so maybe I just did something wrong.
But who knows it may help. :)
Cheers Esden
--
Blog: http://www.esden.net
Projects:
http://open-bldc.org
http://paparazziuav.org
http://github.org/esden/floss-jtag
http://github.org/esden/summon-arm-toolchain
PGP.sig
Description: This is a digitally signed message part
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] STM32 reset halt segfault on Mac OS X
On Nov 29, 2010, at 12:39 PM, Øyvind Harboe wrote: > Better. > > Could you try HEAD w/master branch? > >> #0 0x000100073314 in mem_ap_read_atomic_u32 (dap=0x10032f540, >> address=1, value=0x10032e800) at arm_adi_v5.c:214 > > => this doesn't point to anything sensible, it's the tailend of the fn. > > Also try w/-O0 > > CFLAGS="-O0 -g" configure ... > make clean > make I did that but it does not change anything. It is still failing at the same line. For more context maybe this helps. This is the signal I get: Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: 13 at address: 0x 0x00010007325c in mem_ap_read_atomic_u32 (dap=0x10032f540, address=1, value=0x10032e800) at arm_adi_v5.c:214 Also I stepped through the code and this is what is happening: jim_target_reset (interp=0x100308c90, argc=3, argv=0x7fff5fbfc9d8) at target.c:4321 cortex_m3_assert_reset (target=0x10032e950) at cortex_m3.c:921 mem_ap_read_atomic_u32 (dap=0x10032f7b0, address=3758157296, value=0x10032f6b0) at arm_adi_v5.c:209 dap_run (dap=0x10032f7b0) at arm_adi_v5.h:337 jtag_dp_run (dap=0x10032f7b0) at adi_v5_jtag.c:435 jtagdp_transaction_endcheck (dap=0x10032f7b0) at adi_v5_jtag.c:222 jtag_dp_run (dap=0x10032f7b0) at adi_v5_jtag.c:436 dap_run (dap=0x10032f7b0) at arm_adi_v5.h:339 mem_ap_read_atomic_u32 (dap=0x10032f7b0, address=3758157296, value=0x10032f6b0) at arm_adi_v5.c:214 these calls work correctly in that order each calling the next. As soon as dap_run returns the mem_ap_read_atomic_u32 function wants to return the dap_run value but failes with the memory access error quoted before. I have never seen such wired behavior before. Cheers Esden -- Blog: http://www.esden.net Projects: http://open-bldc.org http://paparazziuav.org http://github.org/esden/floss-jtag http://github.org/esden/summon-arm-toolchain PGP.sig Description: This is a digitally signed message part ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] STM32 reset halt segfault on Mac OS X
Hi, On Nov 28, 2010, at 4:56 AM, Øyvind Harboe wrote: > This is a backtrace without line numbers. Could you try to > produce a backtrace with linenumbers? Yes sorry about that, here you go: #0 0x000100073314 in mem_ap_read_atomic_u32 (dap=0x10032f540, address=1, value=0x10032e800) at arm_adi_v5.c:214 #1 0x0001000b8a9a in jim_target_reset (interp=0x100308c90, argc=3, argv=0x7fff5fbfca48) at target.c:4321 #2 0x0001000cf4ca in command_unknown (interp=0x100308c90, argc=4, argv=0x7fff5fbfca40) at command.c:1053 #3 0x0001000e6f73 in Jim_EvalObj (interp=0x100308c90, scriptObjPtr=0x101857fe0) at jim.c:9422 #4 0x0001000ebef1 in Jim_EvalCoreCommand (interp=0x100308c90, argc=3, argv=0x7fff5fbfcb70) at jim.c:11579 #5 0x0001000e6f73 in Jim_EvalObj (interp=0x100308c90, scriptObjPtr=0x10032b5a0) at jim.c:9422 #6 0x0001000e6c88 in Jim_EvalObj (interp=0x100308c90, scriptObjPtr=0x1003196e0) at jim.c:9347 #7 0x0001000ea13b in Jim_IfCoreCommand (interp=0x100308c90, argc=5, argv=0x7fff5fbfcda0) at jim.c:10704 #8 0x0001000e6f73 in Jim_EvalObj (interp=0x100308c90, scriptObjPtr=0x10030f620) at jim.c:9422 #9 0x0001000e7681 in JimCallProcedure (interp=0x100308c90, cmd=0x100318350, filename=0x101857390 "", linenr=1, argc=3, argv=0x7fff5fbfcf58) at jim.c:9603 #10 0x0001000e6fa9 in Jim_EvalObj (interp=0x100308c90, scriptObjPtr=0x100388470) at jim.c:9425 #11 0x0001000ebef1 in Jim_EvalCoreCommand (interp=0x100308c90, argc=4, argv=0x7fff5fbfd060) at jim.c:11579 #12 0x0001000e6f73 in Jim_EvalObj (interp=0x100308c90, scriptObjPtr=0x10032e780) at jim.c:9422 #13 0x0001000e7681 in JimCallProcedure (interp=0x100308c90, cmd=0x100331080, filename=0x100388590 "embedded:startup.tcl", linenr=240, argc=3, argv=0x7fff5fbfd210) at jim.c:9603 #14 0x0001000e6fa9 in Jim_EvalObj (interp=0x100308c90, scriptObjPtr=0x101857970) at jim.c:9425 #15 0x0001000ea13b in Jim_IfCoreCommand (interp=0x100308c90, argc=3, argv=0x7fff5fbfd330) at jim.c:10704 #16 0x0001000e6f73 in Jim_EvalObj (interp=0x100308c90, scriptObjPtr=0x101854580) at jim.c:9422 #17 0x0001000e9e6c in JimForeachMapHelper (interp=0x100308c90, argc=4, argv=0x7fff5fbfd520, doMap=0) at jim.c:10641 #18 0x0001000ea045 in Jim_ForeachCoreCommand (interp=0x100308c90, argc=4, argv=0x7fff5fbfd520) at jim.c:10673 #19 0x0001000e6f73 in Jim_EvalObj (interp=0x100308c90, scriptObjPtr=0x100317e40) at jim.c:9422 #20 0x0001000e7681 in JimCallProcedure (interp=0x100308c90, cmd=0x10031b840, filename=0x101854140 "embedded:startup.tcl", linenr=180, argc=0, argv=0x7fff5fbfd6c0) at jim.c:9603 #21 0x0001000e6fa9 in Jim_EvalObj (interp=0x100308c90, scriptObjPtr=0x100329f60) at jim.c:9425 #22 0x0001000ee7ef in Jim_CatchCoreCommand (interp=0x100308c90, argc=2, argv=0x7fff5fbfd838) at jim.c:12394 #23 0x0001000e6f73 in Jim_EvalObj (interp=0x100308c90, scriptObjPtr=0x10032a260) at jim.c:9422 #24 0x0001000e6269 in Jim_InterpolateTokens (interp=0x100308c90, token=0x101853fb0, tokens=2, objPtrPtr=0x7fff5fbfda30) at jim.c:9099 #25 0x0001000e6ce9 in Jim_EvalObj (interp=0x100308c90, scriptObjPtr=0x10032a2b0) at jim.c:9360 #26 0x0001000e6c88 in Jim_EvalObj (interp=0x100308c90, scriptObjPtr=0x100317b60) at jim.c:9347 #27 0x0001000e7681 in JimCallProcedure (interp=0x100308c90, cmd=0x10031b940, filename=0x101851b90 "", linenr=1, argc=0, argv=0x7fff5fbfdc70) at jim.c:9603 #28 0x0001000e6fa9 in Jim_EvalObj (interp=0x100308c90, scriptObjPtr=0x10032a7e0) at jim.c:9425 #29 0x0001000e78b0 in Jim_Eval_Named (interp=0x100308c90, script=0x7fff5fbfddd0 "ocd_process_reset halt", filename=0x0, lineno=0) at jim.c:9666 #30 0x0001000e7905 in Jim_Eval (interp=0x100308c90, script=0x7fff5fbfddd0 "ocd_process_reset halt") at jim.c:9674 #31 0x0001000af555 in target_process_reset (cmd_ctx=0x101853160, reset_mode=RESET_HALT) at target.c:505 #32 0x0001000b2ebe in handle_reset_command (cmd=0x7fff5fbfdec0) at target.c:2203 #33 0x0001000ce2f8 in run_command (context=0x101853160, c=0x1003288d0, words=0x10183bb60, num_words=2) at command.c:627 #34 0x0001000cd2cc in script_command_run (interp=0x100308c90, argc=2, argv=0x7fff5fbfdfd0, c=0x1003288d0, capture=true) at command.c:227 #35 0x0001000cd37a in script_command (interp=0x100308c90, argc=2, argv=0x7fff5fbfdfd0) at command.c:242 #36 0x0001000e6f73 in Jim_EvalObj (interp=0x100308c90, scriptObjPtr=0x10032b6e0) at jim.c:9422 #37 0x0001000ebef1 in Jim_EvalCoreCommand (interp=0x100308c90, argc=3, argv=0x7fff5fbfe100) at jim.c:11579 #38 0x0001000e6f73 in Jim_EvalObj (interp=0x100308c90, scriptObjPtr=0x10031aa90) at jim.c:9422 #39 0x0001000ee7ef in Jim_CatchCoreCommand (interp=0x100308c90, argc=1, argv=0x7fff5fbfe288) at jim.c:12394 #40 0x0001000e6f73 in Jim_EvalObj (interp=0x100308c90, scriptObjPtr=0x10031a5d0) at jim.c:9422 #41 0x0001000e42b2 in Jim_EvalExpression (interp=0x100308c90, exprObjPtr=0x
Re: [Openocd-development] STM32 reset halt segfault on Mac OS X
This is a backtrace without line numbers. Could you try to produce a backtrace with linenumbers? Thanks! -- Øyvind Harboe Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 63 25 00 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] STM32 reset halt segfault on Mac OS X
Hi guys, I was playing around with the newest openocd git commit 9a0497. (although I oblserved the same error in previous revisions) It is not happening in the stable version of openocd v0.4.0. I tested using floss-jtag, jtag-key tiny and lisa-l all connected to stm32 targets. Running reset halt commands leads to a segfault. I include the backtrace. I compiled openocd on Mac OS X Snow Leopard (V 10.6.5) using GCC i686-apple-darwin10-gcc-4.2.1. I include the backtrace: #0 0x000100071804 in mem_ap_read_atomic_u32 () #1 0x0001000b6f8a in jim_target_reset () #2 0x0001000cd9ba in command_unknown () #3 0x0001000e5463 in Jim_EvalObj () #4 0x0001000ea3e1 in Jim_EvalCoreCommand () #5 0x0001000e5463 in Jim_EvalObj () #6 0x0001000e5178 in Jim_EvalObj () #7 0x0001000e862b in Jim_IfCoreCommand () #8 0x0001000e5463 in Jim_EvalObj () #9 0x0001000e5b71 in JimCallProcedure () #10 0x0001000e5499 in Jim_EvalObj () #11 0x0001000ea3e1 in Jim_EvalCoreCommand () #12 0x0001000e5463 in Jim_EvalObj () #13 0x0001000e5b71 in JimCallProcedure () #14 0x0001000e5499 in Jim_EvalObj () #15 0x0001000e862b in Jim_IfCoreCommand () #16 0x0001000e5463 in Jim_EvalObj () #17 0x0001000e835c in JimForeachMapHelper () #18 0x0001000e8535 in Jim_ForeachCoreCommand () #19 0x0001000e5463 in Jim_EvalObj () #20 0x0001000e5b71 in JimCallProcedure () #21 0x0001000e5499 in Jim_EvalObj () #22 0x0001000eccdf in Jim_CatchCoreCommand () #23 0x0001000e5463 in Jim_EvalObj () #24 0x0001000e4759 in Jim_InterpolateTokens () #25 0x0001000e51d9 in Jim_EvalObj () #26 0x0001000e5178 in Jim_EvalObj () #27 0x0001000e5b71 in JimCallProcedure () #28 0x0001000e5499 in Jim_EvalObj () #29 0x0001000e5da0 in Jim_Eval_Named () #30 0x0001000e5df5 in Jim_Eval () #31 0x0001000ada45 in target_process_reset () #32 0x0001000b13ae in handle_reset_command () #33 0x0001000cc7e8 in run_command () #34 0x0001000cb7bc in script_command_run () #35 0x0001000cb86a in script_command () #36 0x0001000e5463 in Jim_EvalObj () #37 0x0001000ea3e1 in Jim_EvalCoreCommand () #38 0x0001000e5463 in Jim_EvalObj () #39 0x0001000eccdf in Jim_CatchCoreCommand () #40 0x0001000e5463 in Jim_EvalObj () #41 0x0001000e27a2 in Jim_EvalExpression () #42 0x0001000e28ed in Jim_GetBoolFromExpr () #43 0x0001000e85b8 in Jim_IfCoreCommand () #44 0x0001000e5463 in Jim_EvalObj () #45 0x0001000e862b in Jim_IfCoreCommand () #46 0x0001000e5463 in Jim_EvalObj () #47 0x0001000e86f0 in Jim_IfCoreCommand () #48 0x0001000e5463 in Jim_EvalObj () #49 0x0001000e5b71 in JimCallProcedure () #50 0x0001000e5499 in Jim_EvalObj () #51 0x0001000ea3e1 in Jim_EvalCoreCommand () #52 0x0001000e5463 in Jim_EvalObj () #53 0x0001000e5b71 in JimCallProcedure () #54 0x0001000e5499 in Jim_EvalObj () #55 0x0001000e5da0 in Jim_Eval_Named () #56 0x0001000cc978 in command_run_line () #57 0x0001000c9826 in telnet_input () #58 0x0001000c809a in server_loop () #59 0x0001253c in openocd_main () #60 0x00011a87 in main () I hope that helps to track down the segfault. If I can provide any additional information or you can point me to how to debug and fix that bug I will greatly appreciate it! Cheers Esden -- My blog: http://www.esden.net My projects: http://open-bldc.org, http://openmulticopter.org ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
