W dniu 2012-09-28 22:23, Andreas Fritiofson pisze: > That's exactly what I meant. > > In short, the user pointer that was removed was set up to the location > of the working area handle "returned" from the allocation function. On > free, it was set to NULL. In this case this location was the > lpc2000_info->iap_working_area field. So in effect, when the woring > area was freed on reset, the pointer would be NULL the next flashing > and the check would make sure it was reallocated and the algorithm > re-uploaded. > > Of course this could go horribly horribly wrong since the pointer used > to get the handle could just as well be a stack variable so it would > be out of scope when the free would set it to NULL. > > All flash code needs to be checked for this code construct. When I > wrote the allocator, the CFI code had lots of them, if I recall > correctly.
So you suppose that there can be more of these? That's not very good /; Maybe removing of "user" field was not a good idea after all? 4\/3!! ------------------------------------------------------------------------------ Got visibility? Most devs has no idea what their production app looks like. Find out how fast your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219671;13503038;y? http://info.appdynamics.com/FreeJavaPerformanceDownload.html _______________________________________________ OpenOCD-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openocd-devel
