Add --print_stacktrace_at_api_error.

Add --print_stacktrace_at_api_error.

Should be helpful in tracking down flutter/flutter#8612.

Prefer stack bounds from pthreads when available to be able to see frames below the Dart entry frame.

R=johnmccutchan@google.com

Committed: https://github.com/dart-lang/sdk/commit/91da7428f3026386ab30e41396b9221dd07afa2b

[rmacnak, 2017-04-12 20:29:24]

Description was changed from

==========
Add --print_stacktrace_at_api_error.

Get the true stack base on Linux and Mac from non-portal pthread functions so
the stacktrace can reach the interesting frames.
==========

to

==========
Add --print_stacktrace_at_api_error.

Should be helpful in tracking down flutter/flutter#8612.

Get the true stack base on Linux and Mac from non-portable pthread functions so
the stacktrace can reach the interesting frames.
==========

[rmacnak, 2017-04-12 20:33:07]

rmacnak@google.com changed reviewers:
+ johnmccutchan@google.com

[rmacnak, 2017-04-12 20:33:08]

E.g. from ./out/DebugX64/dart --print-stacktrace-at-api-error
./out/ReleaseX64/dart

I can see that the bad string happens during loading.

...
ApiError: Dart_NewStringFromUTF8 expects argument 'str' to be valid UTF-8.
Dumping native stack trace for thread a02
  [0x00000000009c2337] dart::Profiler::DumpStackTrace(bool)
  [0x00000000009c2337] dart::Profiler::DumpStackTrace(bool)
  [0x00000000008e8173] dart::ApiError::New(dart::String const&,
dart::Heap::Space)
  [0x000000000065f24f] dart::Api::NewError(char const*, ...)
  [0x000000000066d58b] Dart_NewStringFromUTF8
  [0x000000000055cace]
dart::bin::Loader::ProcessResultLocked(dart::bin::Loader*,
dart::bin::Loader::IOResult*)
  [0x000000000055c5a3] dart::bin::Loader::ProcessQueueLocked(bool
(*)(dart::bin::Loader*, dart::bin::Loader::IOResult*))
  [0x000000000055c525] dart::bin::Loader::BlockUntilComplete(bool
(*)(dart::bin::Loader*, dart::bin::Loader::IOResult*))
  [0x000000000055d51f] dart::bin::Loader::LibraryTagHandler(Dart_LibraryTag,
_Dart_Handle*, _Dart_Handle*)
  [0x000000000053355a] Unknown symbol
  [0x000000000053259d] dart::bin::RunMainIsolate(char const*,
dart::bin::CommandLineOptions*)
  [0x0000000000533f15] dart::bin::main(int, char**)
  [0x0000000000534419] Unknown symbol
-- End of DumpStackTrace
...

[Cutch, 2017-04-12 20:36:54]

LGTM but there is already a function on OSThread that will query the OS for the
thread stack bounds.

[rmacnak, 2017-04-12 20:53:22]

Description was changed from

==========
Add --print_stacktrace_at_api_error.

Should be helpful in tracking down flutter/flutter#8612.

Get the true stack base on Linux and Mac from non-portable pthread functions so
the stacktrace can reach the interesting frames.
==========

to

==========
Add --print_stacktrace_at_api_error.

Should be helpful in tracking down flutter/flutter#8612.

Prefer stack bounds from pthreads when available to be able to see frames below
the Dart entry frame.
==========

[rmacnak, 2017-04-12 20:55:13]

On 2017/04/12 20:36:54, Cutch wrote:
> LGTM but there is already a function on OSThread that will query the OS for
the
> thread stack bounds.

Removed my new function and just flipped the priority so the profiler prefers
the pthread bounds if available.

[rmacnak, 2017-04-12 21:09:24]

Description was changed from

==========
Add --print_stacktrace_at_api_error.

Should be helpful in tracking down flutter/flutter#8612.

Prefer stack bounds from pthreads when available to be able to see frames below
the Dart entry frame.
==========

to

==========
Add --print_stacktrace_at_api_error.

Should be helpful in tracking down flutter/flutter#8612.

Prefer stack bounds from pthreads when available to be able to see frames below
the Dart entry frame.

R=johnmccutchan@google.com

Committed:
https://github.com/dart-lang/sdk/commit/91da7428f3026386ab30e41396b9221dd07afa2b
==========

[rmacnak, 2017-04-12 21:09:26]

Committed patchset #4 (id:60001) manually as
91da7428f3026386ab30e41396b9221dd07afa2b (presubmit successful).

[siva, 2017-04-13 01:50:18]

asiva@google.com changed reviewers:
+ asiva@google.com

[siva, 2017-04-13 01:50:19]

DBC

https://codereview.chromium.org/2813283002/diff/60001/runtime/vm/profiler.cc
File runtime/vm/profiler.cc (right):

https://codereview.chromium.org/2813283002/diff/60001/runtime/vm/profiler.cc#...
runtime/vm/profiler.cc:1000: }
Why is this logic relevant only when for_crash is true. Shouldn't we be avoiding
recursion always.

https://codereview.chromium.org/2813283002/diff/60001/runtime/vm/thread_pool.cc
File runtime/vm/thread_pool.cc (right):

https://codereview.chromium.org/2813283002/diff/60001/runtime/vm/thread_pool....
runtime/vm/thread_pool.cc:453: }
Which situation causes the code inside the 'if' statement to be executed?