Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Debugging the engine
This page has some hints about debugging the engine.
See also Crashes for advice on handling engine crashes (specifically around obtaining stack traces, and reporting crashes in AOT Dart code).
Tracing OpenGL calls in Skia
All OpenGL calls in Skia are guarded by either the
GR_GL_CALL_RET_NOERRCHECK macros. Trace events may be added in these macros to trace all GL calls made by Skia, for example in a patch like this.
Due to the number of events traced to the timeline, the trace buffer may be filled up very quickly. Unless you want to see only the traces for the past few frames, use an endless trace buffer (
flutter --trace-startup turns on an endless trace buffer).
Also, make sure to run your application with the
Debugging iOS builds with Xcode
If you open your iOS .xcodeproject or .xcworkspace in Xcode, you can set breakpoints e.g. in
main.m. From there, you can use
lldb to set a breakpoint on the relevant engine source, e.g.
(lldb) br set -f FlutterViewController.mm -l 123.
Debugging Android builds with gdb
Logging in the engine
Flutter tool will by default parse out any non-error output from the engine. Error logs will be displayed. Logging is handled though the FML library's