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 <[email protected]>
>>>>>> 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: [email protected] F: 07 3102 9221
_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development
