Segmentation fault in code involving generic functions

[nightscape]

Hi all,

I'm writing a library that allows to build a Directed Acyclic Graph of descriptions of Stream transformations which can then be applied to actual input streams.
One of the core classes is a StreamNode<T> from which a Stream<T> will be created, optionally allowing a StreamTransformer<T> to be retrieved and applied.
As the graph has different generic parameters T in StreamNodes, I need to go through some hoops to get the Dart compiler accept my code.
In my latest iteration, I thought I had made progress on the issue, but instead I get the Dart to crash with an error like this

===== CRASH =====
si_signo=Segmentation fault([11](https://github.com/nightscape/stream_graph.dart/runs/5080365009?check_suite_focus=true#step:6:11)), si_code=1, si_addr=0x4cf0039015f
version=2.16.0 (stable) (Mon Jan 31 15:28:59 2022 +0100) on "linux_x64"
pid=1690, thread=1728, isolate_group=main(0x55a6da5b6800), isolate=main(0x55a6dc[14](https://github.com/nightscape/stream_graph.dart/runs/5080365009?check_suite_focus=true#step:6:14)e000)
isolate_instructions=55a6d7f92540, vm_instructions=55a6d7f92540
  pc 0x000055a6d80bd7b4 fp 0x00007fd3734fd9c0 dart::BootstrapNatives::DN_Internal_boundsCheckForPartialInstantiation(dart::Thread*, dart::Zone*, dart::NativeArguments*)+0x44
  pc 0x000055a6d8[17](https://github.com/nightscape/stream_graph.dart/runs/5080365009?check_suite_focus=true#step:6:17)0924 fp 0x00007fd3734fda40 dart::NativeEntry::BootstrapNativeCallWrapper(_Dart_NativeArguments*, void (*)(_Dart_NativeArguments*))+0xb4
  pc 0x00007fd377502654 fp 0x00007fd3734fda80 Unknown symbol

The full stack trace can be seen here:
https://github.com/nightscape/stream_graph.dart/runs/5080365009?check_suite_focus=true

I can reproduce this locally on a Mac ARM64 and in an AMD64 Linux env in the Github actions.
Is this something worth looking into, or shall I just go looking for a solution that doesn't make Dart crash?

[leafpetersen]

Transferring to the SDK repo. cc @a-siva

[a-siva]

@nightscape thanks for filing the issue, is it is possible for us to get instructions on how we can get a local reproduction of the crash

[a-siva]

@nightscape any possibilities of getting a setup for reproduction

[nightscape]

@a-siva Sorry for taking so long to respond, this slipped under the radar.
The commands to reproduce would be

git clone https://github.com/nightscape/stream_graph.dart.git
cd ./stream_graph.dart/
git checkout a896451677aeb55eeb73bd5959534df8add27164
dart test

[a-siva]

Thanks for the repro.
I ran a debug version of dart and the crash backtrace is as follows

00:02 +0: loading test/stream_graph_test.dart                                   ../../runtime/vm/object.cc: 3366: error: expected: !sup_type_arg.IsNull()
version=2.18.0-edge.e9e48993f8056f2a8879adc01901cf81ba7fae6f (be) (Mon Apr 25 21:47:14 2022 +0000) on "linux_x64"
pid=4158689, thread=4158713, isolate_group=main(0x55ac53e61000), isolate=main(0x55ac557e4000)
isolate_instructions=55ac51239f20, vm_instructions=55ac51239f20
  pc 0x000055ac51642b4c fp 0x00007f89cebfdda0 dart::Profiler::DumpStackTrace(void*)+0x7c
  pc 0x000055ac5123a0d4 fp 0x00007f89cebfde80 dart::Assert::Fail(char const*, ...) const+0x84
  pc 0x000055ac51558edc fp 0x00007f89cebfdee0 dart::Class::ComputeNumTypeArguments() const+0x37c
  pc 0x000055ac51558f70 fp 0x00007f89cebfdf10 dart::Class::NumTypeArguments() const+0x50
  pc 0x000055ac51479c95 fp 0x00007f89cebfdf70 dart::ClassFinalizer::FinalizeType(dart::AbstractType const&, dart::ClassFinalizer::FinalizationKind, dart::ZoneGrowableHandlePtrArray<dart::AbstractType const>*)+0x255
  pc 0x000055ac514797ae fp 0x00007f89cebfdff0 dart::ClassFinalizer::ExpandAndFinalizeTypeArguments(dart::Zone*, dart::AbstractType const&, dart::ZoneGrowableHandlePtrArray<dart::AbstractType const>*)+0x25e
  pc 0x000055ac51479eef fp 0x00007f89cebfe050 dart::ClassFinalizer::FinalizeType(dart::AbstractType const&, dart::ClassFinalizer::FinalizationKind, dart::ZoneGrowableHandlePtrArray<dart::AbstractType const>*)+0x4af
  pc 0x000055ac514774e0 fp 0x00007f89cebfe100 dart::ClassFinalizer::FinalizeTypesInClass(dart::Class const&)+0x240
  pc 0x000055ac514770c2 fp 0x00007f89cebfe2b0 dart::ClassFinalizer::ProcessPendingClasses()+0x252
  pc 0x000055ac514fe32a fp 0x00007f89cebfe810 dart::kernel::KernelLoader::LoadEntireProgram(dart::kernel::Program*, bool)+0x79a

[a-siva]

//cc @alexmarkov

[alexmarkov]

There are 2 bugs triggered on this code:

1. Assertion failure in DEBUG mode during finalization. It is caused by an incorrect assertion and unlikely to affect users.

Small repro:

abstract class GraphNode extends Comparable<dynamic> {
  int compareTo(dynamic other) => 0;
}

abstract class StreamNode<T> extends GraphNode {}

class TransformNode<S, T> extends StreamNode<T> {}

main() {
  print(TransformNode());
}

2. Crash around _boundsCheckForPartialInstantiation.

Small repro:

void Function<T>()? genericFunction;

void foo(void Function()? arg) {
  print(arg);
}

void main() {
  foo(genericFunction);
}

The problem is that CFE creates Instantiation node which takes a nullable value, but VM doesn't expect to see null as an argument to that node (it expects to see a generic closure which should be instantiated using the Instantiation.typeArguments). The VM implementation of that node didn't expect null since it was added in https://dart-review.googlesource.com/c/sdk/+/34400/.

@johnniwinther Could you clarify if this is a valid AST and VM should support this case?
@leafpetersen What would be a correct behavior in this case? A compile-time error, run-time error or silently "instantiating" null?

[leafpetersen]

This is related to this issue.

I would have expected this code to be a static error (just as implicitly tearing off a call method from a nullable value is a static error), but it seems that neither the analyzer nor the cfe emits an error there.

We could make the breaking change to make this an error, or we could specify these to be null aware (in which case the behavior would be essentially to produce null if the value was null, and otherwise produce the generic instantiation. Either way it seems like we should be consistent. cc @munificent @eernstg @lrhn

[eernstg]

I could not find any rules about generic function instantiation in the nnbd feature spec. The upcoming update to the language specification where null safety is integrated specifies that generic function instantiation can only take place when the function being instantiated has a function type, not a type of the form T? for any T. So we should get a compile-time error according to the ongoing specification work.

However, it would seem reasonable to generalize generic function instantiation to be null-aware if we do the same thing for call insertion, cf. dart-lang/language#1333.

[johnniwinther]

@alexmarkov The CFE shouldn't generate instantiation on a nullable expressions. It should either be an error or converted into genericFunction != null ? genericFunction<dynamic> : null.

[alexmarkov]

Debug assertion is fixed in 609ba96.

@johnniwinther Could you take a stab at fixing the 2nd bug in the CFE?

[johnniwinther]

Fix for the CFE in progress: https://dart-review.googlesource.com/c/sdk/+/242869

[mkustermann]

I believe this issue was fixed by @johnniwinther in 7ab8930. Closing.