[erlang-bugs] R14B01: buffer overflow detected during compilation with -D_FORTIFY_SOURCE=2 (x86_64)

[Kenneth Lundin]

Hi,

Some questions

Has -D_FORTIFY_SOURCE been tried on R14B as well and did not show any
buffer overflow?
I am asking because we are running Valgrind extensively before every
release and shouldn't
buffer overflows be detected there as well?

As I understand it -D_FORTIFY_SOURCE is a patch to GCC developed by Redhat and
=2 can also report buffer flow for code that is correct.

If this buffer overflow indeed is a real bug then of course we want to
find it and correct it.

/Kenneth Erlang/OTP Ericsson

On Tue, Dec 14, 2010 at 11:57 AM, Nico Kruber <kruber@REDACTED> wrote:
> Most distributions nowadays adds the -D_FORTIFY_SOURCE=2 flag during package compilation. I tried updating my erlang package (openSUSE 11.3, x86_64) from R14B to R14B01 and received the following error (also see the attached build.log.fortsource2 - compressed due to its file size):
>
> *** buffer overflow detected ***: /usr/src/packages/BUILD/otp_src_R14B01/bin/x86_64-unknown-linux-gnu/beam.smp terminated
> ======= Backtrace: =========
> /lib64/libc.so.6(__fortify_fail+0x37)[0x2b64930b0067]
> /lib64/libc.so.6(+0xe4e10)[0x2b64930ade10]
> /usr/src/packages/BUILD/otp_src_R14B01/bin/x86_64-unknown-linux-gnu/beam.smp[0x584047]
> /usr/src/packages/BUILD/otp_src_R14B01/bin/x86_64-unknown-linux-gnu/beam.smp(erts_write_to_port+0x97f)[0x4946ef]
> /usr/src/packages/BUILD/otp_src_R14B01/bin/x86_64-unknown-linux-gnu/beam.smp[0x50fcb9]
> /usr/src/packages/BUILD/otp_src_R14B01/bin/x86_64-unknown-linux-gnu/beam.smp(process_main+0x2eba)[0x53b36a]
> /usr/src/packages/BUILD/otp_src_R14B01/bin/x86_64-unknown-linux-gnu/beam.smp[0x4a1772]
> /usr/src/packages/BUILD/otp_src_R14B01/bin/x86_64-unknown-linux-gnu/beam.smp[0x5aee94]
> /lib64/libpthread.so.0(+0x6a4f)[0x2b6492ba8a4f]
> /lib64/libc.so.6(clone+0x6d)[0x2b649309982d]
>
>
> Setting  -D_FORTIFY_SOURCE=1 allows erlang to be build but the buffer overflow is probably still there and dangerous...
> R14B did not show this behaviour.
>
> Additionally, could you correct the dependencies in the makefiles in order to allow make -j2 and higher?
>
>
> Regards
> Nico Kruber
>