Hi David,
I've tried a different x86_64 system with Ubuntu 11.10 and gcc 4.6.1, and the buffer overflow also occurs there (but only without --enable-debug), so I don't think gcc is to blame. Nevertheless, thanks for your efforts.
Regards, Andreas
Hi Andreas, Thanks for trying that. I've tried again but I still can't reproduce it. I did find a problem with the hardening option to produce a position-independent executable but that caused a segfault during start-up.
I was really concerned in case there was a sprintf that was writing beyond its buffer and, of course, it's possible there is. It may also be a false positive which has been fixed in a later version of GCC. For the moment I'm inclined to leave it especially as you've found a work-around. I'd be interested if anyone else has this problem.
Regards, David
On 15/11/2011 07:24, Andreas Lochbihler wrote:
Hi David,
when I add the --enable-debug to ./configure, the buffer overflow error disappears. ./configure --disable-shared leads to the same buffer overflow, but no more details. Is there anything else I could try?
Best regards, Andreas
Am 14.11.2011 18:05, schrieb David Matthews:
I've attempted to reproduce this without success. I'm running Ubuntu 11.10 and had to install the hardening packages manually do there may be some difference. I can't tell much from the backtrace because the function names within the poly library aren't being shown. Could you try rebuilding poly with ./configure --enable-debug --disable-shared That might provide some more useful information.
Regards, David
On 11/11/2011 12:03, Andreas Lochbihler wrote:
Hi,
I tried to build Isabelle 2011-1 with the repository version 1352 of PolyML on Ubuntu 10.04 and x86_64. g++ seems to include its fortify checks automatically in the compiled code. When I build Isabelle's Pure session, it detects a buffer overrun and aborts PolyML. Is this a bug in PolyML? Or does PolyML not work with Fortify? Or is it just a misconfiguration on my side? If I disable fortify with -D_FORTIFY_SOURCE=0 when compiling PolyML, everything works fine again.
At the end of this mail, I have included the stack trace and memory map for the buffer overflow.
Best regards, Andreas