Hi Rick I'm sorry to have disappeared, I had a bunch of lessons and exams to give so i didn't have time to work on this.
good news and bad news: the complete program crash has stopped with the latest svn, however the gdb keep alive packet errors are still there. so in the meantime: I'm actually going to try to step debug a typical flashing and put a hook on the error about gdb packet time outs so maybe i can step backwards and see where this comes from... Is this worthwhile? --federico "Anyone who has never made a mistake has never tried anything new." - Albert Einstein On Wed, Nov 26, 2008 at 7:04 AM, Rick Altherr <kc8...@kc8apf.net> wrote: > I don't see any obvious reason for this. destroy_reg_param() frees exactly > one item in the passed structure. From working through the code, the > pointer being freed shouldn't be changed. Sadly, that means this is likely > to be much more difficult to track. Is it easily reproducible? If so, > could you set a breakpoint cfi.c:1196 and look at the value in > reg_params[0].value. Then, set a breakpoint at cfi.c:1277 and look at the > same variable. Is the value the same? > > Rick > > > > On Nov 7, 2008, at 6:55 AM, Federico Spadini wrote: > > Hi guys, >> Rick, here's the gdb output: >> >> Error: Unable to write block write code to target >> >> Program received signal SIGSEGV, Segmentation fault. >> [Switching to Thread 0x7f7e0f8626e0 (LWP 16245)] >> 0x00007f7e0ef4fbcb in free () from /lib/libc.so.6 >> (gdb) bt >> #0 0x00007f7e0ef4fbcb in free () from /lib/libc.so.6 >> #1 0x000000000041c0fd in destroy_reg_param (param=0x7fff17879580) at >> algorithm.c:57 >> #2 0x000000000048afeb in cfi_intel_write_block (bank=0x73cdd0, >> buffer=0x7a0880 "+\006", address=0, count=7328) >> at cfi.c:1277 >> #3 0x000000000048c853 in cfi_write (bank=0x73cdd0, buffer=0x7a0880 >> "+\006", offset=2049, count=7328) >> at cfi.c:1928 >> #4 0x0000000000484900 in flash_driver_write (bank=0x73cdd0, >> buffer=0x7a06d0 "", offset=0, count=0) >> at flash.c:108 >> #5 0x000000000048633a in flash_write (target=0x730230, >> image=0x7fff17879820, written=0x7fff178797fc, erase=0) >> at flash.c:1108 >> #6 0x00000000004858b9 in handle_flash_write_image_command >> (cmd_ctx=0x73fa70, cmd=0x7a06d0 "", args=0x79ecb8, >> argc=1) at flash.c:699 >> #7 0x000000000046429e in run_command (context=0x73fa70, c=0x78c540, >> words=0x801, num_words=0) at command.c:382 >> #8 0x0000000000463b1c in script_command (interp=0x7070d0, argc=2, >> argv=0x7fff17879960) at command.c:120 >> #9 0x000000000047311f in Jim_EvalObj (interp=0x7070d0, >> scriptObjPtr=0x79e8e0) at jim.c:8630 >> #10 0x000000000047311f in Jim_EvalObj (interp=0x7070d0, >> scriptObjPtr=0x79cba0) at jim.c:8630 >> #11 0x00000000004787a3 in Jim_CatchCoreCommand (interp=0x7070d0, >> argc=2, argv=0x7fff17879b30) at jim.c:11288 >> #12 0x000000000047311f in Jim_EvalObj (interp=0x7070d0, >> scriptObjPtr=0x79ca00) at jim.c:8630 >> #13 0x0000000000470d12 in Jim_EvalExpression (interp=0x7070d0, >> exprObjPtr=0x7992a0, >> exprResultPtrPtr=0x7fff17879cc0) at jim.c:6886 >> #14 0x0000000000470e4e in Jim_GetBoolFromExpr (interp=0x7070d0, >> exprObjPtr=0x7a06d0, boolPtr=0x7fff17879ce4) >> at jim.c:7158 >> #15 0x00000000004763dc in Jim_IfCoreCommand (interp=0x7070d0, argc=5, >> argv=0x7fff17879d70) at jim.c:10186 >> #16 0x000000000047311f in Jim_EvalObj (interp=0x7070d0, >> scriptObjPtr=0x78cf80) at jim.c:8630 >> #17 0x00000000004736b5 in JimCallProcedure (interp=0x7070d0, >> cmd=0x78cda0, argc=7989168, argv=0x7fff17879ea0) >> at jim.c:8746 >> #18 0x00000000004732cc in Jim_EvalObj (interp=0x7070d0, >> scriptObjPtr=0x799030) at jim.c:8632 >> #19 0x000000000047311f in Jim_EvalObj (interp=0x7070d0, >> scriptObjPtr=0x739750) at jim.c:8630 >> #20 0x0000000000473462 in Jim_EvalObj (interp=0x7070d0, >> scriptObjPtr=0x738260) at jim.c:8576 >> #21 0x0000000000476495 in Jim_IfCoreCommand (interp=0x7070d0, argc=3, >> argv=0x7fff1787a150) at jim.c:10217 >> #22 0x000000000047311f in Jim_EvalObj (interp=0x7070d0, >> scriptObjPtr=0x7114f0) at jim.c:8630 >> #23 0x00000000004736b5 in JimCallProcedure (interp=0x7070d0, >> cmd=0x71a180, argc=7965008, argv=0x7fff1787a260) >> at jim.c:8746 >> #24 0x0000000000472bda in Jim_EvalObjVector (interp=0x7070d0, objc=4, >> objv=0x7fff1787a260) at jim.c:8346 >> #25 0x0000000000472abf in JimUnknown (interp=0x7070d0, argc=3, >> argv=0x7fff1787a320) at jim.c:8311 >> #26 0x000000000047333d in Jim_EvalObj (interp=0x7070d0, >> scriptObjPtr=0x71ffc0) at jim.c:8641 >> #27 0x0000000000473821 in Jim_Eval_Named (interp=0x7070d0, >> script=0x7a06d0 "", filename=0x4c37f6 "command.c", >> lineno=436) at jim.c:8790 >> #28 0x0000000000464512 in command_run_line (context=0x0, >> line=0x79734c "flash write_image >> >> /home/fspadini/motes/tinyos2.x/apps/Blink/build/intelmote2/main.bin.out-100") >> at command.c:436 >> #29 0x000000000047ed84 in telnet_input (connection=0x791350) at >> telnet_server.c:345 >> #30 0x000000000047d7f9 in server_loop (command_context=0x7070a0) at >> server.c:392 >> #31 0x000000000040350b in openocd_main (argc=9, argv=0x7fff1787ab58) >> at openocd.c:264 >> #32 0x00007f7e0eef61c4 in __libc_start_main () from /lib/libc.so.6 >> #33 0x0000000000402429 in _start () >> >> --fed >> >> >> >> >> "Anyone who has never made a mistake has never tried anything new." >> - Albert Einstein >> >> >> >> On Thu, Nov 6, 2008 at 4:32 PM, Rick Altherr <kc8...@kc8apf.net> wrote: >> >>> Run openocd under gdb and when you get a segmentation fault, type "bt" at >>> the gdb command prompt. Paste the results here. The output from openocd >>> from before the segfault would be useful as well. >>> >>> Rick >>> >>> >>> On Nov 6, 2008, at 6:59 AM, Federico Spadini wrote: >>> >>> Hi Oyvind, >>>> I agree wholeheartedly. I'm looking into it... I'm going to probably >>>> have to take blame for configuration file differences... I realized >>>> that in my systematic testing at version 826 I started having to futz >>>> with my configurations a bit to get things running (hmmh, so not >>>> really so systematic). >>>> >>>> i've installed the latest svn head and am re-analyzing my >>>> configurations... >>>> >>>> As I wrote this email: >>>> >>>> I'm blue in the face. i think i forgot a line of code... jtag_speed 0 >>>> in my olimex-arm-usb file... >>>> >>>> however, the flashing worked a single time then failed on the latest >>>> trunk. now i'm getting a segmentation fault. >>>> >>>> *shakes his head in confusion* >>>> >>>> any tips on how to verify that my configs are working? i can erase the >>>> flash, i can read the flash... but i just can't seem to write it? >>>> >>>> >>>> >>>> "Anyone who has never made a mistake has never tried anything new." >>>> - Albert Einstein >>>> >>>> >>>> >>>> On Thu, Nov 6, 2008 at 2:45 PM, Øyvind Harboe <oyvind.har...@zylin.com> >>>> wrote: >>>> >>>>> >>>>> On Thu, Nov 6, 2008 at 2:17 PM, Federico Spadini <spad...@iname.com> >>>>> wrote: >>>>> >>>>>> >>>>>> Hey Guys, >>>>>> So to respond, r826 is the first point of failure I found (825 works >>>>>> and flashes) 826 fails and does not flash. >>>>>> >>>>> >>>>> It is inconceivable (ref. The Princess Bride) that the problem was >>>>> introduced >>>>> with 826. >>>>> >>>>> If you do find that 826 introduces the problem, can you create a patch >>>>> against 825 which contains *only* the changes that breaks 825? >>>>> >>>>> This is very strange indeed. >>>>> >>>>> -- >>>>> Øyvind Harboe >>>>> http://www.zylin.com/zy1000.html >>>>> ARM7 ARM9 XScale Cortex >>>>> JTAG debugger and flash programmer >>>>> >>>>> >>>>> _______________________________________________ >>>> Openocd-development mailing list >>>> Openocd-development@lists.berlios.de >>>> https://lists.berlios.de/mailman/listinfo/openocd-development >>>> >>> >>> -- >>> Rick Altherr >>> kc8...@kc8apf.net >>> >>> "He said he hadn't had a byte in three days. I had a short, so I split it >>> with him." >>> -- Slashdot signature >>> >>> >>> >>> _______________________________________________ >> Openocd-development mailing list >> Openocd-development@lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/openocd-development >> > > -- > Rick Altherr > kc8...@kc8apf.net > > "He said he hadn't had a byte in three days. I had a short, so I split it > with him." > -- Unsigned > > > >
_______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
