Trac November 2024

trac@lists.einsteintoolkit.org

1 participants
106 discussions

#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

#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): I don’t know. It might be that the compiler doesn’t know that we’re constructing a vector of size 3 and is worried that there might be uninitialized entries if we construct a larger vector. If you want to apply the change, can you rename the new variable? Variable names starting with an underscore and then an upper case letter shouldn’t be used by an application. I usually append a `1` at the end instead. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2818/failing-tests-wit…

1 0

#2831: ExternalLibraries/MPI creates MPI_INC_DIRS that have double quotes in their value
by Roland Haas 03 Nov '24

03 Nov '24

#2831: ExternalLibraries/MPI creates MPI_INC_DIRS that have double quotes in their value Reporter: Roland Haas Status: new Milestone: Version: Type: bug Priority: minor Component: EinsteinToolkit thorn ExternalLibraries/MPI’s `detect.pl` script creates entries in `make.MPI.defn` like this \(on stampede3\): ``` MPI_DIR = /opt/intel/oneapi/mpi/2021.11 MPI_INC_DIRS = "/opt/intel/oneapi/mpi/2021.11/include" MPI_LIB_DIRS = "/opt/intel/oneapi/mpi/2021.11/lib" MPI_LIBS = mpicxx mpifort mpi rt pthread dl ``` which is incorrect since make makes the double quotes part of the variables value. This is usually safe when used in the shell since `-L"Foo"` is the same as `-LFoo` but fails with Silo which stores the options in a string \(and does not escape embedded quotes\). Since make does not handle spaces well anyway `detect.pl` should not output any quotes since the paths will never contain one. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2831/externallibraries…

1 0

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

03 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): @{557058:56049c54-f8c2-4b6c-9b88-ab697c967495} do you have any idea if this a bug in gcc-14 and I am just perturbing it out of existence or if there really is something wrong with constructing a temporary `vect<bool, bim>` in place when calling `point_desc`? -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2818/failing-tests-wit…

1 0

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

03 Nov '24

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

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac November 2024