Can we merge native and Dart stack traces?

[ghost]

When we get stack traces that include both native and Dart stacks, the current format prints first the native, then the Dart stack, as seen below.
The native stack contains the Dart portion of the stack, but each frame is simply labelled as Unknown symbol. Each frame does however correspond directly to the frames of the Dart stack, which has each frame labelled. printed second.

From the below example it seems trivial to merge the two traces together to produce one, more helpful trace.
Are there any cases where we can't - or perhaps shouldn't - do so?

version=2.15.0-edge.0cd81027f434a0a43bbd800288f3e255358aae3d (be) (Tue Oct 19 13:09:46 2021 +0000) on "linux_x64"
pid=670201, thread=670217, isolate_group=main(0x55f804ac5000), isolate=main(0x55f8052c5000)
isolate_instructions=55f801959200, vm_instructions=55f801959200
  pc 0x000055f801d51fcc fp 0x00007f9f0d4fe350 dart::Profiler::DumpStackTrace(void*)+0x7c
  pc 0x000055f8019593b4 fp 0x00007f9f0d4fe430 dart::Assert::Fail(char const*, ...) const+0x84
  pc 0x000055f801c445e0 fp 0x00007f9f0d4fe5a0 dart::NativeEntry::LinkNativeCall(_Dart_NativeArguments*)+0x5f0
  pc 0x00007f9f135029b4 fp 0x00007f9f0d4fe5e0 Unknown symbol
  pc 0x00007f9f10ca2f77 fp 0x00007f9f0d4fe618 Unknown symbol
  pc 0x00007f9f10ca2ed3 fp 0x00007f9f0d4fe648 Unknown symbol
  pc 0x00007f9f10ca2e29 fp 0x00007f9f0d4fe670 Unknown symbol
  pc 0x00007f9f10ca2d49 fp 0x00007f9f0d4fe6d0 Unknown symbol
  pc 0x00007f9f10ca1b60 fp 0x00007f9f0d4fe708 Unknown symbol
  pc 0x00007f9f10ca18dc fp 0x00007f9f0d4fe770 Unknown symbol
  pc 0x00007f9f10ca1140 fp 0x00007f9f0d4fe7c0 Unknown symbol
  pc 0x00007f9f13502d4d fp 0x00007f9f0d4fe838 Unknown symbol
  pc 0x000055f801bab264 fp 0x00007f9f0d4fe8d0 dart::DartEntry::InvokeCode(dart::Code const&, unsigned long, dart::Array const&, dart::Array const&, dart::Thread*)+0x134
  pc 0x000055f801baae2e fp 0x00007f9f0d4fe940 dart::DartEntry::InvokeFunction(dart::Function const&, dart::Array const&, dart::Array const&, unsigned long)+0x16e
  pc 0x000055f801bae038 fp 0x00007f9f0d4fe9a0 dart::DartLibraryCalls::HandleMessage(long, dart::Instance const&)+0x128
  pc 0x000055f801be4ac8 fp 0x00007f9f0d4fea80 dart::IsolateMessageHandler::HandleMessage(std::__2::unique_ptr<dart::Message, std::__2::default_delete<dart::Message> >)+0x3a8
  pc 0x000055f801c24908 fp 0x00007f9f0d4feb10 dart::MessageHandler::HandleMessages(dart::MonitorLocker*, bool, bool)+0x218
  pc 0x000055f801c256e9 fp 0x00007f9f0d4feb90 dart::MessageHandler::TaskCallback()+0x369
  pc 0x000055f801e06e6b fp 0x00007f9f0d4fec30 dart::ThreadPool::WorkerLoop(dart::ThreadPool::Worker*)+0x1fb
  pc 0x000055f801e07827 fp 0x00007f9f0d4fec80 dart::ThreadPool::Worker::Main(unsigned long)+0x147
  pc 0x000055f801d491a4 fp 0x00007f9f0d4fedd0 out/DebugX64/dart+0x23411a4
-- End of DumpStackTrace
  pc 0x0000000000000000 fp 0x00007f9f0d4fe5e0 sp 0x0000000000000000 [Stub] CallBootstrapNative
  pc 0x00007f9f10ca2f77 fp 0x00007f9f0d4fe618 sp 0x00007f9f0d4fe5f0 [Unoptimized] _printString@18024710
  pc 0x00007f9f10ca2ed3 fp 0x00007f9f0d4fe648 sp 0x00007f9f0d4fe628 [Unoptimized] main
  pc 0x00007f9f10ca2e29 fp 0x00007f9f0d4fe670 sp 0x00007f9f0d4fe658 [Unoptimized] main
  pc 0x00007f9f10ca2d49 fp 0x00007f9f0d4fe6d0 sp 0x00007f9f0d4fe680 [Unoptimized] _Closure@0150898.dyn:call
  pc 0x00007f9f10ca1b60 fp 0x00007f9f0d4fe708 sp 0x00007f9f0d4fe6e0 [Unoptimized] _delayEntrypointInvocation@1026248.<anonymous closure>
  pc 0x00007f9f10ca18dc fp 0x00007f9f0d4fe770 sp 0x00007f9f0d4fe718 [Unoptimized] _Closure@0150898.dyn:call
  pc 0x00007f9f10ca1140 fp 0x00007f9f0d4fe7c0 sp 0x00007f9f0d4fe780 [Unoptimized] _RawReceivePortImpl@1026248._handleMessage@1026248
  pc 0x00007f9f13502d4d fp 0x00007f9f0d4fe838 sp 0x00007f9f0d4fe7d0 [Stub] InvokeDartCode

[rmacnak-google]

The second phase that symbolizes the Dart frames requires heap walks. It makes assumptions about the current safepoint state and walkability of the heap. It also uses a different stack walker that will succeed in iterating Dart frames even if the C stack walker fails from a lack of frame pointers. The stack dumps are split into two phases so that if the second phase fails and produces a second crash, we at least have the C frames.

[mraleph]

@rmacnak-google We could maintain an off-Dart-heap structure (built through code observer interface) which could be used to symbolize Dart portion of the stack without ever touching the heap, similar to how profilers do that.

[ghost]

The stack dumps are split into two phases so that if the second phase fails and produces a second crash, we at least have the C frames.

Ah, right. So I suppose we can't rely on information from the second phase as long as we can't guarantee that the second phase does not crash.

@mraleph, am I understanding it correctly that the case we'd avoid in that case is heap corruption of the symbol information?

[mraleph]

@cskau-g we'd avoid accessing Dart heap directly - which is something that can only be safely done if you are in the right state. (also Dart heap might be in a broken state when a crash occurs - if we symbolise using off-heap information then our symbolisation is more likely to succeed because our simpler of-heap structure is likely going to be non-corrupt even if Dart heap structure is corrupt).