On Mon, May 30, 2011 at 7:10 PM, Drasko DRASKOVIC <drasko.drasko...@gmail.com> wrote: > On Mon, May 30, 2011 at 5:47 PM, Mahr, Stefan <stefan.m...@sphairon.com> > wrote: > >>>> lead to the NULL pointer dereference in the time of jtag data scan >>>> execution (r is a automatic variable, local to the >>>> mips_ejtag_fastdata_scan() function) ? >>> Correction, not NULL pointer, but some trash value pointer from the >>> no longer valid stack. >> >> No, buf_get_u32 fills r[4]. The initial value does not matter. > > No, I meant about r array. this array is a local variable allocated on > a stack. Where is it referenced again ? Outside of this function ? I > do not know very well the OpenOCD architecture, I am afraid that this > reference might be used during jtag data scan execute function and > that at this moment it will not be valid anymore (although I am > obviously wrong, since you confirm that it works and you saw no > sigfaults). >
Drasko is probably right here. This will crash and burn. At least sometimes/somewhere. Getting a segfault or even a consistent failure is not guaranteed. However, a more fundamental problem with this code is that it uses the in_field before the jtag queue is likely to have been executed. Most of the times it would just set *data to whatever garbage that was on the stack where r[] got allocated. The correct way to handle host/target endianness swapping without forcing a queue execution is to add a callback to the queue. See for example adi_jtag_dp_scan_u32() in adi_v5_jtag.c. Regards, Andreas _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
