[MLIR][SPIR-V] Null pointer dereference in type attribute handling while function call processing

[sairam2661]

Test commit: 5a86dc996c26299de63effc927075dcbfb924167

Description:
mlir-opt ends up triggering undefined behavior (null pointer dereference) when processing SPIR-V module with function calls and custom attributes (detected by UndefinedBehaviorSanitizer)

Steps to reproduce

• Minimal MLIR program (test.mlir)

"builtin.module"() ({
  "spirv.module"() <{
    addressing_model = #spirv.addressing_model<Logical>,
    memory_model = #spirv.memory_model<GLSL450>
  }> ({
    "spirv.func"() <{
      function_control = #spirv.function_control<None>,
      function_type = (f32) -> f32,
      sym_name = "bar"
    }> ({
    ^bb0(%arg0: f32):
      %0 = "spirv.FunctionCall"(%arg0) <{callee = @foo}> : (f32) -> f32
      "spirv.ReturnValue"(%0) : (f32) -> ()
    }) : () -> ()
    "spirv.func"() <{
      function_control = #spirv.function_control<None>,
      message = "2nd parent",
      sym_name = "foo"
    }> ({
    ^bb0(%arg0: f32):
      "spirv.ReturnValue"(%arg0) : (f32) -> ()
    }) : () -> ()
  }) : () -> ()
}) : () -> ()

Command:

mlir-opt test.mlir

Output:

/workdir/llvm-project/build/tools/mlir/include/mlir/IR/BuiltinAttributes.cpp.inc:735:21: runtime error: member access within null pointer of type 'mlir::detail::StorageUserBase<mlir::TypeAttr, mlir::Attribute, mlir::detail::TypeAttrStorage, mlir::detail::AttributeUniquer>::ImplType' (aka 'mlir::detail::TypeAttrStorage')
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /workdir/llvm-project/build/tools/mlir/include/mlir/IR/BuiltinAttributes.cpp.inc:735:21 in

[llvmbot]

@llvm/issue-subscribers-mlir

Author: None (sairam2661)

Test commit: [5a86dc9](https://github.com//pull/157520/commits/5a86dc996c26299de63effc927075dcbfb924167)

Description:
mlir-opt ends up triggering undefined behavior (null pointer dereference) when processing SPIR-V module with function calls and custom attributes (detected by UndefinedBehaviorSanitizer)

Steps to reproduce

• Minimal MLIR program (test.mlir)

"builtin.module"() ({
  "spirv.module"() <{
    addressing_model = #spirv.addressing_model<Logical>,
    memory_model = #spirv.memory_model<GLSL450>
  }> ({
    "spirv.func"() <{
      function_control = #spirv.function_control<None>,
      function_type = (f32) -> f32,
      sym_name = "bar"
    }> ({
    ^bb0(%arg0: f32):
      %0 = "spirv.FunctionCall"(%arg0) &lt;{callee = @<!-- -->foo}&gt; : (f32) -&gt; f32
      "spirv.ReturnValue"(%0) : (f32) -&gt; ()
    }) : () -&gt; ()
    "spirv.func"() &lt;{
      function_control = #spirv.function_control&lt;None&gt;,
      message = "2nd parent",
      sym_name = "foo"
    }&gt; ({
    ^bb0(%arg0: f32):
      "spirv.ReturnValue"(%arg0) : (f32) -&gt; ()
    }) : () -&gt; ()
  }) : () -&gt; ()
}) : () -&gt; ()

Command:

mlir-opt test.mlir

Output:

/workdir/llvm-project/build/tools/mlir/include/mlir/IR/BuiltinAttributes.cpp.inc:735:21: runtime error: member access within null pointer of type 'mlir::detail::StorageUserBase<mlir::TypeAttr, mlir::Attribute, mlir::detail::TypeAttrStorage, mlir::detail::AttributeUniquer>::ImplType' (aka 'mlir::detail::TypeAttrStorage')
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /workdir/llvm-project/build/tools/mlir/include/mlir/IR/BuiltinAttributes.cpp.inc:735:21 in

[llvmbot]

@llvm/issue-subscribers-mlir-spirv

Author: None (sairam2661)

Test commit: [5a86dc9](https://github.com//pull/157520/commits/5a86dc996c26299de63effc927075dcbfb924167)

Description:
mlir-opt ends up triggering undefined behavior (null pointer dereference) when processing SPIR-V module with function calls and custom attributes (detected by UndefinedBehaviorSanitizer)

Steps to reproduce

• Minimal MLIR program (test.mlir)

"builtin.module"() ({
  "spirv.module"() <{
    addressing_model = #spirv.addressing_model<Logical>,
    memory_model = #spirv.memory_model<GLSL450>
  }> ({
    "spirv.func"() <{
      function_control = #spirv.function_control<None>,
      function_type = (f32) -> f32,
      sym_name = "bar"
    }> ({
    ^bb0(%arg0: f32):
      %0 = "spirv.FunctionCall"(%arg0) &lt;{callee = @<!-- -->foo}&gt; : (f32) -&gt; f32
      "spirv.ReturnValue"(%0) : (f32) -&gt; ()
    }) : () -&gt; ()
    "spirv.func"() &lt;{
      function_control = #spirv.function_control&lt;None&gt;,
      message = "2nd parent",
      sym_name = "foo"
    }&gt; ({
    ^bb0(%arg0: f32):
      "spirv.ReturnValue"(%arg0) : (f32) -&gt; ()
    }) : () -&gt; ()
  }) : () -&gt; ()
}) : () -&gt; ()

Command:

mlir-opt test.mlir

Output:

/workdir/llvm-project/build/tools/mlir/include/mlir/IR/BuiltinAttributes.cpp.inc:735:21: runtime error: member access within null pointer of type 'mlir::detail::StorageUserBase<mlir::TypeAttr, mlir::Attribute, mlir::detail::TypeAttrStorage, mlir::detail::AttributeUniquer>::ImplType' (aka 'mlir::detail::TypeAttrStorage')
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /workdir/llvm-project/build/tools/mlir/include/mlir/IR/BuiltinAttributes.cpp.inc:735:21 in

[kuhar]

@amd-eochoalo could you take a look?

[amd-eochoalo]

@sairam2661 , it looks like the error is in the test case itself. Function foo is missing the function_type attribute. But it does take an argument and returns a value. After fixing this, the test passes.

"builtin.module"() ({
  "spirv.module"() <{
    addressing_model = #spirv.addressing_model<Logical>,
    memory_model = #spirv.memory_model<GLSL450>
  }> ({
    "spirv.func"() <{
      function_control = #spirv.function_control<None>,
      function_type = (f32) -> f32,
      sym_name = "bar"
    }> ({
    ^bb0(%arg0: f32):
      %0 = "spirv.FunctionCall"(%arg0) <{callee = @foo}> : (f32) -> f32
      "spirv.ReturnValue"(%0) : (f32) -> ()
    }) : () -> ()
    "spirv.func"() <{
      function_control = #spirv.function_control<None>,
      message = "2nd parent",
      sym_name = "foo",               // added comma here
      function_type = (f32) -> f32 // notice this added line here
    }> ({
    ^bb0(%arg0: f32):
      "spirv.ReturnValue"(%arg0) : (f32) -> ()
    }) : () -> ()
  }) : () -> ()
}) : () -> ()

$ UBSAN_OPTIONS=print_stacktrace=1 mlir-opt --mlir-disable-threading  test.mlir

module {
  spirv.module Logical GLSL450 {
    spirv.func @bar(%arg0: f32) -> f32 "None" {
      %0 = spirv.FunctionCall @foo(%arg0) : (f32) -> f32
      spirv.ReturnValue %0 : f32
    }
    spirv.func @foo(%arg0: f32) -> f32 "None" {
      spirv.ReturnValue %arg0 : f32
    }
  }
}

[sairam2661]

@amd-eochoalo Thanks for the reply + fix! I'm curious about the tool's behavior - is this undefined behavior expected for the original case/similar cases, than a more graceful failure?

[joker-eph]

it looks like the error is in the test case itself.

MLIR should not trigger UB or crash on invalid input: the parsers should be resilient to the generic printed form, and the verifier should cover a graceful failure.

[amd-eochoalo]

Thanks for the clarification @joker-eph! @sairam2661 I will make a PR to handle this failure in a more graceful manner.

[amd-eochoalo]

It looks like the issue is that the verification is attempting to verify using non-local properties that have not been verified themselves. I've opened [mlir][spirv] Remove nonlocal call verification. #159399 to remove the verification which depends on unverified operations.