Possible memory corruption in cling #15511
Assignees
Labels
affects:master
affects:6.28
affects:6.30
affects:6.32
bug
experiment
Affects an experiment / reported by its software & computimng experts
in:Cling
priority:high
Comments
hahnjo
added
the
experiment
|
A stripped down version of the header that segfaults: |
|
I met a similar situation here. I am using LCG_103. |
|
Can you run valgrind using the root suppression file? |
Hi, here is the result. Do note that I do not know valgrind very well. I ran this: The result looks like this: |
|
I am surprised that valgrind is happy… |
|
There's problem in the way the application was invoked: there a stray |
|
I tried to run Valgrind, but it only spots one small leak, despite the segfault. But that made me look a bit better at the stack trace and I noticed the line I also tried to put the line Tomorrow I'll investigate this new path, as it might be that the segfault is a red herring (hiding the actual problem in my code). |
|
The file The error seems weird because I see |
|
Yes I noticed that as well. I switched to 1533 and got the same seg fault.
Thank you for the note. I will try it again later!
|
|
I have a small update, but no good news. When trying to reproduce the segfault with a I prepared small "reproducer" that should work on any RHEL9 equivalent machine with CVMFS and the HEP_OSlibs meta-rpm. |
|
Output of (note that I ran it directly on With @pikacic if |
|
Let me have a look. |
|
Okay, never mind, this is a Cling issue: If there are more than 16 extern "C" int printf(const char*, ...);
struct A {
int val;
A(int v) : val(v) {
printf("A(%d), this = %p\n", val, this);
}
~A() {
printf("~A(%d), this = %p\n", val, this);
}
};
const A a1(1);
const A a2(2);
const A a3(3);
const A a4(4);
const A a5(5);
const A a6(6);
const A a7(7);
const A a8(8);
const A a9(9);
const A a10(10);
const A a11(11);
const A a12(12);
const A a13(13);
const A a14(14);
const A a15(15);
const A a16(16);
const A a17(17);This should print from 1 to 17, but for example (at least destruction order is consistent) For the LHCb headers, this causes problems because some constructor calls reference other global This seems to be caused by #13614, which was meant to fix #13429, and therefore affects v6.28/08, where it was backported, and later versions (all v6.30, v6.32, |
It turns out there should be a |
|
Awesome! Thanks for the detailed analysis and a fix! |
hahnjo
added a commit
to hahnjo/root
that referenced
this issue
Jun 14, 2024
Constructors with the same priority should keep their relative order
that was specified. This is important for clang-repl with many const
variables after commit 05137ecfca ("[clang-repl] Emit const variables
only once").
---
Fixes root-project#15511
|
Thanks a lot! |
hahnjo
added a commit
that referenced
this issue
Jun 14, 2024
Constructors with the same priority should keep their relative order
that was specified. This is important for clang-repl with many const
variables after commit 05137ecfca ("[clang-repl] Emit const variables
only once").
---
Fixes #15511
hahnjo
added a commit
to hahnjo/root
that referenced
this issue
Jun 14, 2024
Constructors with the same priority should keep their relative order
that was specified. This is important for clang-repl with many const
variables after commit 05137ecfca ("[clang-repl] Emit const variables
only once").
---
Fixes root-project#15511
(cherry picked from commit a60f353)
hahnjo
added a commit
to hahnjo/root
that referenced
this issue
Jun 14, 2024
Constructors with the same priority should keep their relative order
that was specified. This is important for clang-repl with many const
variables after commit 05137ecfca ("[clang-repl] Emit const variables
only once").
---
Fixes root-project#15511
(version of commit a60f353 for
LLVM 13 in v6-30-00-patches)
hahnjo
added a commit
to hahnjo/root
that referenced
this issue
Jun 14, 2024
Constructors with the same priority should keep their relative order
that was specified. This is important for clang-repl with many const
variables after commit 05137ecfca ("[clang-repl] Emit const variables
only once").
---
Fixes root-project#15511
(version of commit a60f353 for
LLVM 13 in v6-28-00-patches)
|
As requested by LHCb, a release for the 6.30 branch including the fix was provided today: https://root-forum.cern.ch/t/root-6-30-08-is-out |
silverweed
pushed a commit
to silverweed/root
that referenced
this issue
Aug 19, 2024
Constructors with the same priority should keep their relative order
that was specified. This is important for clang-repl with many const
variables after commit 05137ecfca ("[clang-repl] Emit const variables
only once").
---
Fixes root-project#15511
hahnjo
added a commit
to hahnjo/root
that referenced
this issue
Sep 13, 2024
hahnjo
added a commit
to hahnjo/root
that referenced
this issue
Sep 13, 2024
hahnjo
added a commit
to hahnjo/root
that referenced
this issue
Sep 18, 2024
(cherry picked from commit 67ff470)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Check duplicate issues.
Description
Since the switch to ROOT 6.30/02 (LCG 105) we started to experience segfaults related to dictionaries. The most straightforward reproducer is just a
#includeof a specific headerWhat makes me think that there may be a memory corruption is that I tried to isolate which part of that header was triggering the segfault and I noticed that (on a subset of the header) I could make the segfault appear and disappear just shuffling some class definitions.
I also find weird that the segfault seems to be related to an
atexitfunction inlibCling.so:Reproducer
With the
test_env.shincluded in test_env.zip on lxplus.cern.ch:ROOT version
Installation method
LCG builds
Operating system
Linux (EL9)
Additional context
No response
The text was updated successfully, but these errors were encountered: