On Tue, Jan 15, 2013 at 7:33 AM, Valery Zaporozhchenko
<valeryz2001@gmail.com> wrote:
Hello,
faced very strange behaviour of efence on ia64 and need an advice.
After moving from g++-4.3 to 4.4 several first builds of my project
were very unsuccessful, with heap crashes. That persisted for every O2
build while with O1 all was OK. Compiling with -lefence yields very
strange result I've never seen before: it appears that the corruptor
is malloc() itself, in strlen() call. Very subtle changes in the
source code (definitely not related to the problem, if any) removed
the runtime crashes (with O2 option) completely but the behaviour of
efence didn't change: every run of the code compiled with -g -lefence
eventually ends with a heap corruption within the same malloc() call,
regardless of O1/2/3 settings.
Сareful examination of the code supposedly causing the malloc crash
revealed nothing indicative of the error. On ia32/amd64 valgrind says
that all is OK. Nevertheless, I really expect a hidden error in the
algorithm coded rather than a compiler error (and even rather than bug
in efence). I have 3 questions:
- what do people think about efence on ia64? any experiences?
- which kind of data, private to malloc() itself and residing in
memory not guarded by efence I could corrupt before this call to
malloc()?
- very unusual case of stack corruption pretending to be a heap
corruption, if this is possible? I have very limited knowledge of
these things, unfortunately.
The code is a solver for one of the graph-theoretical problems.
Thank you for any advice
Regards
Valery
--
To UNSUBSCRIBE, email to debian-ia64-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: [🔎] CAHcuCGfruU40+qptCuCFCGyHWgFafXibMokWJruzBMYV8D4opw@mail.gmail.com" target="_blank">http://lists.debian.org/[🔎] CAHcuCGfruU40+qptCuCFCGyHWgFafXibMokWJruzBMYV8D4opw@mail.gmail.com