Crash when Quadrature custom_blocks and custom_orders sizes do not match

[brandonlangley]

Bug Description

I noticed an issue while testing the development of the MOOSE language server autocomplete capabilities.

The --check-input app used by the server crashes with a seg-fault when an Executioner/Quadrature block like:

[Executioner]
  type = Steady
  [Quadrature]

  []
[]

is autocompleted to add a custom_blocks parameter when there is not already a custom_orders present.

This can be observed by taking test/tests/quadrature/order/block-order.i which has an Executioner block like:

[Executioner]
  type = Steady
  [Quadrature]
    custom_blocks = '1 2'
    custom_orders = 'first second'
  []
[]

and just commenting out the custom_orders parameter and then running the input with or without --check-input.

[Executioner]
  type = Steady
  [Quadrature]
    custom_blocks = '1 2'
#   custom_orders = 'first second'
  []
[]

$> ~/projects/moose/test/moose_test-opt --check-input-i block-order.i
Segmentation fault: 11

I also built a debug MOOSE app executable and ran lldb which produced this backtrace:

* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x17)
  * frame #0: 0x0000000101f98004 libc++.1.dylib`std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >::basic_string(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) + 20
    frame #1: 0x00000001121a9cfc libmoose-dbg.0.dylib`libMesh::Order Moose::stringToEnum<libMesh::Order>(s=Summary Unavailable) at Conversion.C:200:15
    frame #2: 0x000000011176d928 libmoose-dbg.0.dylib`SetupQuadratureAction::act(this=0x0000000109696b98) at SetupQuadratureAction.C:70:28
    frame #3: 0x000000011174e304 libmoose-dbg.0.dylib`Action::timedAct(this=0x0000000109696b98) at Action.C:97:3
    frame #4: 0x000000011174dd30 libmoose-dbg.0.dylib`ActionWarehouse::executeActionsWithAction(this=0x000000010a85b248, task=Summary Unavailable) at ActionWarehouse.C:386:19
    frame #5: 0x000000011177de08 libmoose-dbg.0.dylib`ActionWarehouse::executeAllActions(this=0x000000010a85b248) at ActionWarehouse.C:346:5
    frame #6: 0x00000001122b5c14 libmoose-dbg.0.dylib`MooseApp::runInputFile(this=0x000000010a85ae18) at MooseApp.C:1128:21
    frame #7: 0x00000001122b1010 libmoose-dbg.0.dylib`MooseApp::run(this=0x000000010a85ae18) at MooseApp.C:1472:5
    frame #8: 0x000000010000f550 moose_test-dbg`main(argc=4, argv=0x000000016fdff8a0) at main.C:33:8
    frame #9: 0x000000010002908c dyld`start + 520

indicating the culprit is this loop in the act() method from framework/src/actions/SetupQuadratureAction.C.

 66    // add custom block-specific quadrature rules
 67    for (unsigned int i = 0; i < _custom_blocks.size(); i++)
 68      _problem->createQRules(_type,
 69                             _order,
 70                             Moose::stringToEnum<Order>(_custom_orders[i]),
 71                             Moose::stringToEnum<Order>(_custom_orders[i]),
 72                             _custom_blocks[i],
 73                             _allow_negative_qweights);

The loop i index used for Moose::stringToEnum<Order>(_custom_orders[i]) is limited by _custom_blocks.size().

But it is never verified beforehand that the size of _custom_orders is at least as much as _custom_blocks.

So this seg-faults and crashes when there is a custom_blocks parameter in the input without a custom_orders.

The fix should simply be adding an earlier check to act() that _custom_blocks.size() == _custom_orders.size().

Then the MOOSE language server will report that error message as diagnostics for this scenario instead of crashing.

Steps to Reproduce

Run --check-input on test/tests/quadrature/order/block-order.i and notice that it executes as expected.

$> ~/projects/moose/test/moose_test-opt --check-input -i block-order.i
Syntax OK

Then run it again after just commenting out the custom_orders parameter in the Executioner/Quadrature block.

$> ~/projects/moose/test/moose_test-opt --check-input-i block-order.i
Segmentation fault: 11

That test/tests/quadrature/order/block-order.i test input file with the modification causing the crash looks like:

[Mesh]
  [gmg]
    type = GeneratedMeshGenerator
    dim = 2
    nx = 1
    ny = 2
    xmin = 0
    xmax = 1
    ymin = 0
    ymax = 2
  []

  [bottom]
    type = SubdomainBoundingBoxGenerator
    input = gmg
    block_id = 1
    bottom_left = '0 0 0'
    top_right = '1 1 0'
  []
  [top]
    type = SubdomainBoundingBoxGenerator
    input = bottom
    block_id = 2
    bottom_left = '0 1 0'
    top_right = '1 2 0'
  []
  [middle]
    type = SideSetsBetweenSubdomainsGenerator
    input = top
    primary_block = 1
    paired_block = 2
    new_boundary = middle
  []
[]

[Postprocessors]
  [block1_qps]
    type = NumElemQPs
    block = 1
  []
  [block2_qps]
    type = NumElemQPs
    block = 2
  []
  [top_side_qps]
    type = NumSideQPs
    boundary = top
  []
  [bottom_side_qps]
    type = NumSideQPs
    boundary = bottom
  []
  [middle_side_qps]
    type = NumSideQPs
    boundary = middle
  []
[]

[Problem]
  type = FEProblem
  solve = false
[]

[Executioner]
  type = Steady
  [Quadrature]
    custom_blocks = '1 2'
#   custom_orders = 'first second'
  []
[]

[Outputs]
  execute_on = 'timestep_end'
  exodus = false
  csv = true
[]

Impact

The app that checks input for the language server crashes if custom_blocks is autocompleted prior to custom_orders.

It should report an error message that custom_blocks and custom_orders must be the same size instead of crashing.

[brandonlangley]

@permcody @loganharbour -

I noticed this crash while testing the new MOOSE language server autocomplete feature.

It should be a simple one-line fix of adding an input validation check as described above.

[dschwen]

I can address this.