[3.8.1] [OpenMandriva] llvm armv7hnl bug malloc(): memory corruption: 0x01bd6eb8

[Quuxplusone]

Bugzilla Link	PR28147
Status	CONFIRMED
Importance	P normal
Reported by	Alexander Stefanov (nobodydead@gmail.com)
Reported on	2016-06-15 16:10:27 -0700
Last modified on	2016-06-21 06:33:55 -0700
Version	3.8
Hardware	Other Linux
CC	bero@lindev.ch, diana.picus@linaro.org, llvm-bugs@lists.llvm.org, rengolin@gmail.com
Fixed by commit(s)
Attachments	extent-tree-79ed0f.c (977501 bytes, text/x-csrc) extent-tree-79ed0f.sh (3062 bytes, application/x-shellscript) 28147.zip (193027 bytes, application/zip) 28147-objects.zip (345309 bytes, application/zip)
Blocks
Blocked by
See also

Created attachment 16551
/tmp/extent-tree-79ed0f.c

Full log
https://gist.github.com/fedya/950977b3b98db52bccd5d3532b0ced60

System: Wandboard ARMv7 (armv7hl with neon)
Hardware: Freescale i.MX6 Quad/DualLite (Device Tree)
Kernel: Linux b22b71aa08bd 4.5.2-server-11omv #1 SMP Sun May 1 03:00:41 UTC
2016 armv7l armv7l armv7l GNU/Linux

LLVM version
llvm-3.8.0-5.272115.1-omv2015.0.armv7hl , where 5.272115.1 is svn revision
https://github.com/OpenMandrivaAssociation/llvm/commit/f2ce4a2926a11fc6d8b335588c3afd3e30d99d73

InstalledDir: /usr/bin
clang-3.8: note: diagnostic msg: PLEASE submit a bug report to
http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and
associated run script.
clang-3.8: note: diagnostic msg:
********************

PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang-3.8: note: diagnostic msg: /tmp/radix-tree-32a672.c
clang-3.8: note: diagnostic msg: /tmp/radix-tree-32a672.sh
clang-3.8: note: diagnostic msg:

********************

[Quuxplusone]

Attached extent-tree-79ed0f.c (977501 bytes, text/x-csrc): /tmp/extent-tree-79ed0f.c

[Quuxplusone]

Attached extent-tree-79ed0f.sh (3062 bytes, application/x-shellscript): /tmp/extent-tree-79ed0f.sh

[Quuxplusone]

latest good snapshot for ARM is libllvm3.8-3.8.0-0.259247.1-omv2015.0.armv7hl.rpm

[Quuxplusone]

FWIW 272115 is the revision that was tagged as 3.8.1-rc1

[Quuxplusone]

Bero,

I cannot reproduce the error.

I've used both upstream 3.8.0 and current RC1 on the pre-processed file you
sent with the exact command line and it still produces the bit-code files
correctly.

Is it possible that this is an additional patch you guys have on top of 3.7.1?
Or maybe the tools/libraries you guys are using?

Here's mine:

Ubuntu 14.04.2 LTS, Linux 3.8.11
cc version 4.8.2 (Ubuntu/Linaro 4.8.2-19ubuntu1)
GNU ld (GNU Binutils for Ubuntu) 2.24
Ubuntu EGLIBC 2.19-0ubuntu6.6
GLIBCXX_3.4.19

[Quuxplusone]

Attached 28147.zip (193027 bytes, application/zip): Script for both 3.8.0 and 3.8.1-RC1

[Quuxplusone]

Attached 28147-objects.zip (345309 bytes, application/zip): 3.8.0 and 3.8.1-RC1 object files

[Quuxplusone]

odd, we aren't applying any relevant patches on top of 3.8.1 (just the patches
I sent you some time back, essentially soname versioning, assuming hardfloat if
neither soft nor hard is given, detecting a couple more triplets).

I wonder if clang/llvm itself was miscompiled by the older compiler.

Libraries here are quite a bit newer, glibc might also be a possible culprit.

OpenMandriva 3.0-beta2, Linux 4.5.2
cc = clang 3.8.1-rc1 (was an older post-3.8.0 release_38 snapshot before)
gcc = Linaro gcc 5.4-2016.06
ld = binutils 2.26 (with gold as default ld)
glibc = 2.23
GLIBCXX_3.4.21

Alexander: I notice the initial bug report says it crashes in radix-tree, but
the attached files for reproducing are from extent-tree -- do both files show
identical behavior for you?

[Quuxplusone]

(In reply to comment #7)
> odd, we aren't applying any relevant patches on top of 3.8.1 (just the
> patches I sent you some time back, essentially soname versioning, assuming
> hardfloat if neither soft nor hard is given, detecting a couple more
> triplets).

That shouldn't make any difference, I agree.

> I wonder if clang/llvm itself was miscompiled by the older compiler.

Both Clang releases (from llvm.org/release) are Phase3, so compiled by itself
twice and compared. The GCC is only used in Phase1, so shouldn't matter much.

> Libraries here are quite a bit newer, glibc might also be a possible culprit.

I agree. I take it you didn't move to GCC ABI 5, right?

> OpenMandriva 3.0-beta2, Linux 4.5.2
> cc = clang 3.8.1-rc1 (was an older post-3.8.0 release_38 snapshot before)
> gcc = Linaro gcc 5.4-2016.06
> ld = binutils 2.26 (with gold as default ld)
> glibc = 2.23
> GLIBCXX_3.4.21

These are considerably newer, and a possible problem for me, as I want to
release 3.9.0 with the new Ubuntu LTS 16.04. I better start testing now...

I'll move it down from "release blocker" to "normal", since I can't reproduce
on the "official" environment, but I need to get to the bottom of this before
3.9.0, at least if it affects Ubuntu 16.04 or Debian Jessie, too.

[Quuxplusone]

Just repeated the process on my x86_64 running Arch Linux, no luck reproducing
it with either 3.8.0 or 3.8.1 built locally.

gcc version 6.1.1 20160602 (GCC)
GNU ld (GNU Binutils) 2.26.0.20160501
ldd (GNU libc) 2.23
GLIBCXX_3.4.22

[Quuxplusone]

Bero, can you reproduce it with a vanilla LLVM, built from source without patches, on OpenMandriva? Or another system?

[Quuxplusone]

How to reproduce:
1. you need ARM board, e.g. wandboard, sabreboard or any other

2. download chroot http://file-
store.openmandriva.org/download/d31082d59586e74cf2ee53124a137e923a32fe73

3. unpack it tar tar -xvf rootfs.tar.bz2

4. mount /dev./dev/pts/,/dev/shm,/proc on rootfs/proc,dev, etc

5. chroot rootfs

6. cd /home/omv/htop/

7. abb build

8. reproduced

[Quuxplusone]

Hi Alexander,

Reproducing it in OpenMandriva is not enough. There could be millions of things
influencing it other than the toolchain. We need to reproduce the bug upstream,
otherwise will be impossible to know what's wrong.

I have not been able to reproduce the bug on an ARM board (A15, essentially the
same) on Ubuntu. That's why I suggested try on OpenMandriva, but *not* using
the system compiler.

So, if you have such a system, clone Clang+LLVM's sources, build it and try to
reproduce it. If you can, then we have a bug in LLVM.

However, it is possible that OpenMandriva is using Compiler-RT or libc++ or
LLVM's libunwind for its base libraries, which could be at play, here. I still
haven't got around testing them more thoroughly, but we do have a buildbot with
basic tests:

http://lab.llvm.org:8011/builders/libcxx-libcxxabi-arm-linux

and a buildbot with a lot of libc++ test failing:

http://buildmaster.tcwglab.linaro.org/builders/clang-cmake-armv7-prototype

(I forgot to update the CMake, it'll fail check-all stage 2 soon).

It could be that, too.