Trac

trac@lists.einsteintoolkit.org

8708 discussions

#2833: Null pointer dereference in AEILocalInterp
by Roland Haas 05 Nov '24

05 Nov '24

#2833: Null pointer dereference in AEILocalInterp Reporter: Erik Schnetter Status: open Milestone: Version: Type: bug Priority: major Component: EinsteinToolkit thorn Changes (by Roland Haas): status: open (was new) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2833/null-pointer-dere…

1 0

#2833: Null pointer dereference in AEILocalInterp
by Roland Haas 05 Nov '24

05 Nov '24

#2833: Null pointer dereference in AEILocalInterp Reporter: Erik Schnetter Status: new Milestone: Version: Type: bug Priority: major Component: EinsteinToolkit thorn Comment (by Roland Haas): Any chance to redo the change to match AHFinderDirect’s style as outlined in [https://bitbucket.org/einsteintoolkit/einsteinanalysis/src/master/AHFinderD… ? If not I’ll give that a try myself. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2833/null-pointer-dere…

1 0

#2833: Null pointer dereference in AEILocalInterp
by Roland Haas 05 Nov '24

05 Nov '24

#2833: Null pointer dereference in AEILocalInterp Reporter: Erik Schnetter Status: new Milestone: Version: Type: bug Priority: major Component: EinsteinToolkit thorn Changes (by Roland Haas): responsible: [] (was ) priority: major (was critical) assignee: Roland Haas (was ) Comment (by Roland Haas): reduce severity to “major” since “critical” is “At least one important thorn cannot be used, or something else is severely broken. If this is not addressed quickly, the respective change should be reverted.“ \([https://docs.einsteintoolkit.org/et-docs/Tickets#Priority](https://docs.einsteintoolkit.org/et-docs/Tickets#Priority)\) which does not seem to be the case here given that AFinderDirect’s test suites pass. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2833/null-pointer-dere…

1 0

#2833: Null pointer dereference in AEILocalInterp
by Roland Haas 05 Nov '24

05 Nov '24

#2833: Null pointer dereference in AEILocalInterp Reporter: Erik Schnetter Status: new Milestone: Version: Type: bug Priority: critical Component: EinsteinToolkit thorn Comment (by Roland Haas): Non-matching code style but the change itself seems fine. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2833/null-pointer-dere…

1 0

#2832: possible race condition in LoopControl
by Roland Haas 05 Nov '24

05 Nov '24

#2832: possible race condition in LoopControl Reporter: Roland Haas Status: new Milestone: Version: Type: bug Priority: major Component: Comment (by Roland Haas): The issue may be alignment related. gcc-14 produces a warning: ``` COMPILING Carpet/LoopControl/src/loopcontrol.cc /data/rhaas/postdoc/gr/cactus/ET_trunk/configs/yosef/build/LoopControl/loopcontrol.cc: In function ?voi LC_control_init(lc_control_t*, lc_descr_t*, ptrdiff_t, ptrdiff_t, ptrdiff_t, ptrdiff_t, ptrdiff_t, ptrdiff_t, ptrdiff_t, ptrdiff_t, ptrdiff_t, ptrdiff_t, ptrdiff_t, ptrdiff_t)?: /data/rhaas/postdoc/gr/cactus/ET_trunk/configs/yosef/build/LoopControl/loopcontrol.cc:797:29: warning: new? of type ?lc_thread_info_t? with extended alignment 128 [-Waligned-new=] 797 | { thread_info_ptr = new lc_thread_info_t; } | ^~~~~~~~~~~~~~~~ /data/rhaas/postdoc/gr/cactus/ET_trunk/configs/yosef/build/LoopControl/loopcontrol.cc:797:29: note: uses ?void* operator new(std::size_t)?, which does not have an alignment parameter /data/rhaas/postdoc/gr/cactus/ET_trunk/configs/yosef/build/LoopControl/loopcontrol.cc:797:29: note: use ?-faligned-new? to enable C++17 over-aligned new support ``` and changing LoopControl like this: ```diff diff --git a/LoopControl/src/loopcontrol.cc b/LoopControl/src/loopcontrol.cc index a2e3460f2..062db9c1f 100644 --- a/LoopControl/src/loopcontrol.cc +++ b/LoopControl/src/loopcontrol.cc @@ -71,12 +71,16 @@ static minstd_rand::result_type const constexpr lc_random_range = struct lc_thread_info_t { volatile int idx; // linear index of next coarse thread block -} CCTK_ATTRIBUTE_ALIGNED(128); // align to prevent sharing cache lines + char pad[128 - sizeof(int)]; // align to prevent sharing cache lines +}; +static_assert(sizeof(lc_thread_info_t) == 128, "Incorrect size for alignment"); struct lc_fine_thread_comm_t { volatile int state; // waiting threads volatile int value; // broadcast value -} CCTK_ATTRIBUTE_ALIGNED(128); // align to prevent sharing cache lines + char pad[128-2*sizeof(int)]; // align to prevent sharing cache lines +}; +static_assert(sizeof(lc_fine_thread_comm_t) == 128, "Incorrect size for alignment"); // One object per coarse thread: shared between fine threads // Note: Since we use a vector, the individual elements may not ``` makes the issue go away. Note that this may not actually give alignment to 128 bytes as originally requested. However the comments make it clear that alignment was never the goal, instead the goal was to spread out consecutive `lc_fine_thread_comm_t` across multiple cache lines, which making them big enough should also achieve. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2832/possible-race-con…

1 0

#2833: Null pointer dereference in AEILocalInterp
by Erik Schnetter 05 Nov '24

05 Nov '24

#2833: Null pointer dereference in AEILocalInterp Reporter: Erik Schnetter Status: new Milestone: Version: Type: bug Priority: critical Component: EinsteinToolkit thorn See the correction at [https://bitbucket.org/cactuscode/numerical/pull-requests/1](https://bitbuck… . This bug is triggered by AHFinderDirect. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2833/null-pointer-dere…

1 0

#2832: possible race condition in LoopControl
by Roland Haas 05 Nov '24

05 Nov '24

#2832: possible race condition in LoopControl Reporter: Roland Haas Status: new Milestone: Version: Type: bug Priority: major Component: @{557058:d079f9c2-ad27-47b2-bf4b-ecc6bbe288b0} reported an issue where SEGFAULTs are triggered from within LoopControl. I can reproduce this using the thornlist and parameter file that Yosef provided. I use the attached option list, where using `-std=gnu++11` instead of `-std=c++17 -D_GNU_SOURCE` is required for the issue to show up for me. I run using ``` export OMP_NUM_THREADS=2 exe/cactus_yosef test.par ``` and the CPU on my workstation is a “12th Gen Intel\(R\) Core\(TM\) i7-12700” attachment: OptionList (https://api.bitbucket.org/2.0/repositories/einsteintoolkit/tickets/issues/2…) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2832/possible-race-con…

1 0

#2818: failing tests with gcc-14
by Roland Haas 04 Nov '24

04 Nov '24

#2818: failing tests with gcc-14 Reporter: Roland Haas Status: new Milestone: Version: Type: bug Priority: major Component: EinsteinToolkit thorn Comment (by Roland Haas): will do. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2818/failing-tests-wit…

1 0

#2818: failing tests with gcc-14
by Erik Schnetter 04 Nov '24

04 Nov '24

#2818: failing tests with gcc-14 Reporter: Roland Haas Status: new Milestone: Version: Type: bug Priority: major Component: EinsteinToolkit thorn Comment (by Erik Schnetter): `vect` objects are created via this mechanism \(see \`vect.hxx1\): ```c++ template <typename T, std::size_t N, typename F> constexpr ARITH_INLINE ARITH_DEVICE ARITH_HOST std::array<T, N> construct_array(const F &f) { if constexpr (N == 0) return std::array<T, N>(); if constexpr (N > 0) return array_push<T>(construct_array<T, N - 1>(f), f(N - 1)); } ``` Maybe the compiler is getting confused by the `constexpr` expressions and accidentally evaluates the second `if` statement? That’s the only `- 1` that I see. If so, you could try splitting the function into two, with an `enable_if` condition checking `N==0` and `N>0`, and removing the `if constexpr` statements from the bodies. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2818/failing-tests-wit…

1 0

#2818: failing tests with gcc-14
by Roland Haas 04 Nov '24

04 Nov '24

#2818: failing tests with gcc-14 Reporter: Roland Haas Status: new Milestone: Version: Type: bug Priority: major Component: EinsteinToolkit thorn Comment (by Roland Haas): Yes, I will rename the variable. Yes, `_FOO` is reserved by compiler / standard library I think. The thing that has me worried is that with the change in the diff the tests all pass with gcc-14 \(well other than ones that are failing for reasons such as schedule issues or hwloc not liking my efficiency cores in my workstation\) but without the change many tests in CarpetX fail. All the failing CarpetX tests also pass if I compile with gcc-13 instead of gcc-14. gcc-14 produces some other warnings \(like reporting that index -1 is out of bounds for a `double foo[3]` vector, which is true\) but I have a harder time finding out exactly what line triggers it. So this seems like I am just perturbing something out of existence. I’ll propose a the change in a pull request. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2818/failing-tests-wit…

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac