Set up ability to use RADSAN_OPTIONS, move RADSAN_ERROR_MODE to this new variable as a test #13

cjappl · 2023-12-21T15:29:16Z

Prior art

The design of this code review is heavily based on the design of msan. I highly recommend checking out the following files for the context I was working with.

Setting up the "init" function:

llvm-project/compiler-rt/lib/msan/msan.cpp

Line 147 in a902ca6

static void InitializeFlags() {

Flags definition files:
https://github.com/realtime-sanitizer/llvm-project/blob/main/compiler-rt/lib/msan/msan_flags.h
https://github.com/realtime-sanitizer/llvm-project/blob/main/compiler-rt/lib/msan/msan_flags.inc

Use of the "ENSURE" macro:

llvm-project/compiler-rt/lib/msan/msan_interceptors.cpp

Line 127 in a902ca6

ENSURE_MSAN_INITED();

Summary

All of the other sanitizers have a environment variable they respect. This variable is "$SANNAME_OPTIONS" e.g. TSAN_OPTIONS, MSAN_OPTIONS etc.

These variables have any and all configuration in a space/= separated list, e.g.

$ TSAN_OPTIONS="history_size=7 force_seq_cst_atomics=1" ./myprogram

To easily replicate the "suppression list" feature, we can copy this prior art. This also allows us a few additional things "for free". A couple examples you will see in this review

Configuring the error code with RADSAN_OPTIONS="exitcode=27"
Getting help docs automagically RADSAN_OPTIONS="help=true"

What to look for

Please help me check

Do the functions all live in the right files? Are we OK with the organization?
Do we like how the exit/continue/interactive is right now? A few other sanitizers have a binary halt_on_error or continue_on_error that we could copy, but we would lose the "Interactive mode"

cjappl · 2023-12-21T15:29:48Z

compiler-rt/lib/radsan/radsan.cpp

+  }
+}
+
+void radsan_init() {


Everything in this file HEAVILY copied from msan. check out msan.cpp for the source

cjappl · 2023-12-21T15:30:12Z

compiler-rt/lib/radsan/radsan.cpp

+    cf.stack_trace_format = "DEFAULT";
+    cf.external_symbolizer_path = GetEnv("RADSAN_SYMBOLIZER_PATH");
+    OverrideCommonFlags(cf);
+  }


This information previously in another file can now be initialized only the once, cool!

cjappl · 2023-12-21T15:30:41Z

compiler-rt/lib/radsan/radsan.cpp

 }

-RADSAN_EXPORT void radsan_on() {
+SANITIZER_INTERFACE_ATTRIBUTE void radsan_on() {


This is a standard way to do what we were doing with RADSAN_EXPORT before, switched it to match the style

cjappl · 2023-12-21T15:31:16Z

compiler-rt/lib/radsan/radsan.h

+  } \
+} while (0)
+
+// TODO: are these data races?? Things may be initialized in multiple threads


Eyes here, I think there is a big possibility these bools could be data races. msan doesn't have them as atomics, but I am suspicious 🤔

I opted to change these to static and atomic for safety reasons. I don't think msan is doing it right..

Interesting - I'm not sure. What's your thinking?

cjappl · 2023-12-21T15:31:43Z

compiler-rt/lib/radsan/radsan_context.cpp

    printDiagnostics(intercepted_function_name);
    if (get_error_action_() == OnErrorAction::ExitWithFailure) {
-      exit(EXIT_FAILURE);
+      exit(common_flags()->exitcode);


Cool! Configurable exitcode for free, just like the other sanitizers

I agree this is cool... but let's make sure we have a compelling use case for it before we take on the maintenance 👍

Makes sense! Happy to talk more about this on our eventual call

cjappl · 2023-12-21T15:32:24Z

compiler-rt/lib/radsan/radsan_context.cpp

          "`%s` in real-time context! Stack trace:\n",
          intercepted_function_name);
+
+  atomic_fetch_add(&radsan::radsan_report_count, 1, memory_order_relaxed);


The base of the "exit non-zero in continue mode". This is what msan does.

In a future review, we then hook into the exit call and check this number.

cjappl · 2023-12-21T15:32:48Z

compiler-rt/lib/radsan/radsan_flags.inc

+// RADSAN_FLAG(Type, Name, DefaultValue, Description)
+// See COMMON_FLAG in sanitizer_flags.inc for more details.
+
+RADSAN_FLAG(const char*, error_mode, "exit", "Error mode: [continue|interactive|exit].")


Super easy to define new flags in this format, very impressed with the infrastructure around this.

cjappl · 2023-12-21T15:33:11Z

compiler-rt/lib/radsan/radsan_user_interface.cpp

-  if (user_mode == nullptr) {
-    return exit_getter;
-  }
+  const char* user_mode = radsan::flags()->error_mode;


Another new use of this system with our custom flag

Yeah this is nice!

cjappl · 2023-12-21T15:33:32Z

compiler-rt/test/radsan/TestCases/test_continue_mode.cpp

@@ -1,11 +1,11 @@
 // RUN: %clangxx -fsanitize=realtime %s -o %t
-// RUN: env RADSAN_ERROR_MODE=continue %run %t 2>&1 | FileCheck %s
+// RUN: env RADSAN_OPTIONS="error_mode=continue" %run %t 2>&1 | FileCheck %s


Test updated to confirm we are using the new way of doing things.

davidtrevelyan · 2023-12-22T10:55:23Z

compiler-rt/lib/radsan/radsan.cpp

+using namespace __sanitizer;
+
+namespace radsan {
+static __sanitizer::atomic_uint8_t radsan_inited{};


Why do we need to use the __sanitizer atomic types here rather than just std::atomic?

Good question. I think it is possibly so these can run on systems that don't have standard libraries.

This hunch (and it's 100% a hunch, could be misinformed) was based on something I saw in MSAN, and is also in tsan and hwasan

compiler-rt/lib/hwasan/hwasan.cpp 37:// ACHTUNG! No system header includes in this file. compiler-rt/lib/tsan/rtl/tsan_rtl.h 19:// - No system headers included in header files (*). compiler-rt/lib/msan/msan.cpp 34:// ACHTUNG! No system header includes in this file.

After fussing with this a bit, there are very easy ways for you to segfault in these sanitizers. These internal types are defined to not use any system calls that may or may not invoke an intercepted function.

For instance, I was trying to make a Meyer's singleton of a big type. Because it was statically initialized, and was large enough, the compiler attempted to put a pthread_mutex_lock around the call. This happened in such a way that we were in a recursive loop (intercepting the lock, trying to initialize the member with a lock, intercepting the lock) and it segfaulted.

It seems as if you stay in the __sanitizer special types, it prevents you from shooting yourself in the foot.

davidtrevelyan · 2023-12-22T10:56:23Z

compiler-rt/lib/radsan/radsan.cpp

+
+Flags *flags() { return &radsan_flags; }
+
+void EnsureInitialized() {


Naive question: why do we need this function at all if we know that radsan_init is called in the .preinit stage?

naive answer: So I don't know anything about .preinit, and never encountered it before this project.

When I was sleuthing a bit, it seems as if this is only a linux thing:

https://github.com/llvm/llvm-project/blob/04c473bea3e0f135432698fcaafab52e1fe1b5ec/compiler-rt/lib/sanitizer_common/sanitizer_internal_defs.h#L95-L113

So in non-linux systems, there needs to be something that will initialize this functionality

Much to my surprise, on OSX you can completely remove the call to initialiseInterceptors and the entire (original) radsan_init and things work fine! That call (in the original version of the code, in the radsan branch right now) is never called on mac.

So to clean up my answer from this now that I'm older and wiser: The initialiseInterceptors call does not need to be called on mac. It DOES need to be called on linux, and is taken care of in the .preinit array.

However, now we are doing a lot more in this function, making sure our flags() are set up, etc. To facilitate this, we need to ensure radsan is initialized before we use anything that needs it. Thus we have this complicated scheme that ensures it, and doesn't blow up if there is a data race.

davidtrevelyan · 2023-12-22T11:04:55Z

compiler-rt/lib/radsan/radsan.cpp

+    CommonFlags cf;
+    cf.CopyFrom(*common_flags());
+    cf.stack_trace_format = "DEFAULT";
+    cf.external_symbolizer_path = GetEnv("RADSAN_SYMBOLIZER_PATH");


Shall we move this into RADSAN_OPTIONS as well, for consistency?

Actually, we are in good company here! This one is a different env variable for each of the other sanitizers

> rg "external_symbolizer_path.*_SYMBOLIZER_PATH" compiler-rt/lib/ubsan/ubsan_flags.cpp 53: cf.external_symbolizer_path = GetFlag("UBSAN_SYMBOLIZER_PATH"); compiler-rt/lib/memprof/memprof_flags.cpp 52: cf.external_symbolizer_path = GetEnv("MEMPROF_SYMBOLIZER_PATH"); compiler-rt/lib/asan/asan_flags.cpp 57: cf.external_symbolizer_path = GetEnv("ASAN_SYMBOLIZER_PATH"); compiler-rt/lib/radsan/radsan.cpp 83: cf.external_symbolizer_path = GetEnv("RADSAN_SYMBOLIZER_PATH"); compiler-rt/lib/tsan/rtl/tsan_flags.cpp 60: cf.external_symbolizer_path = GetEnv("TSAN_SYMBOLIZER_PATH"); compiler-rt/lib/msan/msan.cpp 152: cf.external_symbolizer_path = GetEnv("MSAN_SYMBOLIZER_PATH"); compiler-rt/lib/lsan/lsan.cpp 57: cf.external_symbolizer_path = GetEnv("LSAN_SYMBOLIZER_PATH"); compiler-rt/lib/hwasan/hwasan.cpp 78: cf.external_symbolizer_path = GetEnv("HWASAN_SYMBOLIZER_PATH");

davidtrevelyan · 2023-12-22T11:10:18Z

compiler-rt/lib/radsan/radsan.cpp

+Flags *flags() { return &radsan_flags; }
+
+void EnsureInitialized() {
+  CHECK(!radsan::IsInitRunning());


Does this return if init is currently running?

This is an assert basically, it will abort the process if this is happening.

This pattern was borrowed from msan, but I think the idea is: EnsureInitialized with MAKE SURE this thing is initialized before letting you continue. It is up to the caller to behave differently if the initialization is running.

You can see this check for IsInitRunning then the call here:

https://github.com/realtime-sanitizer/llvm-project/pull/13/files#diff-2d332ab3b2cfde868d5292ad94bfb45f304711efa30b0518c922ded7ff02eae7R39-R43

This is helpful for the case where initalization is running in one thread, and you have some interceptor that happens in another thread under conditions in which it would normally intercept. In that case it should just return the REAL functionality

davidtrevelyan · 2023-12-22T11:12:42Z

compiler-rt/lib/radsan/radsan_interceptors.cpp

+  {
+    return;
+  }
+  radsan::EnsureInitialized();


Two questions here:

I don't yet understand why we need EnsureInitialized here - this expectation is only called from within an interceptor, isn't it? Doesn't that mean that IsInitialized() will always return true here?

If EnsureInitialized() checks IsInitRunning inside it, do we need to check it in the line above this one as well?

So there are a few different branches here.

On linux machines, where we load the radsan_init into the .preinit array, this will always return true

On mac machines:

The first thread going through here will initialize radsan

any subsequent threads that have an interception happen during the "IsInitRunning" phase will fail that check above, and not register their interception

After "IsInitRunning" is false, it will always be true.

This situation is a bit complex but I think it scratches all the itches of any corner cases (threads coming in at the same time, without things being initialized). I have to assume this is why msan did this in the first place.

One thing that would simplify all of this massively is: "Is there one single solitary point where we KNOW we will be able to initialize on one thread ONLY?"

To my knowledge, I can't think of anything on all systems (obviously .preinit exists on linux boxes). We have to use the first interception point on the first thread calling a [[clang::realtime]] to set ourselves up.

davidtrevelyan · 2023-12-22T11:14:10Z

compiler-rt/lib/radsan/radsan_preinit.cpp

 // The symbol is called __local_radsan_preinit, because it's not intended to be
 // exported.
 // This code is linked into the main executable when -fsanitize=realtime is in
 // the link flags. It can only use exported interface functions.


Does this definitely still work on the Linux image? The comment here suggests that the function radsan::radsan_init (which no longer has the RADSAN_EXPORT/SANITIZER_INTERFACE_ATTRIBUTE) can't be used - is the comment a mistake, maybe?

Great question. I have not run this on CI, so I'm not sure!

Perfect time to ask this question (and I'll do my own research too).

What is the significance of extern C? What functions should be in a block that has that?

What is the significance of the SANITIZER_INTERFACE_ATTRIBUTE and what functions should have it?

I was blindly pattern matching in radsan.h, and don't have a good mental model of these two things. It would be good for this review to be principled in those decisions as opposed to pattern matching. Wondering if you have any thoughts!

Alright, to put in some of my own discovered answers here (please add on or correct if I'm wrong). I'm typing this out mostly for my own education

Extern C

Free functions in C++ cannot be automatically compiled and used in C++. The main reason for this is that C does NOT support function overloading.

To support function overloading in C++, the compiler adds a bunch of extra information to the name of the function to differentiate them from other overloads. This process is called "name mangling".

For instance, we the programmer may see:

void foo(int x, float y); void foo(bool b);

The compiler/linker will see something else, for example (completely made up)

__fooIntFlo209ca __fooBool29ri04

So, what do we do when we need to use a free function that is in our C++ code base in C? we need to make sure the name does not get mangled. This is where extern "C" comes in.

extern "C" ensures the code inside of it is compiled with the C linkage (instead of the C++ linkage) and ensures no mangling takes place. These functions can be called from either C or C++ with no issues.

The functions we should put in an extern C block are the functions that need to be called from C world.

FIXME IN THIS REVIEW: For example I think our init function MUST BE extern C, as it needs to be loaded into the preinit array.

This comment:

Does this definitely still work on the Linux image? The comment here suggests that the function radsan::radsan_init (which no longer has the RADSAN_EXPORT/SANITIZER_INTERFACE_ATTRIBUTE) can't be used - is the comment a mistake, maybe?

Seems to make sense now, and I would be surprised if this code ran as written on our linux box.

Fixed this in the latest review, all methods called from linux land are linked in the C linkage instead of C++.

davidtrevelyan · 2023-12-22T11:15:50Z

compiler-rt/lib/radsan/radsan_user_interface.cpp

-  if (user_mode == nullptr) {
-    return exit_getter;
-  }
+  CHECK(radsan::IsInitialized());


What happens if it's not initialised here?

Process aborts, as in a failed assertion.

However, if we remove this CHECK the line on 36 aborts because radsan::flags() is nullptr. This just gives a better name to the problem, that we are not initialized so we should be dying here.

davidtrevelyan · 2023-12-22T11:24:07Z

compiler-rt/lib/radsan/tests/radsan_test_context.cpp

+// Test fixture that calls ENSURE_RADSAN_INITED before each test
+class TestRadsanContext : public ::testing::Test {
+protected:
+  void SetUp() override { radsan::EnsureInitialized(); }


So what happens if this SetUp routine is removed?

If this is removed, the flags() returns a nullptr and we die on line 36 of radsan_user_interface.cpp

davidtrevelyan · 2023-12-22T11:26:52Z

compiler-rt/lib/radsan/radsan_user_interface.cpp

    return exit_getter;
  }

+  __sanitizer::Printf("WARNING Invalid error mode: %s. Assuming 'exit'\n", user_mode);


What made you choose to use the __sanitizer printf here instead of a standard one?

Matching from other sanitizers (check out msan_report.cpp, for instance). Similar to using the atomics that are defined internally, I believe it's to run on systems that don't have standard headers

See the other comment about recursion hell.

If you intercept a function then call a method like std::printf and that also calls a method that could be intercepted, you go into a recursive loop you can't recover from. I think that is more of the reason why they don't use standard implementations, but roll their own.

davidtrevelyan · 2023-12-22T11:31:38Z

compiler-rt/lib/radsan/radsan.cpp

+
+namespace radsan {
+static __sanitizer::atomic_uint8_t radsan_inited{};
+static __sanitizer::atomic_uint8_t radsan_init_is_running{};


Another naive question: I can't picture a situation in my head where a second thread could be created during radsan_init, because I thought it's meant to be called before main - have you seen this happen elsewhere? Unless maybe this protects against the situation where a user might have added their own thread-creating functions into the .preinit array as well?

See comment on .preinit below!

davidtrevelyan · 2023-12-22T11:34:25Z

compiler-rt/lib/radsan/radsan.h

+#include "radsan_flags.h"

-extern "C" {
+namespace radsan {


It would be nice to be able to keep this radsan.h header file to just the public-facing API methods. I wonder if we could move these functions to another header/impl combination like radsan_globals.h and radsan_globals.cpp?

davidtrevelyan · 2023-12-22T11:45:50Z

Thanks for the PR @cjappl ! In answer to your questions:

Do the functions all live in the right files? Are we OK with the organization?

I've suggested a minor change with radsan.h, but otherwise it looks good to me!

Do we like how the exit/continue/interactive is right now? A few other sanitizers have a binary halt_on_error or continue_on_error that we could copy, but we would lose the "Interactive mode"

Good question. I do like the interactive mode, and it's something someone in the audience at the talk actually asked about. Personally my take is that interactive mode brings quite a lot of value, especially for use with interactive applications. I'd be sad if we got rid of it! What's your take?

One more general point. While I do really like where this is going, and the features it brings are great, I'm also equally cautious about how much more we're doubling-down on using the existing LLVM sanitizer infrastructure and how we're increasing use of LLVM code tools. There's definitely already some of that in RADSan now, but I'm mindful that we still want to explore teasing RADSan away from LLVM as well, as a bunch of potential users have told us that using a different compiler is much much harder for them than integrating a simple library. Part of me thinks it would be prudent to try to:

use standard tooling in preference over LLVM tooling wherever possible, and
create a clean architectural break around the things from LLVM that RADSan can survive without, so that it makes it easier in future to pull it out into its own separate library.

Perhaps we can have a core RADSan library on its own without the LLVM bells and whistles, and then the sanitizer could just use that in addition to the extra cool stuff. I need to collect my thoughts around this and what it means for this PR. But it's good food for thought! Have you thought about this too at all?

cjappl · 2023-12-22T17:53:51Z

I've suggested a minor change with radsan.h, but otherwise it looks good to me!

Great! Thanks. I'll probably save a serious revision on this until we can chat it all over :) Appreciate the review, definitely made me interrogate some places I glossed over.

Do we like how the exit/continue/interactive is right now? A few other sanitizers have a binary halt_on_error or continue_on_error that we could copy, but we would lose the "Interactive mode"

Good question. I do like the interactive mode, and it's something someone in the audience at the talk actually asked about. Personally my take is that interactive mode brings quite a lot of value, especially for use with interactive applications. I'd be sad if we got rid of it! What's your take?

Works for me! Just wanted to ask the question to say "We have a chance to match some other sanitizers, but we lose some of our local flavor, what do we thing?" All for keeping it in!!

One more general point. While I do really like where this is going, and the features it brings are great, I'm also equally cautious about how much more we're doubling-down on using the existing LLVM sanitizer infrastructure and how we're increasing use of LLVM code tools. There's definitely already some of that in RADSan now, but I'm mindful that we still want to explore teasing RADSan away from LLVM as well, as a bunch of potential users have told us that using a different compiler is much much harder for them than integrating a simple library. Part of me thinks it would be prudent to try to:
* use standard tooling in preference over LLVM tooling wherever possible, and

* create a clean architectural break around the things from LLVM that RADSan can survive without, so that it makes it easier in future to pull it out into its own separate library.
Perhaps we can have a core RADSan library on its own without the LLVM bells and whistles, and then the sanitizer could just use that in addition to the extra cool stuff. I need to collect my thoughts around this and what it means for this PR. But it's good food for thought! Have you thought about this too at all?

Good question. I think this is the thing we should discuss in the new year more than anything! I think these ideas are absolutely worth chewing on, and massively inform how this review (and the near future of development) goes.

I want to understand more fully the "separate library" approach.

Some questions I have are:

How would the interceptors work without being a part of the compiler?
How are we able to push/pop a stack on function calls without being a part of the compiler?

I want to understand more fully that direction so I can turn it over in my head. I think once I have a better idea of what that path entails I'll be able to have a more fully formed opinion on it!

I think getting to the root of the issue of "does radsan have a life outside of clang/llvm" is a core question we should approach head on, I think it'll inform a bunch of things in this next batch of changes :)

cjappl

Alright I took a pass at reorganizing and simplifying everything. This didn't touch the bigger questions posed in my last big comment, I'll save that for when we chat in the new year.

Cheers!

cjappl · 2023-12-23T22:16:31Z

compiler-rt/lib/radsan/radsan.cpp

+using namespace __sanitizer;
+
+namespace radsan {
+static __sanitizer::atomic_uint8_t radsan_inited{};


After fussing with this a bit, there are very easy ways for you to segfault in these sanitizers. These internal types are defined to not use any system calls that may or may not invoke an intercepted function.

For instance, I was trying to make a Meyer's singleton of a big type. Because it was statically initialized, and was large enough, the compiler attempted to put a pthread_mutex_lock around the call. This happened in such a way that we were in a recursive loop (intercepting the lock, trying to initialize the member with a lock, intercepting the lock) and it segfaulted.

It seems as if you stay in the __sanitizer special types, it prevents you from shooting yourself in the foot.

cjappl · 2023-12-23T22:17:18Z

compiler-rt/lib/radsan/radsan.h

+
+    @return true if RADSan is initialized, false otherwise.
+*/
+SANITIZER_INTERFACE_ATTRIBUTE bool radsan_is_initialized();


Made these methods "public". Let me know what you think about them being here

cjappl · 2023-12-23T22:18:16Z

compiler-rt/lib/radsan/radsan_context.cpp

+  return __sanitizer::atomic_load(&detail::radsan_report_count, memory_order_acquire); 
+}
+
+void IncrementReportCount() { 


Moved these report methods into this file, as it's where they are used. It may make sense to make a radsan_report.cpp/.h, especially once we get an exit report if we do that with the continue mode.

cjappl · 2023-12-23T22:19:09Z

compiler-rt/lib/radsan/radsan_preinit.cpp

 // The symbol is called __local_radsan_preinit, because it's not intended to be
 // exported.
 // This code is linked into the main executable when -fsanitize=realtime is in
 // the link flags. It can only use exported interface functions.


Fixed this in the latest review, all methods called from linux land are linked in the C linkage instead of C++.

cjappl · 2023-12-23T22:21:16Z

compiler-rt/lib/radsan/radsan_user_interface.cpp

    return exit_getter;
  }

+  __sanitizer::Printf("WARNING Invalid error mode: %s. Assuming 'exit'\n", user_mode);


See the other comment about recursion hell.

If you intercept a function then call a method like std::printf and that also calls a method that could be intercepted, you go into a recursive loop you can't recover from. I think that is more of the reason why they don't use standard implementations, but roll their own.

cjappl · 2024-01-04T18:12:54Z

Converted to DRAFT - as discussed we are going to more seriously investigate feedback and the upstreaming process before continuing down this line of thinking

…arallel fusion llvm#94391 (llvm#97607)" This reverts commit edbc0e3. Reason for rollback. ASAN complains about this PR: ==4320==ERROR: AddressSanitizer: heap-use-after-free on address 0x502000006cd8 at pc 0x55e2978d63cf bp 0x7ffe6431c2b0 sp 0x7ffe6431c2a8 READ of size 8 at 0x502000006cd8 thread T0 #0 0x55e2978d63ce in map<llvm::MutableArrayRef<mlir::BlockArgument> &, llvm::MutableArrayRef<mlir::BlockArgument>, nullptr> mlir/include/mlir/IR/IRMapping.h:40:11 #1 0x55e2978d63ce in mlir::createFused(mlir::LoopLikeOpInterface, mlir::LoopLikeOpInterface, mlir::RewriterBase&, std::__u::function<llvm::SmallVector<mlir::Value, 6u> (mlir::OpBuilder&, mlir::Location, llvm::ArrayRef<mlir::BlockArgument>)>, llvm::function_ref<void (mlir::RewriterBase&, mlir::LoopLikeOpInterface, mlir::LoopLikeOpInterface&, mlir::IRMapping)>) mlir/lib/Interfaces/LoopLikeInterface.cpp:156:11 #2 0x55e2952a614b in mlir::fuseIndependentSiblingForLoops(mlir::scf::ForOp, mlir::scf::ForOp, mlir::RewriterBase&) mlir/lib/Dialect/SCF/Utils/Utils.cpp:1398:43 #3 0x55e291480c6f in mlir::transform::LoopFuseSiblingOp::apply(mlir::transform::TransformRewriter&, mlir::transform::TransformResults&, mlir::transform::TransformState&) mlir/lib/Dialect/SCF/TransformOps/SCFTransformOps.cpp:482:17 #4 0x55e29149ed5e in mlir::transform::detail::TransformOpInterfaceInterfaceTraits::Model<mlir::transform::LoopFuseSiblingOp>::apply(mlir::transform::detail::TransformOpInterfaceInterfaceTraits::Concept const*, mlir::Operation*, mlir::transform::TransformRewriter&, mlir::transform::TransformResults&, mlir::transform::TransformState&) blaze-out/k8-opt-asan/bin/mlir/include/mlir/Dialect/Transform/Interfaces/TransformInterfaces.h.inc:477:56 #5 0x55e297494a60 in apply blaze-out/k8-opt-asan/bin/mlir/include/mlir/Dialect/Transform/Interfaces/TransformInterfaces.cpp.inc:61:14 #6 0x55e297494a60 in mlir::transform::TransformState::applyTransform(mlir::transform::TransformOpInterface) mlir/lib/Dialect/Transform/Interfaces/TransformInterfaces.cpp:953:48 #7 0x55e294646a8d in applySequenceBlock(mlir::Block&, mlir::transform::FailurePropagationMode, mlir::transform::TransformState&, mlir::transform::TransformResults&) mlir/lib/Dialect/Transform/IR/TransformOps.cpp:1788:15 #8 0x55e29464f927 in mlir::transform::NamedSequenceOp::apply(mlir::transform::TransformRewriter&, mlir::transform::TransformResults&, mlir::transform::TransformState&) mlir/lib/Dialect/Transform/IR/TransformOps.cpp:2155:10 #9 0x55e2945d28ee in mlir::transform::detail::TransformOpInterfaceInterfaceTraits::Model<mlir::transform::NamedSequenceOp>::apply(mlir::transform::detail::TransformOpInterfaceInterfaceTraits::Concept const*, mlir::Operation*, mlir::transform::TransformRewriter&, mlir::transform::TransformResults&, mlir::transform::TransformState&) blaze-out/k8-opt-asan/bin/mlir/include/mlir/Dialect/Transform/Interfaces/TransformInterfaces.h.inc:477:56 #10 0x55e297494a60 in apply blaze-out/k8-opt-asan/bin/mlir/include/mlir/Dialect/Transform/Interfaces/TransformInterfaces.cpp.inc:61:14 #11 0x55e297494a60 in mlir::transform::TransformState::applyTransform(mlir::transform::TransformOpInterface) mlir/lib/Dialect/Transform/Interfaces/TransformInterfaces.cpp:953:48 #12 0x55e2974a5fe2 in mlir::transform::applyTransforms(mlir::Operation*, mlir::transform::TransformOpInterface, mlir::RaggedArray<llvm::PointerUnion<mlir::Operation*, mlir::Attribute, mlir::Value>> const&, mlir::transform::TransformOptions const&, bool) mlir/lib/Dialect/Transform/Interfaces/TransformInterfaces.cpp:2016:16 #13 0x55e2945888d7 in mlir::transform::applyTransformNamedSequence(mlir::RaggedArray<llvm::PointerUnion<mlir::Operation*, mlir::Attribute, mlir::Value>>, mlir::transform::TransformOpInterface, mlir::ModuleOp, mlir::transform::TransformOptions const&) mlir/lib/Dialect/Transform/Transforms/TransformInterpreterUtils.cpp:234:10 #14 0x55e294582446 in (anonymous namespace)::InterpreterPass::runOnOperation() mlir/lib/Dialect/Transform/Transforms/InterpreterPass.cpp:147:16 #15 0x55e2978e93c6 in operator() mlir/lib/Pass/Pass.cpp:527:17 #16 0x55e2978e93c6 in void llvm::function_ref<void ()>::callback_fn<mlir::detail::OpToOpPassAdaptor::run(mlir::Pass*, mlir::Operation*, mlir::AnalysisManager, bool, unsigned int)::$_1>(long) llvm/include/llvm/ADT/STLFunctionalExtras.h:45:12 #17 0x55e2978e207a in operator() llvm/include/llvm/ADT/STLFunctionalExtras.h:68:12 #18 0x55e2978e207a in executeAction<mlir::PassExecutionAction, mlir::Pass &> mlir/include/mlir/IR/MLIRContext.h:275:7 #19 0x55e2978e207a in mlir::detail::OpToOpPassAdaptor::run(mlir::Pass*, mlir::Operation*, mlir::AnalysisManager, bool, unsigned int) mlir/lib/Pass/Pass.cpp:521:21 #20 0x55e2978e5fbf in runPipeline mlir/lib/Pass/Pass.cpp:593:16 #21 0x55e2978e5fbf in mlir::PassManager::runPasses(mlir::Operation*, mlir::AnalysisManager) mlir/lib/Pass/Pass.cpp:904:10 #22 0x55e2978e5b65 in mlir::PassManager::run(mlir::Operation*) mlir/lib/Pass/Pass.cpp:884:60 #23 0x55e291ebb460 in performActions(llvm::raw_ostream&, std::__u::shared_ptr<llvm::SourceMgr> const&, mlir::MLIRContext*, mlir::MlirOptMainConfig const&) mlir/lib/Tools/mlir-opt/MlirOptMain.cpp:408:17 #24 0x55e291ebabd9 in processBuffer mlir/lib/Tools/mlir-opt/MlirOptMain.cpp:481:9 #25 0x55e291ebabd9 in operator() mlir/lib/Tools/mlir-opt/MlirOptMain.cpp:548:12 #26 0x55e291ebabd9 in llvm::LogicalResult llvm::function_ref<llvm::LogicalResult (std::__u::unique_ptr<llvm::MemoryBuffer, std::__u::default_delete<llvm::MemoryBuffer>>, llvm::raw_ostream&)>::callback_fn<mlir::MlirOptMain(llvm::raw_ostream&, std::__u::unique_ptr<llvm::MemoryBuffer, std::__u::default_delete<llvm::MemoryBuffer>>, mlir::DialectRegistry&, mlir::MlirOptMainConfig const&)::$_0>(long, std::__u::unique_ptr<llvm::MemoryBuffer, std::__u::default_delete<llvm::MemoryBuffer>>, llvm::raw_ostream&) llvm/include/llvm/ADT/STLFunctionalExtras.h:45:12 #27 0x55e297b1cffe in operator() llvm/include/llvm/ADT/STLFunctionalExtras.h:68:12 #28 0x55e297b1cffe in mlir::splitAndProcessBuffer(std::__u::unique_ptr<llvm::MemoryBuffer, std::__u::default_delete<llvm::MemoryBuffer>>, llvm::function_ref<llvm::LogicalResult (std::__u::unique_ptr<llvm::MemoryBuffer, std::__u::default_delete<llvm::MemoryBuffer>>, llvm::raw_ostream&)>, llvm::raw_ostream&, llvm::StringRef, llvm::StringRef)::$_0::operator()(llvm::StringRef) const mlir/lib/Support/ToolUtilities.cpp:86:16 #29 0x55e297b1c9c5 in interleave<const llvm::StringRef *, (lambda at mlir/lib/Support/ToolUtilities.cpp:79:23), (lambda at llvm/include/llvm/ADT/STLExtras.h:2147:49), void> llvm/include/llvm/ADT/STLExtras.h:2125:3 #30 0x55e297b1c9c5 in interleave<llvm::SmallVector<llvm::StringRef, 8U>, (lambda at mlir/lib/Support/ToolUtilities.cpp:79:23), llvm::raw_ostream, llvm::StringRef> llvm/include/llvm/ADT/STLExtras.h:2147:3 #31 0x55e297b1c9c5 in mlir::splitAndProcessBuffer(std::__u::unique_ptr<llvm::MemoryBuffer, std::__u::default_delete<llvm::MemoryBuffer>>, llvm::function_ref<llvm::LogicalResult (std::__u::unique_ptr<llvm::MemoryBuffer, std::__u::default_delete<llvm::MemoryBuffer>>, llvm::raw_ostream&)>, llvm::raw_ostream&, llvm::StringRef, llvm::StringRef) mlir/lib/Support/ToolUtilities.cpp:89:3 #32 0x55e291eb0cf0 in mlir::MlirOptMain(llvm::raw_ostream&, std::__u::unique_ptr<llvm::MemoryBuffer, std::__u::default_delete<llvm::MemoryBuffer>>, mlir::DialectRegistry&, mlir::MlirOptMainConfig const&) mlir/lib/Tools/mlir-opt/MlirOptMain.cpp:551:10 #33 0x55e291eb115c in mlir::MlirOptMain(int, char**, llvm::StringRef, llvm::StringRef, mlir::DialectRegistry&) mlir/lib/Tools/mlir-opt/MlirOptMain.cpp:589:14 #34 0x55e291eb15f8 in mlir::MlirOptMain(int, char**, llvm::StringRef, mlir::DialectRegistry&) mlir/lib/Tools/mlir-opt/MlirOptMain.cpp:605:10 #35 0x55e29130d1be in main mlir/tools/mlir-opt/mlir-opt.cpp:311:33 #36 0x7fbcf3fff3d3 in __libc_start_main (/usr/grte/v5/lib64/libc.so.6+0x613d3) (BuildId: 9a996398ce14a94560b0c642eb4f6e94) #37 0x55e2912365a9 in _start /usr/grte/v5/debug-src/src/csu/../sysdeps/x86_64/start.S:120 0x502000006cd8 is located 8 bytes inside of 16-byte region [0x502000006cd0,0x502000006ce0) freed by thread T0 here: #0 0x55e29130b7e2 in operator delete(void*, unsigned long) compiler-rt/lib/asan/asan_new_delete.cpp:155:3 #1 0x55e2979eb657 in __libcpp_operator_delete<void *, unsigned long> #2 0x55e2979eb657 in __do_deallocate_handle_size<> #3 0x55e2979eb657 in __libcpp_deallocate #4 0x55e2979eb657 in deallocate #5 0x55e2979eb657 in deallocate #6 0x55e2979eb657 in operator() #7 0x55e2979eb657 in ~vector #8 0x55e2979eb657 in mlir::Block::~Block() mlir/lib/IR/Block.cpp:24:1 #9 0x55e2979ebc17 in deleteNode llvm/include/llvm/ADT/ilist.h:42:39 #10 0x55e2979ebc17 in erase llvm/include/llvm/ADT/ilist.h:205:5 #11 0x55e2979ebc17 in erase llvm/include/llvm/ADT/ilist.h:209:39 #12 0x55e2979ebc17 in mlir::Block::erase() mlir/lib/IR/Block.cpp:67:28 #13 0x55e297aef978 in mlir::RewriterBase::eraseBlock(mlir::Block*) mlir/lib/IR/PatternMatch.cpp:245:10 #14 0x55e297af0563 in mlir::RewriterBase::inlineBlockBefore(mlir::Block*, mlir::Block*, llvm::ilist_iterator<llvm::ilist_detail::node_options<mlir::Operation, false, false, void, false, void>, false, false>, mlir::ValueRange) mlir/lib/IR/PatternMatch.cpp:331:3 #15 0x55e297af06d8 in mlir::RewriterBase::mergeBlocks(mlir::Block*, mlir::Block*, mlir::ValueRange) mlir/lib/IR/PatternMatch.cpp:341:3 #16 0x55e297036608 in mlir::scf::ForOp::replaceWithAdditionalYields(mlir::RewriterBase&, mlir::ValueRange, bool, std::__u::function<llvm::SmallVector<mlir::Value, 6u> (mlir::OpBuilder&, mlir::Location, llvm::ArrayRef<mlir::BlockArgument>)> const&) mlir/lib/Dialect/SCF/IR/SCF.cpp:575:12 #17 0x55e2970673ca in mlir::detail::LoopLikeOpInterfaceInterfaceTraits::Model<mlir::scf::ForOp>::replaceWithAdditionalYields(mlir::detail::LoopLikeOpInterfaceInterfaceTraits::Concept const*, mlir::Operation*, mlir::RewriterBase&, mlir::ValueRange, bool, std::__u::function<llvm::SmallVector<mlir::Value, 6u> (mlir::OpBuilder&, mlir::Location, llvm::ArrayRef<mlir::BlockArgument>)> const&) blaze-out/k8-opt-asan/bin/mlir/include/mlir/Interfaces/LoopLikeInterface.h.inc:658:56 #18 0x55e2978d5feb in replaceWithAdditionalYields blaze-out/k8-opt-asan/bin/mlir/include/mlir/Interfaces/LoopLikeInterface.cpp.inc:105:14 #19 0x55e2978d5feb in mlir::createFused(mlir::LoopLikeOpInterface, mlir::LoopLikeOpInterface, mlir::RewriterBase&, std::__u::function<llvm::SmallVector<mlir::Value, 6u> (mlir::OpBuilder&, mlir::Location, llvm::ArrayRef<mlir::BlockArgument>)>, llvm::function_ref<void (mlir::RewriterBase&, mlir::LoopLikeOpInterface, mlir::LoopLikeOpInterface&, mlir::IRMapping)>) mlir/lib/Interfaces/LoopLikeInterface.cpp:135:14 #20 0x55e2952a614b in mlir::fuseIndependentSiblingForLoops(mlir::scf::ForOp, mlir::scf::ForOp, mlir::RewriterBase&) mlir/lib/Dialect/SCF/Utils/Utils.cpp:1398:43 #21 0x55e291480c6f in mlir::transform::LoopFuseSiblingOp::apply(mlir::transform::TransformRewriter&, mlir::transform::TransformResults&, mlir::transform::TransformState&) mlir/lib/Dialect/SCF/TransformOps/SCFTransformOps.cpp:482:17 #22 0x55e29149ed5e in mlir::transform::detail::TransformOpInterfaceInterfaceTraits::Model<mlir::transform::LoopFuseSiblingOp>::apply(mlir::transform::detail::TransformOpInterfaceInterfaceTraits::Concept const*, mlir::Operation*, mlir::transform::TransformRewriter&, mlir::transform::TransformResults&, mlir::transform::TransformState&) blaze-out/k8-opt-asan/bin/mlir/include/mlir/Dialect/Transform/Interfaces/TransformInterfaces.h.inc:477:56 #23 0x55e297494a60 in apply blaze-out/k8-opt-asan/bin/mlir/include/mlir/Dialect/Transform/Interfaces/TransformInterfaces.cpp.inc:61:14 #24 0x55e297494a60 in mlir::transform::TransformState::applyTransform(mlir::transform::TransformOpInterface) mlir/lib/Dialect/Transform/Interfaces/TransformInterfaces.cpp:953:48 #25 0x55e294646a8d in applySequenceBlock(mlir::Block&, mlir::transform::FailurePropagationMode, mlir::transform::TransformState&, mlir::transform::TransformResults&) mlir/lib/Dialect/Transform/IR/TransformOps.cpp:1788:15 #26 0x55e29464f927 in mlir::transform::NamedSequenceOp::apply(mlir::transform::TransformRewriter&, mlir::transform::TransformResults&, mlir::transform::TransformState&) mlir/lib/Dialect/Transform/IR/TransformOps.cpp:2155:10 #27 0x55e2945d28ee in mlir::transform::detail::TransformOpInterfaceInterfaceTraits::Model<mlir::transform::NamedSequenceOp>::apply(mlir::transform::detail::TransformOpInterfaceInterfaceTraits::Concept const*, mlir::Operation*, mlir::transform::TransformRewriter&, mlir::transform::TransformResults&, mlir::transform::TransformState&) blaze-out/k8-opt-asan/bin/mlir/include/mlir/Dialect/Transform/Interfaces/TransformInterfaces.h.inc:477:56 #28 0x55e297494a60 in apply blaze-out/k8-opt-asan/bin/mlir/include/mlir/Dialect/Transform/Interfaces/TransformInterfaces.cpp.inc:61:14 #29 0x55e297494a60 in mlir::transform::TransformState::applyTransform(mlir::transform::TransformOpInterface) mlir/lib/Dialect/Transform/Interfaces/TransformInterfaces.cpp:953:48 #30 0x55e2974a5fe2 in mlir::transform::applyTransforms(mlir::Operation*, mlir::transform::TransformOpInterface, mlir::RaggedArray<llvm::PointerUnion<mlir::Operation*, mlir::Attribute, mlir::Value>> const&, mlir::transform::TransformOptions const&, bool) mlir/lib/Dialect/Transform/Interfaces/TransformInterfaces.cpp:2016:16 #31 0x55e2945888d7 in mlir::transform::applyTransformNamedSequence(mlir::RaggedArray<llvm::PointerUnion<mlir::Operation*, mlir::Attribute, mlir::Value>>, mlir::transform::TransformOpInterface, mlir::ModuleOp, mlir::transform::TransformOptions const&) mlir/lib/Dialect/Transform/Transforms/TransformInterpreterUtils.cpp:234:10 #32 0x55e294582446 in (anonymous namespace)::InterpreterPass::runOnOperation() mlir/lib/Dialect/Transform/Transforms/InterpreterPass.cpp:147:16 #33 0x55e2978e93c6 in operator() mlir/lib/Pass/Pass.cpp:527:17 #34 0x55e2978e93c6 in void llvm::function_ref<void ()>::callback_fn<mlir::detail::OpToOpPassAdaptor::run(mlir::Pass*, mlir::Operation*, mlir::AnalysisManager, bool, unsigned int)::$_1>(long) llvm/include/llvm/ADT/STLFunctionalExtras.h:45:12 #35 0x55e2978e207a in operator() llvm/include/llvm/ADT/STLFunctionalExtras.h:68:12 #36 0x55e2978e207a in executeAction<mlir::PassExecutionAction, mlir::Pass &> mlir/include/mlir/IR/MLIRContext.h:275:7 #37 0x55e2978e207a in mlir::detail::OpToOpPassAdaptor::run(mlir::Pass*, mlir::Operation*, mlir::AnalysisManager, bool, unsigned int) mlir/lib/Pass/Pass.cpp:521:21 #38 0x55e2978e5fbf in runPipeline mlir/lib/Pass/Pass.cpp:593:16 #39 0x55e2978e5fbf in mlir::PassManager::runPasses(mlir::Operation*, mlir::AnalysisManager) mlir/lib/Pass/Pass.cpp:904:10 llvm#40 0x55e2978e5b65 in mlir::PassManager::run(mlir::Operation*) mlir/lib/Pass/Pass.cpp:884:60 llvm#41 0x55e291ebb460 in performActions(llvm::raw_ostream&, std::__u::shared_ptr<llvm::SourceMgr> const&, mlir::MLIRContext*, mlir::MlirOptMainConfig const&) mlir/lib/Tools/mlir-opt/MlirOptMain.cpp:408:17 llvm#42 0x55e291ebabd9 in processBuffer mlir/lib/Tools/mlir-opt/MlirOptMain.cpp:481:9 llvm#43 0x55e291ebabd9 in operator() mlir/lib/Tools/mlir-opt/MlirOptMain.cpp:548:12 llvm#44 0x55e291ebabd9 in llvm::LogicalResult llvm::function_ref<llvm::LogicalResult (std::__u::unique_ptr<llvm::MemoryBuffer, std::__u::default_delete<llvm::MemoryBuffer>>, llvm::raw_ostream&)>::callback_fn<mlir::MlirOptMain(llvm::raw_ostream&, std::__u::unique_ptr<llvm::MemoryBuffer, std::__u::default_delete<llvm::MemoryBuffer>>, mlir::DialectRegistry&, mlir::MlirOptMainConfig const&)::$_0>(long, std::__u::unique_ptr<llvm::MemoryBuffer, std::__u::default_delete<llvm::MemoryBuffer>>, llvm::raw_ostream&) llvm/include/llvm/ADT/STLFunctionalExtras.h:45:12 llvm#45 0x55e297b1cffe in operator() llvm/include/llvm/ADT/STLFunctionalExtras.h:68:12 llvm#46 0x55e297b1cffe in mlir::splitAndProcessBuffer(std::__u::unique_ptr<llvm::MemoryBuffer, std::__u::default_delete<llvm::MemoryBuffer>>, llvm::function_ref<llvm::LogicalResult (std::__u::unique_ptr<llvm::MemoryBuffer, std::__u::default_delete<llvm::MemoryBuffer>>, llvm::raw_ostream&)>, llvm::raw_ostream&, llvm::StringRef, llvm::StringRef)::$_0::operator()(llvm::StringRef) const mlir/lib/Support/ToolUtilities.cpp:86:16 llvm#47 0x55e297b1c9c5 in interleave<const llvm::StringRef *, (lambda at mlir/lib/Support/ToolUtilities.cpp:79:23), (lambda at llvm/include/llvm/ADT/STLExtras.h:2147:49), void> llvm/include/llvm/ADT/STLExtras.h:2125:3 llvm#48 0x55e297b1c9c5 in interleave<llvm::SmallVector<llvm::StringRef, 8U>, (lambda at mlir/lib/Support/ToolUtilities.cpp:79:23), llvm::raw_ostream, llvm::StringRef> llvm/include/llvm/ADT/STLExtras.h:2147:3 llvm#49 0x55e297b1c9c5 in mlir::splitAndProcessBuffer(std::__u::unique_ptr<llvm::MemoryBuffer, std::__u::default_delete<llvm::MemoryBuffer>>, llvm::function_ref<llvm::LogicalResult (std::__u::unique_ptr<llvm::MemoryBuffer, std::__u::default_delete<llvm::MemoryBuffer>>, llvm::raw_ostream&)>, llvm::raw_ostream&, llvm::StringRef, llvm::StringRef) mlir/lib/Support/ToolUtilities.cpp:89:3 llvm#50 0x55e291eb0cf0 in mlir::MlirOptMain(llvm::raw_ostream&, std::__u::unique_ptr<llvm::MemoryBuffer, std::__u::default_delete<llvm::MemoryBuffer>>, mlir::DialectRegistry&, mlir::MlirOptMainConfig const&) mlir/lib/Tools/mlir-opt/MlirOptMain.cpp:551:10 llvm#51 0x55e291eb115c in mlir::MlirOptMain(int, char**, llvm::StringRef, llvm::StringRef, mlir::DialectRegistry&) mlir/lib/Tools/mlir-opt/MlirOptMain.cpp:589:14 previously allocated by thread T0 here: #0 0x55e29130ab5d in operator new(unsigned long) compiler-rt/lib/asan/asan_new_delete.cpp:86:3 #1 0x55e2979ed5d4 in __libcpp_operator_new<unsigned long> #2 0x55e2979ed5d4 in __libcpp_allocate #3 0x55e2979ed5d4 in allocate #4 0x55e2979ed5d4 in __allocate_at_least<std::__u::allocator<mlir::BlockArgument> > #5 0x55e2979ed5d4 in __split_buffer #6 0x55e2979ed5d4 in mlir::BlockArgument* std::__u::vector<mlir::BlockArgument, std::__u::allocator<mlir::BlockArgument>>::__push_back_slow_path<mlir::BlockArgument const&>(mlir::BlockArgument const&) #7 0x55e2979ec0f2 in push_back #8 0x55e2979ec0f2 in mlir::Block::addArgument(mlir::Type, mlir::Location) mlir/lib/IR/Block.cpp:154:13 #9 0x55e29796e457 in parseRegionBody mlir/lib/AsmParser/Parser.cpp:2172:34 #10 0x55e29796e457 in (anonymous namespace)::OperationParser::parseRegion(mlir::Region&, llvm::ArrayRef<mlir::OpAsmParser::Argument>, bool) mlir/lib/AsmParser/Parser.cpp:2121:7 #11 0x55e29796b25e in (anonymous namespace)::CustomOpAsmParser::parseRegion(mlir::Region&, llvm::ArrayRef<mlir::OpAsmParser::Argument>, bool) mlir/lib/AsmParser/Parser.cpp:1785:16 #12 0x55e297035742 in mlir::scf::ForOp::parse(mlir::OpAsmParser&, mlir::OperationState&) mlir/lib/Dialect/SCF/IR/SCF.cpp:521:14 #13 0x55e291322c18 in llvm::ParseResult llvm::detail::UniqueFunctionBase<llvm::ParseResult, mlir::OpAsmParser&, mlir::OperationState&>::CallImpl<llvm::ParseResult (*)(mlir::OpAsmParser&, mlir::OperationState&)>(void*, mlir::OpAsmParser&, mlir::OperationState&) llvm/include/llvm/ADT/FunctionExtras.h:220:12 #14 0x55e29795bea3 in operator() llvm/include/llvm/ADT/FunctionExtras.h:384:12 #15 0x55e29795bea3 in callback_fn<llvm::unique_function<llvm::ParseResult (mlir::OpAsmParser &, mlir::OperationState &)> > llvm/include/llvm/ADT/STLFunctionalExtras.h:45:12 #16 0x55e29795bea3 in operator() llvm/include/llvm/ADT/STLFunctionalExtras.h:68:12 #17 0x55e29795bea3 in parseOperation mlir/lib/AsmParser/Parser.cpp:1521:9 #18 0x55e29795bea3 in parseCustomOperation mlir/lib/AsmParser/Parser.cpp:2017:19 #19 0x55e29795bea3 in (anonymous namespace)::OperationParser::parseOperation() mlir/lib/AsmParser/Parser.cpp:1174:10 #20 0x55e297971d20 in parseBlockBody mlir/lib/AsmParser/Parser.cpp:2296:9 #21 0x55e297971d20 in (anonymous namespace)::OperationParser::parseBlock(mlir::Block*&) mlir/lib/AsmParser/Parser.cpp:2226:12 #22 0x55e29796e4f5 in parseRegionBody mlir/lib/AsmParser/Parser.cpp:2184:7 #23 0x55e29796e4f5 in (anonymous namespace)::OperationParser::parseRegion(mlir::Region&, llvm::ArrayRef<mlir::OpAsmParser::Argument>, bool) mlir/lib/AsmParser/Parser.cpp:2121:7 #24 0x55e29796b25e in (anonymous namespace)::CustomOpAsmParser::parseRegion(mlir::Region&, llvm::ArrayRef<mlir::OpAsmParser::Argument>, bool) mlir/lib/AsmParser/Parser.cpp:1785:16 #25 0x55e29796b2cf in (anonymous namespace)::CustomOpAsmParser::parseOptionalRegion(mlir::Region&, llvm::ArrayRef<mlir::OpAsmParser::Argument>, bool) mlir/lib/AsmParser/Parser.cpp:1796:12 #26 0x55e2978d89ff in mlir::function_interface_impl::parseFunctionOp(mlir::OpAsmParser&, mlir::OperationState&, bool, mlir::StringAttr, llvm::function_ref<mlir::Type (mlir::Builder&, llvm::ArrayRef<mlir::Type>, llvm::ArrayRef<mlir::Type>, mlir::function_interface_impl::VariadicFlag, std::__u::basic_string<char, std::__u::char_traits<char>, std::__u::allocator<char>>&)>, mlir::StringAttr, mlir::StringAttr) mlir/lib/Interfaces/FunctionImplementation.cpp:232:14 #27 0x55e2969ba41d in mlir::func::FuncOp::parse(mlir::OpAsmParser&, mlir::OperationState&) mlir/lib/Dialect/Func/IR/FuncOps.cpp:203:10 #28 0x55e291322c18 in llvm::ParseResult llvm::detail::UniqueFunctionBase<llvm::ParseResult, mlir::OpAsmParser&, mlir::OperationState&>::CallImpl<llvm::ParseResult (*)(mlir::OpAsmParser&, mlir::OperationState&)>(void*, mlir::OpAsmParser&, mlir::OperationState&) llvm/include/llvm/ADT/FunctionExtras.h:220:12 #29 0x55e29795bea3 in operator() llvm/include/llvm/ADT/FunctionExtras.h:384:12 #30 0x55e29795bea3 in callback_fn<llvm::unique_function<llvm::ParseResult (mlir::OpAsmParser &, mlir::OperationState &)> > llvm/include/llvm/ADT/STLFunctionalExtras.h:45:12 #31 0x55e29795bea3 in operator() llvm/include/llvm/ADT/STLFunctionalExtras.h:68:12 #32 0x55e29795bea3 in parseOperation mlir/lib/AsmParser/Parser.cpp:1521:9 #33 0x55e29795bea3 in parseCustomOperation mlir/lib/AsmParser/Parser.cpp:2017:19 #34 0x55e29795bea3 in (anonymous namespace)::OperationParser::parseOperation() mlir/lib/AsmParser/Parser.cpp:1174:10 #35 0x55e297959b78 in parse mlir/lib/AsmParser/Parser.cpp:2725:20 #36 0x55e297959b78 in mlir::parseAsmSourceFile(llvm::SourceMgr const&, mlir::Block*, mlir::ParserConfig const&, mlir::AsmParserState*, mlir::AsmParserCodeCompleteContext*) mlir/lib/AsmParser/Parser.cpp:2785:41 #37 0x55e29790d5c2 in mlir::parseSourceFile(std::__u::shared_ptr<llvm::SourceMgr> const&, mlir::Block*, mlir::ParserConfig const&, mlir::LocationAttr*) mlir/lib/Parser/Parser.cpp:46:10 #38 0x55e291ebbfe2 in parseSourceFile<mlir::ModuleOp, const std::__u::shared_ptr<llvm::SourceMgr> &> mlir/include/mlir/Parser/Parser.h:159:14 #39 0x55e291ebbfe2 in parseSourceFile<mlir::ModuleOp> mlir/include/mlir/Parser/Parser.h:189:10 llvm#40 0x55e291ebbfe2 in mlir::parseSourceFileForTool(std::__u::shared_ptr<llvm::SourceMgr> const&, mlir::ParserConfig const&, bool) mlir/include/mlir/Tools/ParseUtilities.h:31:12 llvm#41 0x55e291ebb263 in performActions(llvm::raw_ostream&, std::__u::shared_ptr<llvm::SourceMgr> const&, mlir::MLIRContext*, mlir::MlirOptMainConfig const&) mlir/lib/Tools/mlir-opt/MlirOptMain.cpp:383:33 llvm#42 0x55e291ebabd9 in processBuffer mlir/lib/Tools/mlir-opt/MlirOptMain.cpp:481:9 llvm#43 0x55e291ebabd9 in operator() mlir/lib/Tools/mlir-opt/MlirOptMain.cpp:548:12 llvm#44 0x55e291ebabd9 in llvm::LogicalResult llvm::function_ref<llvm::LogicalResult (std::__u::unique_ptr<llvm::MemoryBuffer, std::__u::default_delete<llvm::MemoryBuffer>>, llvm::raw_ostream&)>::callback_fn<mlir::MlirOptMain(llvm::raw_ostream&, std::__u::unique_ptr<llvm::MemoryBuffer, std::__u::default_delete<llvm::MemoryBuffer>>, mlir::DialectRegistry&, mlir::MlirOptMainConfig const&)::$_0>(long, std::__u::unique_ptr<llvm::MemoryBuffer, std::__u::default_delete<llvm::MemoryBuffer>>, llvm::raw_ostream&) llvm/include/llvm/ADT/STLFunctionalExtras.h:45:12 llvm#45 0x55e297b1cffe in operator() llvm/include/llvm/ADT/STLFunctionalExtras.h:68:12 llvm#46 0x55e297b1cffe in mlir::splitAndProcessBuffer(std::__u::unique_ptr<llvm::MemoryBuffer, std::__u::default_delete<llvm::MemoryBuffer>>, llvm::function_ref<llvm::LogicalResult (std::__u::unique_ptr<llvm::MemoryBuffer, std::__u::default_delete<llvm::MemoryBuffer>>, llvm::raw_ostream&)>, llvm::raw_ostream&, llvm::StringRef, llvm::StringRef)::$_0::operator()(llvm::StringRef) const mlir/lib/Support/ToolUtilities.cpp:86:16 llvm#47 0x55e297b1c9c5 in interleave<const llvm::StringRef *, (lambda at mlir/lib/Support/ToolUtilities.cpp:79:23), (lambda at llvm/include/llvm/ADT/STLExtras.h:2147:49), void> llvm/include/llvm/ADT/STLExtras.h:2125:3 llvm#48 0x55e297b1c9c5 in interleave<llvm::SmallVector<llvm::StringRef, 8U>, (lambda at mlir/lib/Support/ToolUtilities.cpp:79:23), llvm::raw_ostream, llvm::StringRef> llvm/include/llvm/ADT/STLExtras.h:2147:3 llvm#49 0x55e297b1c9c5 in mlir::splitAndProcessBuffer(std::__u::unique_ptr<llvm::MemoryBuffer, std::__u::default_delete<llvm::MemoryBuffer>>, llvm::function_ref<llvm::LogicalResult (std::__u::unique_ptr<llvm::MemoryBuffer, std::__u::default_delete<llvm::MemoryBuffer>>, llvm::raw_ostream&)>, llvm::raw_ostream&, llvm::StringRef, llvm::StringRef) mlir/lib/Support/ToolUtilities.cpp:89:3 llvm#50 0x55e291eb0cf0 in mlir::MlirOptMain(llvm::raw_ostream&, std::__u::unique_ptr<llvm::MemoryBuffer, std::__u::default_delete<llvm::MemoryBuffer>>, mlir::DialectRegistry&, mlir::MlirOptMainConfig const&) mlir/lib/Tools/mlir-opt/MlirOptMain.cpp:551:10 llvm#51 0x55e291eb115c in mlir::MlirOptMain(int, char**, llvm::StringRef, llvm::StringRef, mlir::DialectRegistry&) mlir/lib/Tools/mlir-opt/MlirOptMain.cpp:589:14 llvm#52 0x55e291eb15f8 in mlir::MlirOptMain(int, char**, llvm::StringRef, mlir::DialectRegistry&) mlir/lib/Tools/mlir-opt/MlirOptMain.cpp:605:10 llvm#53 0x55e29130d1be in main mlir/tools/mlir-opt/mlir-opt.cpp:311:33 llvm#54 0x7fbcf3fff3d3 in __libc_start_main (/usr/grte/v5/lib64/libc.so.6+0x613d3) (BuildId: 9a996398ce14a94560b0c642eb4f6e94) llvm#55 0x55e2912365a9 in _start /usr/grte/v5/debug-src/src/csu/../sysdeps/x86_64/start.S:120 SUMMARY: AddressSanitizer: heap-use-after-free mlir/include/mlir/IR/IRMapping.h:40:11 in map<llvm::MutableArrayRef<mlir::BlockArgument> &, llvm::MutableArrayRef<mlir::BlockArgument>, nullptr> Shadow bytes around the buggy address: 0x502000006a00: fa fa 00 fa fa fa 00 00 fa fa 00 fa fa fa 00 fa 0x502000006a80: fa fa 00 fa fa fa 00 00 fa fa 00 00 fa fa 00 00 0x502000006b00: fa fa 00 00 fa fa 00 00 fa fa 00 fa fa fa 00 fa 0x502000006b80: fa fa 00 fa fa fa 00 fa fa fa 00 00 fa fa 00 00 0x502000006c00: fa fa 00 00 fa fa 00 00 fa fa 00 00 fa fa fd fa =>0x502000006c80: fa fa fd fa fa fa fd fd fa fa fd[fd]fa fa fd fd 0x502000006d00: fa fa 00 fa fa fa 00 fa fa fa 00 fa fa fa 00 fa 0x502000006d80: fa fa 00 fa fa fa 00 fa fa fa 00 fa fa fa 00 fa 0x502000006e00: fa fa 00 fa fa fa 00 fa fa fa 00 00 fa fa 00 fa 0x502000006e80: fa fa 00 fa fa fa 00 00 fa fa 00 fa fa fa 00 fa 0x502000006f00: fa fa 00 fa fa fa 00 fa fa fa 00 fa fa fa 00 fa Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb ==4320==ABORTING

davidtrevelyan · 2024-09-21T18:29:13Z

Closing this PR as it's now long stale

…erver (llvm#148774) Summary: There was a deadlock was introduced by [PR llvm#146441](llvm#146441) which changed `CurrentThreadIsPrivateStateThread()` to `CurrentThreadPosesAsPrivateStateThread()`. This change caused the execution path in [`ExecutionContextRef::SetTargetPtr()`](https://github.com/llvm/llvm-project/blob/10b5558b61baab59c7d3dff37ffdf0861c0cc67a/lldb/source/Target/ExecutionContext.cpp#L513) to now enter a code block that was previously skipped, triggering [`GetSelectedFrame()`](https://github.com/llvm/llvm-project/blob/10b5558b61baab59c7d3dff37ffdf0861c0cc67a/lldb/source/Target/ExecutionContext.cpp#L522) which leads to a deadlock. Thread 1 gets m_modules_mutex in [`ModuleList::AppendImpl`](https://github.com/llvm/llvm-project/blob/96148f92146e5211685246722664e51ec730e7ba/lldb/source/Core/ModuleList.cpp#L218), Thread 3 gets m_language_runtimes_mutex in [`GetLanguageRuntime`](https://github.com/llvm/llvm-project/blob/96148f92146e5211685246722664e51ec730e7ba/lldb/source/Target/Process.cpp#L1501), but then Thread 1 waits for m_language_runtimes_mutex in [`GetLanguageRuntime`](https://github.com/llvm/llvm-project/blob/96148f92146e5211685246722664e51ec730e7ba/lldb/source/Target/Process.cpp#L1501) while Thread 3 waits for m_modules_mutex in [`ScanForGNUstepObjCLibraryCandidate`](https://github.com/llvm/llvm-project/blob/96148f92146e5211685246722664e51ec730e7ba/lldb/source/Plugins/LanguageRuntime/ObjC/GNUstepObjCRuntime/GNUstepObjCRuntime.cpp#L57). This fixes the deadlock by adding a scoped block around the mutex lock before the call to the notifier, and moved the notifier call outside of the mutex-guarded section. The notifier call [`NotifyModuleAdded`](https://github.com/llvm/llvm-project/blob/96148f92146e5211685246722664e51ec730e7ba/lldb/source/Target/Target.cpp#L1810) should be thread-safe, since the module should be added to the `ModuleList` before the mutex is released, and the notifier doesn't modify the module list further, and the call is operates on local state and the `Target` instance. ### Deadlocked Thread backtraces: ``` * thread #3, name = 'dbg.evt-handler', stop reason = signal SIGSTOP * frame #0: 0x00007f2f1e2973dc libc.so.6`futex_wait(private=0, expected=2, futex_word=0x0000563786bd5f40) at futex-internal.h:146:13 /*... a bunch of mutex related bt ... */ liblldb.so.21.0git`std::lock_guard<std::recursive_mutex>::lock_guard(this=0x00007f2f0f1927b0, __m=0x0000563786bd5f40) at std_mutex.h:229:19 frame #8: 0x00007f2f27946eb7 liblldb.so.21.0git`ScanForGNUstepObjCLibraryCandidate(modules=0x0000563786bd5f28, TT=0x0000563786bd5eb8) at GNUstepObjCRuntime.cpp:60:41 frame #9: 0x00007f2f27946c80 liblldb.so.21.0git`lldb_private::GNUstepObjCRuntime::CreateInstance(process=0x0000563785e1d360, language=eLanguageTypeObjC) at GNUstepObjCRuntime.cpp:87:8 frame #10: 0x00007f2f2746fca5 liblldb.so.21.0git`lldb_private::LanguageRuntime::FindPlugin(process=0x0000563785e1d360, language=eLanguageTypeObjC) at LanguageRuntime.cpp:210:36 frame #11: 0x00007f2f2742c9e3 liblldb.so.21.0git`lldb_private::Process::GetLanguageRuntime(this=0x0000563785e1d360, language=eLanguageTypeObjC) at Process.cpp:1516:9 ... frame #21: 0x00007f2f2750b5cc liblldb.so.21.0git`lldb_private::Thread::GetSelectedFrame(this=0x0000563785e064d0, select_most_relevant=DoNoSelectMostRelevantFrame) at Thread.cpp:274:48 frame #22: 0x00007f2f273f9957 liblldb.so.21.0git`lldb_private::ExecutionContextRef::SetTargetPtr(this=0x00007f2f0f193778, target=0x0000563786bd5be0, adopt_selected=true) at ExecutionContext.cpp:525:32 frame #23: 0x00007f2f273f9714 liblldb.so.21.0git`lldb_private::ExecutionContextRef::ExecutionContextRef(this=0x00007f2f0f193778, target=0x0000563786bd5be0, adopt_selected=true) at ExecutionContext.cpp:413:3 frame #24: 0x00007f2f270e80af liblldb.so.21.0git`lldb_private::Debugger::GetSelectedExecutionContext(this=0x0000563785d83bc0) at Debugger.cpp:1225:23 frame #25: 0x00007f2f271bb7fd liblldb.so.21.0git`lldb_private::Statusline::Redraw(this=0x0000563785d83f30, update=true) at Statusline.cpp:136:41 ... * thread #1, name = 'lldb', stop reason = signal SIGSTOP * frame #0: 0x00007f2f1e2973dc libc.so.6`futex_wait(private=0, expected=2, futex_word=0x0000563785e1dd98) at futex-internal.h:146:13 /*... a bunch of mutex related bt ... */ liblldb.so.21.0git`std::lock_guard<std::recursive_mutex>::lock_guard(this=0x00007ffe62be0488, __m=0x0000563785e1dd98) at std_mutex.h:229:19 frame #8: 0x00007f2f2742c8d1 liblldb.so.21.0git`lldb_private::Process::GetLanguageRuntime(this=0x0000563785e1d360, language=eLanguageTypeC_plus_plus) at Process.cpp:1510:41 frame #9: 0x00007f2f2743c46f liblldb.so.21.0git`lldb_private::Process::ModulesDidLoad(this=0x0000563785e1d360, module_list=0x00007ffe62be06a0) at Process.cpp:6082:36 ... frame #13: 0x00007f2f2715cf03 liblldb.so.21.0git`lldb_private::ModuleList::AppendImpl(this=0x0000563786bd5f28, module_sp=ptr = 0x563785cec560, use_notifier=true) at ModuleList.cpp:246:19 frame #14: 0x00007f2f2715cf4c liblldb.so.21.0git`lldb_private::ModuleList::Append(this=0x0000563786bd5f28, module_sp=ptr = 0x563785cec560, notify=true) at ModuleList.cpp:251:3 ... frame #19: 0x00007f2f274349b3 liblldb.so.21.0git`lldb_private::Process::ConnectRemote(this=0x0000563785e1d360, remote_url=(Data = "connect://localhost:1234", Length = 24)) at Process.cpp:3250:9 frame #20: 0x00007f2f27411e0e liblldb.so.21.0git`lldb_private::Platform::DoConnectProcess(this=0x0000563785c59990, connect_url=(Data = "connect://localhost:1234", Length = 24), plugin_name=(Data = "gdb-remote", Length = 10), debugger=0x0000563785d83bc0, stream=0x00007ffe62be3128, target=0x0000563786bd5be0, error=0x00007ffe62be1ca0) at Platform.cpp:1926:23 ``` ## Test Plan: Built a hello world a.out Run server in one terminal: ``` ~/llvm/build/Debug/bin/lldb-server g :1234 a.out ``` Run client in another terminal ``` ~/llvm/build/Debug/bin/lldb -o "gdb-remote 1234" -o "b hello.cc:3" ``` Before: Client hangs indefinitely ``` ~/llvm/build/Debug/bin/lldb -o "gdb-remote 1234" -o "b main" (lldb) gdb-remote 1234 ^C^C ``` After: ``` ~/llvm/build/Debug/bin/lldb -o "gdb-remote 1234" -o "b hello.cc:3" (lldb) gdb-remote 1234 Process 837068 stopped * thread #1, name = 'a.out', stop reason = signal SIGSTOP frame #0: 0x00007ffff7fe4a60 ld-linux-x86-64.so.2`_start: -> 0x7ffff7fe4a60 <+0>: movq %rsp, %rdi 0x7ffff7fe4a63 <+3>: callq 0x7ffff7fe5780 ; _dl_start at rtld.c:522:1 ld-linux-x86-64.so.2`_dl_start_user: 0x7ffff7fe4a68 <+0>: movq %rax, %r12 0x7ffff7fe4a6b <+3>: movl 0x18067(%rip), %eax ; _dl_skip_args (lldb) b hello.cc:3 Breakpoint 1: where = a.out`main + 15 at hello.cc:4:13, address = 0x00005555555551bf (lldb) c Process 837068 resuming Process 837068 stopped * thread #1, name = 'a.out', stop reason = breakpoint 1.1 frame #0: 0x00005555555551bf a.out`main at hello.cc:4:13 1 #include <iostream> 2 3 int main() { -> 4 std::cout << "Hello World" << std::endl; 5 return 0; 6 } ```

…namic (llvm#153420) Canonicalizing the following IR: ``` func.func @mul_zero_dynamic_nofold(%arg0: tensor<?x17xf32>) -> tensor<?x17xf32> { %0 = "tosa.const"() <{values = dense<0.000000e+00> : tensor<1x1xf32>}> : () -> tensor<1x1xf32> %1 = "tosa.const"() <{values = dense<0> : tensor<1xi8>}> : () -> tensor<1xi8> %2 = tosa.mul %arg0, %0, %1 : (tensor<?x17xf32>, tensor<1x1xf32>, tensor<1xi8>) -> tensor<?x17xf32> return %2 : tensor<?x17xf32> } ``` resulted in a crash ``` #0 0x000056513187e8db backtrace (./build-release/bin/mlir-opt+0x9d698db) #1 0x0000565131b17737 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) /local-ssd/sayans/Softwares/llvm-repo/llvm-project-latest/llvm/lib/Support/Unix/Signals.inc:838:8 #2 0x0000565131b187f3 PrintStackTraceSignalHandler(void*) /local-ssd/sayans/Softwares/llvm-repo/llvm-project-latest/llvm/lib/Support/Unix/Signals.inc:918:1 #3 0x0000565131b18c30 llvm::sys::RunSignalHandlers() /local-ssd/sayans/Softwares/llvm-repo/llvm-project-latest/llvm/lib/Support/Signals.cpp:105:18 #4 0x0000565131b18c30 SignalHandler(int, siginfo_t*, void*) /local-ssd/sayans/Softwares/llvm-repo/llvm-project-latest/llvm/lib/Support/Unix/Signals.inc:409:3 #5 0x00007f2e4165b050 (/lib/x86_64-linux-gnu/libc.so.6+0x3c050) #6 0x00007f2e416a9eec __pthread_kill_implementation ./nptl/pthread_kill.c:44:76 #7 0x00007f2e4165afb2 raise ./signal/../sysdeps/posix/raise.c:27:6 #8 0x00007f2e41645472 abort ./stdlib/abort.c:81:7 #9 0x00007f2e41645395 _nl_load_domain ./intl/loadmsgcat.c:1177:9 #10 0x00007f2e41653ec2 (/lib/x86_64-linux-gnu/libc.so.6+0x34ec2) #11 0x00005651443ec4ba mlir::DenseIntOrFPElementsAttr::getRaw(mlir::ShapedType, llvm::ArrayRef<char>) /local-ssd/sayans/Softwares/llvm-repo/llvm-project-latest/mlir/lib/IR/BuiltinAttributes.cpp:1361:3 #12 0x00005651443f1209 mlir::DenseElementsAttr::resizeSplat(mlir::ShapedType) /local-ssd/sayans/Softwares/llvm-repo/llvm-project-latest/mlir/lib/IR/BuiltinAttributes.cpp:0:10 #13 0x000056513f76f2b6 mlir::tosa::MulOp::fold(mlir::tosa::MulOpGenericAdaptor<llvm::ArrayRef<mlir::Attribute>>) /local-ssd/sayans/Softwares/llvm-repo/llvm-project-latest/mlir/lib/Dialect/Tosa/IR/TosaCanonicalizations.cpp:0:0 ``` from the folder for `tosa::mul` since the zero value was being reshaped to `?x17` size which isn't supported. AFAIK, `tosa.const` requires all dimensions to be static. So in this case, the fix is to not to fold the op.

cjappl added 16 commits December 20, 2023 12:38

Few more tests

e09205b

Clang-tidy fixups

6174ea7

Fix one more issue with continue test

7c497ff

Initial reorganizing

6617658

Use common sanitizer interface

2815d94

Make init 'private'

4341585

Some helper variables created

cd7b2a2

Compiling with some flags being read

76dc63f

Apparently working default flags!

f8f823f

Tests passing again

2fba9d2

Move RADSAN_ERROR_MODE to be part of RADSAN_OPTIONS

87d42f5

Two small things

6f445c9

More cleanup

8ff5f31

New test

3e36bbf

Merge branch 'radsan' into RADSAN_OPTIONS

ecfc292

More cleanup

87e2e98

cjappl commented Dec 21, 2023

View reviewed changes

cjappl requested a review from davidtrevelyan December 21, 2023 15:35

Get rid of data races

02642e4

davidtrevelyan reviewed Dec 22, 2023

View reviewed changes

cjappl added 5 commits December 23, 2023 10:19

Simplify initialization process with double locking

f280f0d

Make radsan_init use C-linkage

76215f7

Some reorganizing

7f974dd

Tucking everything else away

ff1e166

Reorganize double locking

6a34cdc

cjappl commented Dec 23, 2023

View reviewed changes

cjappl marked this pull request as draft January 4, 2024 18:12

Merge branch 'radsan' into RADSAN_OPTIONS

f2d2841

davidtrevelyan closed this Sep 21, 2024


		Flags *flags() { return &radsan_flags; }

		void EnsureInitialized() {

Set up ability to use RADSAN_OPTIONS, move RADSAN_ERROR_MODE to this new variable as a test #13

Set up ability to use RADSAN_OPTIONS, move RADSAN_ERROR_MODE to this new variable as a test #13

Uh oh!

Conversation

cjappl commented Dec 21, 2023

Prior art

Summary

What to look for

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

davidtrevelyan Dec 22, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

davidtrevelyan Dec 22, 2023 •

edited

Loading

davidtrevelyan commented Dec 22, 2023 •

edited

Loading

cjappl commented Dec 22, 2023 •

edited

Loading