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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED] >
wrote:

On Thu, Nov 6, 2008 at 2:17 PM, Federico Spadini <[EMAIL PROTECTED]>
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
[EMAIL PROTECTED]

"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
[EMAIL PROTECTED]

"He said he hadn't had a byte in three days. I had a short, so I split it with him."
 -- Unsigned



Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Reply via email to