Deep recursion when running LoopParamOver test ?

[hzeller]

The LoopParamOver test crashes when running in debug mode or address sanitizer mode due to a very deep stack, which looks like a super-deep recursion (see below).
It might not show up in optimized mode as the stack-frames are probably smaller.

But given that the input is:

module Foo ();
 parameter P1 = 10;
 parameter P2 = P1 + P2;
 
endmodule


module top();
  parameter P3 = P1;
  parameter P2 = P3;
  parameter P1 = P2;
  Foo #(.P1(P2)) sub();
endmodule

... it is unclear where the deep recursion of more than 1000 frames is coming from

*** SIGSEGV (@0x7fffda3ee400) ***
PC: @     0x56438cb460a5  (unknown)  UHDM::ExprEval::reduceExpr()
    @     0x564390160598        256  FailureSignalHandler()
    @     0x7fdae39eb1c0  (unknown)  (unknown)
    @     0x56438c459f7d       1056  SURELOG::CompileHelper::reduceExpr()
    @     0x56438c45c7d3       1840  SURELOG::CompileHelper::getValue()
    @     0x56438c48a380         80  std::__u::__function::__policy_invoker<>::__call_impl<>()
    @     0x56438cb4475f        352  UHDM::ExprEval::getValue()
    @     0x56438cb468f0      12352  UHDM::ExprEval::reduceExpr()
    @     0x56438c459f7d       1056  SURELOG::CompileHelper::reduceExpr()
    @     0x56438c45c7d3       1840  SURELOG::CompileHelper::getValue()
    @     0x56438c48a380         80  std::__u::__function::__policy_invoker<>::__call_impl<>()
    @     0x56438cb4475f        352  UHDM::ExprEval::getValue()
    @     0x56438cb468f0      12352  UHDM::ExprEval::reduceExpr()
    @     0x56438c459f7d       1056  SURELOG::CompileHelper::reduceExpr()
    @     0x56438c45c7d3       1840  SURELOG::CompileHelper::getValue()
    @     0x56438c48a380         80  std::__u::__function::__policy_invoker<>::__call_impl<>()
    @     0x56438cb4475f        352  UHDM::ExprEval::getValue()
    @     0x56438cb468f0      12352  UHDM::ExprEval::reduceExpr()
    @     0x56438c459f7d       1056  SURELOG::CompileHelper::reduceExpr()
    @     0x56438c45c7d3       1840  SURELOG::CompileHelper::getValue()
    @     0x56438c48a380         80  std::__u::__function::__policy_invoker<>::__call_impl<>()
    @     0x56438cb4475f        352  UHDM::ExprEval::getValue()
    @     0x56438cb468f0      12352  UHDM::ExprEval::reduceExpr()
    @     0x56438c459f7d       1056  SURELOG::CompileHelper::reduceExpr()
    @     0x56438c45c7d3       1840  SURELOG::CompileHelper::getValue()
    @     0x56438c48a380         80  std::__u::__function::__policy_invoker<>::__call_impl<>()
    @     0x56438cb4475f        352  UHDM::ExprEval::getValue()
    @     0x56438cb468f0      12352  UHDM::ExprEval::reduceExpr()
    @     0x56438c459f7d       1056  SURELOG::CompileHelper::reduceExpr()
    @     0x56438c45c7d3       1840  SURELOG::CompileHelper::getValue()
    @     0x56438c48a380         80  std::__u::__function::__policy_invoker<>::__call_impl<>()
    @     0x56438cb4475f        352  UHDM::ExprEval::getValue()
    @     0x56438cb468f0      12352  UHDM::ExprEval::reduceExpr()
    @     0x56438c459f7d       1056  SURELOG::CompileHelper::reduceExpr()
    @     0x56438c45c7d3       1840  SURELOG::CompileHelper::getValue()
    @     0x56438c48a380         80  std::__u::__function::__policy_invoker<>::__call_impl<>()
    @     0x56438cb4475f        352  UHDM::ExprEval::getValue()
    @     0x56438cb468f0      12352  UHDM::ExprEval::reduceExpr()
    @     0x56438c459f7d       1056  SURELOG::CompileHelper::reduceExpr()
    @     0x56438c45c7d3       1840  SURELOG::CompileHelper::getValue()
    @     0x56438c48a380         80  std::__u::__function::__policy_invoker<>::__call_impl<>()
    @     0x56438cb4475f        352  UHDM::ExprEval::getValue()
    @     0x56438cb468f0      12352  UHDM::ExprEval::reduceExpr()
    @     0x56438c459f7d       1056  SURELOG::CompileHelper::reduceExpr()
    @     0x56438c45c7d3       1840  SURELOG::CompileHelper::getValue()
    @     0x56438c48a380         80  std::__u::__function::__policy_invoker<>::__call_impl<>()
    @     0x56438cb4475f        352  UHDM::ExprEval::getValue()
    @     0x56438cb468f0      12352  UHDM::ExprEval::reduceExpr()
    @     0x56438c459f7d       1056  SURELOG::CompileHelper::reduceExpr()
    @     0x56438c45c7d3       1840  SURELOG::CompileHelper::getValue()
    @     0x56438c48a380         80  std::__u::__function::__policy_invoker<>::__call_impl<>()
    @     0x56438cb4475f        352  UHDM::ExprEval::getValue()
    @     0x56438cb468f0      12352  UHDM::ExprEval::reduceExpr()
    @     0x56438c459f7d       1056  SURELOG::CompileHelper::reduceExpr()
    @     0x56438c45c7d3       1840  SURELOG::CompileHelper::getValue()
    @     0x56438c48a380         80  std::__u::__function::__policy_invoker<>::__call_impl<>()
    @     0x56438cb4475f        352  UHDM::ExprEval::getValue()
    @     0x56438cb468f0      12352  UHDM::ExprEval::reduceExpr()
    @     0x56438c459f7d       1056  SURELOG::CompileHelper::reduceExpr()
    @     0x56438c45c7d3       1840  SURELOG::CompileHelper::getValue()
    @     0x56438c48a380         80  std::__u::__function::__policy_invoker<>::__call_impl<>()
    @     0x56438cb4475f        352  UHDM::ExprEval::getValue()
    @     0x56438cb468f0      12352  UHDM::ExprEval::reduceExpr()
    @     0x56438c459f7d       1056  SURELOG::CompileHelper::reduceExpr()
    @ ... and at least 1000 more frames

[hs-apotell]

This recursion comes from the evaluation logic. The logic to identify circular dependence is based on it reaching 1000 attempts without success.

[hzeller]

That sounds dangerous and problematic. Doesn't the usual 'no change in the last iteration' be sufficient ?

[hs-apotell]

Surelog/src/DesignCompile/CompileHelper.cpp

Lines 78 to 82 in 103bf15

	#if defined(_WIN32)
	constexpr int32_t kMaxAllowedStackDepth = 100;
	#else
	constexpr int32_t kMaxAllowedStackDepth = 1000;
	#endif

I have to reduce the limit down to 100 for Windows since the stack doesn't grow automatically as it does for Linux. The current stack size on Windows is 64 MB and with that limit only 100 iterations were possible. The situation is worse for Clang since the stack requirement for Clang is larger than both cl and gcc.

[hs-apotell]

Doesn't the usual 'no change in the last iteration' be sufficient ?

Yes, but I am just stating the facts. The current implementation relies on number of attempts to evaluate. Sure, there is lot of room to improve on this logic.

[alaindargelas]

The correct fix requires way too many changes in all the functions involved in expression evaluation both on the UHDM and Surelog side. Just for the sake of detecting an error condition that is far from the norm. Maybe limiting to 100 when running valgrind would be enough? We are attempting here to run valgrind on a negative test that is built to create a corner case behavior. Not the typical usage...

[hs-apotell]

The difference in number of allowed iterations (100 for Windows & 1000 for others) is the reason for current build failures in CI. The number of ref_obj instances created are very different across the platforms. Windows builds won't succeed with anything higher.

@alaindargelas How do you want to deal with this?
@hzeller FYI

[alaindargelas]

Create 2 log files, that is what is typically done. One per OS when there is OS specific diffs.