|
From: Keith R. <Kei...@nt...> - 2007-01-25 08:00:01
|
An issue I see running libgoto-linked applications under valgrind is there are many invalid reads of 8 bytes immediately preceding or following a malloced block. I guess that this arises from attepting to prefetch data before correct loop execution limits are tested. Does this constitute an error in libgoto or is this allowable practice? I'm assuming the values fetched are not actually used as the code executes successfully. (http://www.tacc.utexas.edu/~kgoto/) Keith Refson |
|
From: Julian S. <js...@ac...> - 2007-01-25 09:52:12
|
On Thursday 25 January 2007 07:58, Keith Refson wrote: > An issue I see running libgoto-linked applications under valgrind > is there are many invalid reads of 8 bytes immediately preceding or > following a malloced block. I guess that this arises from attepting > to prefetch data before correct loop execution limits are tested. Does > this constitute an error in libgoto or is this allowable practice? It's marginal. As specified by ANSI/ISO C (and probably C++), any program which accesses outside allocated blocks is deemed, in essence, incorrect. (it is deemed to have unspecified behaviour following the first such access). It is however possible to write highly optimised libraries like libgoto in such a way that they work correctly and yet access outside blocks in this way (for performance reasons). It may be a bug in libgoto (in which case you might consider reporting it) or it may be a known consequence of the handed-coded, tuned assembly. It is hard to know. Can you send some examples of the errors you are seeing? J |