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

[llvmbot]

Bugzilla Link	28147
Version	3.8
OS	Linux
Attachments	[https://user-images.githubusercontent.com/60944935/143753730-3d9b674b-75fa-4572-8e99-58b17ff7be97.gz), [https://user-images.githubusercontent.com/60944935/143753731-295184c4-d043-4d19-80ee-ba7ccc08d4a8.gz)
Reporter	LLVM Bugzilla Contributor
CC	@berolinux,@rovka,@rengolin

Extended Description

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:

---

[rengolin]

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.

[llvmbot]

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

[rengolin]

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

[rengolin]

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

[rengolin]

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.

[berolinux]

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?

[rengolin]

3.8.0 and 3.8.1-RC1 object files

[rengolin]

Script for both 3.8.0 and 3.8.1-RC1

[rengolin]

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

[berolinux]

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

[llvmbot]

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

[llvmbot]

assigned to @rengolin