DumpStackTrace when using pub run

[travissanderson-wf]

I am using the dart_dev library via pub run and getting a stack trace dump:

Dumping native stack trace for thread 50f
  [0x0000000106704b83] Dart_ParseAll
  [0x0000000106704b83] Dart_ParseAll
  [0x00000001067ea126] Dart_ParseAll
  [0x000000010684cad2] Dart_ParseAll
  [0x00000001067ea809] Dart_ParseAll
  [0x000000010684c62c] Dart_ParseAll
  [0x00000001067ebb69] Dart_ParseAll
  [0x000000010684c670] Dart_ParseAll
  [0x000000010684fd4e] Dart_ParseAll
  [0x00000001067f14cf] Dart_ParseAll
  [0x000000010684cddb] Dart_ParseAll
  [0x000000010684b9b7] Dart_ParseAll
  [0x000000010684e822] Dart_ParseAll
-- End of DumpStackTrace

This is the second time I've run into the problem.. it went away when I threw out my pub cache and rebooted my machine last time. I can use pub serve directly but trying to proxy it thru a dart_dev task results in the stack trace. Same for running tests. If there are more verbose logs I can get, please let me know! Thanks.

[travissanderson-wf]

Actually, this may be specific to some code changes I am making as our CI environment is encountering the same thing. I'll report back if/when I figure it out.

[travissanderson-wf]

The error in CI has more detail (it's a different command too). I'm working on moving our codebase to strong mode if that is a clue...

	Dumping native stack trace for thread 2d7
	  [0x000000000078e7f1] dart::TypeParameter::set_parameterized_class(dart::Class const&) const
	  [0x000000000078e7f1] dart::TypeParameter::set_parameterized_class(dart::Class const&) const
	  [0x00000000009605c8] dart::TypeParameter::ReadFrom(dart::SnapshotReader*, long, long, dart::Snapshot::Kind, bool)
	  [0x00000000008c89a7] dart::SnapshotReader::ReadObjectImpl(long, bool, long, long)
	  [0x00000000009609b8] dart::TypeArguments::ReadFrom(dart::SnapshotReader*, long, long, dart::Snapshot::Kind, bool)
	  [0x00000000008c84d6] dart::SnapshotReader::ReadObjectImpl(long, bool, long, long)
	  [0x0000000000964cac] dart::Function::ReadFrom(dart::SnapshotReader*, long, long, dart::Snapshot::Kind, bool)
	  [0x00000000008c851a] dart::SnapshotReader::ReadObjectImpl(long, bool, long, long)
	  [0x00000000008cb8bd] dart::SnapshotReader::ArrayReadFrom(long, dart::Array const&, long, long)
	  [0x0000000000963438] dart::Array::ReadFrom(dart::SnapshotReader*, long, long, dart::Snapshot::Kind, bool)
	  [0x00000000008c8cff] dart::SnapshotReader::ReadObjectImpl(long, bool, long, long)
	  [0x00000000008cb4d7] dart::SnapshotReader::ReadObject()
	  [0x00000000008cb628] dart::SnapshotReader::ReadScriptSnapshot()
	-- End of DumpStackTrace

[travissanderson-wf]

I've narrowed down the cause but have no idea why it should be the cause. If I depend on latest master of webdriver.dart via git, I get the stack trace dump. If I have a local checkout of the same commit and use a path dependency, I get no dump and everything seems to work.

[fsc8000]

Which version of Dart SDK are you using? This looks similar to #28072

[travissanderson-wf]

Stable release of 1.21.0

[fsc8000]

Ok, it seems that the fix has not been merged to the stable branch yet. @a-siva @crelier Could you file a merge-request?

If you have the possibility to try the dev-channel version, it should be fixed there.

[travissanderson-wf]

I'll give it a whirl tomorrow. Thanks!

[a-siva]

This is a duplicate of #28072

[travissanderson-wf]

We've verified that the latest development build resolves the issue, do you know of any workaround in the stable build? If not, we think it is the latest tag of webdriver.dart that introduced usage of the methods+generics of Dart 1.21 - google/webdriver.dart#131. As I stated above, it's strange because the same code as a local dependency doesn't seem to trigger the issue.

[travissanderson-wf]

@fsc8000 would this fix be included in a patch release of the 1.21 line?

[fsc8000]

Yes, the next patch release for 1.21 would include the fix.

[whesse]

MergeToStable issue is #28375 . 1.21.1 will be created with the fix.

[whesse]

New stable version 1.21.1 has been released with the fix for this issue.

[dgrove]

Given Bill's comment, closing.

[travissanderson-wf]

Thanks, FWIW I updated today and verified the previous tag of webdriver.dart no longer triggers this error for us.