aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/main/java/com/google/devtools/build/lib/skylarkdebug
Commit message (Collapse)AuthorAge
* [Skylark] Use POJOs instead of dynamic proxies.Gravatar Taras Tsugrii2018-07-30
| | | | | | | | | | | | | | Java uses dynamically generated proxy classes to access annotation properties and their methods are ~7X slower than plain getters. According to async-profiler 50%+ of `convertArgumentList` method time is spent in dynamic proxy methods, so optimizing their performance makes sense. This also makes the model less anemic, since POJOs can actually provide business methods. Closes #5666. PiperOrigin-RevId: 206608812
* Skylark debugger: show contents of SkylarkValue objects when serializing.Gravatar brendandouglas2018-07-16
| | | | | | | Temporary solution finding the SkylarkCallable fields using reflection, mirroring the existing handling of ClassObject. PiperOrigin-RevId: 204779295
* Debug server: retrieve nested frame bindings tree lazily.Gravatar brendandouglas2018-06-29
| | | | | TYPE_CHANGE_OK=Proto hasn't yet been used PiperOrigin-RevId: 202705882
* Debug server logging: don't construct expensive debug-level log strings ↵Gravatar brendandouglas2018-06-27
| | | | | | unless necessary. PiperOrigin-RevId: 202317115
* Debug server debug logs: use EventHandler instead of Logger.Gravatar brendandouglas2018-06-26
| | | | | | | | Logger messages aren't printed to the console, they're written to /usr/local/google/tmp, and can be prohibitively large for these debug server logs. Instead I'm going with your original suggestion in https://github.com/bazelbuild/bazel/commit/b74922932b25a71c626b47ea9a9afb7dbc506cec, and selectively suppressing debug events by wrapping the EventHandler on the way in to SkylarkDebugServer. PiperOrigin-RevId: 202166571
* Fix concurrent modification exception while resuming all threads.Gravatar brendandouglas2018-06-26
| | | | PiperOrigin-RevId: 202151257
* Handle evaluation of statements, not just expressions.Gravatar brendandouglas2018-06-26
| | | | | | | | | | | | | | | Also handle statements in conditional breakpoints. This is more consistent with other common debuggers (e.g. java, python). Calls Parser#parseStatement with local parsing level, so some statement types aren't handled (e.g. load statements), which is broadly consistent with other debuggers. Assignment, augmented assignment, and return statements return a non-None value, and simple expression statements still return the result of evaluating the expression. TAG_CHANGE_OK=This proto has never yet been used TYPE_CHANGE_OK=This proto has never yet been used PiperOrigin-RevId: 202135678
* Go back to handling conditional breakpoints server side.Gravatar brendandouglas2018-06-25
| | | | | | | | I should have left it as it was -- doing it client-side is just too slow. ENUM_VALUE_OK=This proto has never yet been used PiperOrigin-RevId: 201957138
* Skylark debugging protocol: only track paused or stepping threads.Gravatar brendandouglas2018-06-21
| | | | | | | | | | | | | | | | | | | | | | | | - remove blaze-side thread creation/destruction hooks - remove ListThreads, ThreadStarted, ThreadEnded events from protocol - don't track unpaused, not stepping threads in ThreadHandler The threading model didn't provide useful information -- in practice, users never want to list currently-running threads, and the debug client doesn't need to list currently-paused threads, since it receives each ThreadPaused and ThreadContinued event, so its model is always up to date. Not tracking thread creation/destruction greatly simplifies the API, and reduces the blaze-side hooks -- it was also only semi-implemented, as plenty (/most?) skylark threads were never registered. The biggest cost to removing this is lack of nice thread names. In practice, I think the benefits greatly outweigh this cost. If it ever becomes a problem, there are other lighter-weight ways of communicating thread names. TAG_CHANGE_OK=This proto has never yet been used TYPE_CHANGE_OK=This proto has never yet been used PiperOrigin-RevId: 201532462
* Add an option to show verbose debugging logs.Gravatar brendandouglas2018-06-19
| | | | | | | | | | Turns out the event handler (BlazeCommandEventHandler) prints almost all event types, and I don't believe there's a way to tune it. We certainly don't want these messages printed to the console unless we're debugging the debugger, so turn them off by default. PiperOrigin-RevId: 201211355
* Skylark debugging protocol: remove conditional breakpoints, don't include ↵Gravatar brendandouglas2018-06-14
| | | | | | | | | | | | | | | | | | | | | frames in thread paused events. I started implementing conditional breakpoints server-side in unknown commit, but: - client-side implementations seem more common in debugging protocols - IntelliJ in particular has great support for client-side conditional breakpoints, but poor support for server-side - it's unnecessary extra complexity for the server -- simple line breakpoints + evaluation requests already give us conditional bps. Also removing frames from thread paused events. It results in poor performance for stepping and pausing (in which we get frame info for potentially dozens of threads), and again isn't usual for debuggers. Finally, ignore breakpoints when performing a client-requested evaluation. PiperOrigin-RevId: 200547972
* Skylark debugger: don't quote or escape strings when serializing.Gravatar brendandouglas2018-06-13
| | | | | | | A minor serialization improvement. I'm planning to refactor this code significantly, but wanted to get this in before I forgot. PiperOrigin-RevId: 200453925
* Skylark debugger: Fix NPE listing frames.Gravatar brendandouglas2018-06-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Environment$Continuation#caller is most definitely nullable in practice. I suspect it's a bug in skylark itself, but for now, just properly mark it nullable and handle it in the debugger. Stack trace from NPE: Caused by: java.lang.NullPointerException at com.google.devtools.build.lib.syntax.Environment.listFrames(Environment.java:1197) at com.google.devtools.build.lib.syntax.Environment.listFrames(Environment.java:81) at com.google.devtools.build.lib.skylarkdebug.server.ThreadHandler.listFrames(ThreadHandler.java:236) at com.google.devtools.build.lib.skylarkdebug.server.ThreadHandler.getThreadProto(ThreadHandler.java:345) at com.google.devtools.build.lib.skylarkdebug.server.ThreadHandler.pauseCurrentThread(ThreadHandler.java:289) at com.google.devtools.build.lib.skylarkdebug.server.ThreadHandler.pauseIfNecessary(ThreadHandler.java:203) at com.google.devtools.build.lib.skylarkdebug.server.SkylarkDebugServer.pauseIfNecessary(SkylarkDebugServer.java:158) at com.google.devtools.build.lib.skylarkdebug.server.SkylarkDebugServer$DebugAwareEval.exec(SkylarkDebugServer.java:262) at com.google.devtools.build.lib.syntax.UserDefinedFunction.call(UserDefinedFunction.java:91) at com.google.devtools.build.lib.syntax.BaseFunction.callWithArgArray(BaseFunction.java:462) at com.google.devtools.build.lib.syntax.BaseFunction.call(BaseFunction.java:440) at com.google.devtools.build.lib.analysis.skylark.SkylarkRuleConfiguredTargetUtil.lambda$buildRule$1(SkylarkRuleConfiguredTargetUtil.java:105) at com.google.devtools.build.lib.skylarkdebug.server.SkylarkDebugServer.runWithDebugging(SkylarkDebugServer.java:142) at com.google.devtools.build.lib.syntax.DebugServerUtils.runWithDebuggingIfEnabled(DebugServerUtils.java:70) at com.google.devtools.build.lib.analysis.skylark.SkylarkRuleConfiguredTargetUtil.buildRule(SkylarkRuleConfiguredTargetUtil.java:100) PiperOrigin-RevId: 200229036
* Skylark debugging protocol: include a 'stop reason' in ThreadPausedEvent.Gravatar brendandouglas2018-06-11
| | | | | | | | | | | | Pulls out a ThreadPausedState message, containing the previously separate 'isPaused' and 'locationIfPaused' information, as well as the stack frames and the reason for pausing, which is useful for debugging clients (e.g. IDEs might change focus when a breakpoint is hit, but not when all threads are paused). TAG_CHANGE_OK=This proto has never yet been used TYPE_CHANGE_OK=This proto has never yet been used PiperOrigin-RevId: 200109927
* Add some more logging to the debug server.Gravatar brendandouglas2018-06-11
| | | | | | Mostly 'debug' level logs that won't appear by default. PiperOrigin-RevId: 200072597
* Skylark debugging protocol: include frames information in ThreadPausedEvents.Gravatar brendandouglas2018-06-08
| | | | | | | This is almost always desirable -- if a thread is paused, the IDE expects to know the context. PiperOrigin-RevId: 199865078
* Add the skylark debugging options to the recognized 'build' options.Gravatar brendandouglas2018-06-08
| | | | | | | | | | Ensure debugging is turned off (and the server socket closed) when the command finishes, even if the blaze server is shut down. Finally, unpause all threads as part of shutting down the debug server, and also shut down the server if the client connection is lost. PiperOrigin-RevId: 199863623
* Skylark debugger: fix thread paused state and location not being properly ↵Gravatar brendandouglas2018-06-08
| | | | | | set in ThreadPausedEvents. PiperOrigin-RevId: 199847385
* Add an initial skylark debug server implementation.Gravatar Googler2018-06-07
| | | | | | | | | | | | Not intending this to be a complete implementation yet. Among the things still to do: - officially add support for debugging aspects, rules, etc., with corresponding tests. - handle breakpoints at return statements (an edge case which bypasses Eval). PiperOrigin-RevId: 199692670
* Initial implementation of a Skylark debug server API.Gravatar Googler2018-05-23
| | | | | | | | | | | | | | | | | | I've pulled out the API for separate review. It includes all hooks from blaze/skylark used by the debugger. Debuggable thread contexts are currently declared in 3 places: - BuildFileAST (top-level evaluation of BUILD files) - SkylarkRuleConfiguredTargetUtil (rules) - SkylarkAspectFactory (aspects) The purpose of declaring these contexts is so that the debugger can track currently-active threads (and stop tracking them when the task is completed). Details of the actual debugging server are in unknown commit. PiperOrigin-RevId: 197770547
* Skylark debug server: add serialization codeGravatar Googler2018-05-18
| | | | | | | Small self-contained part of the debug server (see unknown commit for the larger picture). PiperOrigin-RevId: 197140094
* Skylark debugging proto: add a 'pause thread' request/response.Gravatar Googler2018-05-07
| | | | | | | To handle a common debugging workflow where you want to pause execution of one/all threads. PiperOrigin-RevId: 195657472
* Skylark debugging proto changes.Gravatar Googler2018-05-04
| | | | | | | | | | | - add 'start debugging' request/response messages. The debug server will block until this request is received, allowing the client to perform initial setup (e.g. setting breakpoints) - support conditional breakpoints - add a column index to the Location message - rename 'line number' to 'line index', and specify that it's 0-based PiperOrigin-RevId: 195420363
* Change "LexicalBlock" back to "Scope".Gravatar allevato2017-10-20
| | | | | | The former is *technically* more formally correct, but other debuggers (VS Code and V8, among others) already use the term "scope" to refer to the same concept so aligning with those existing debuggers has value. PiperOrigin-RevId: 172778821
* Define protos for the Skylark debug server.Gravatar allevato2017-10-16
PiperOrigin-RevId: 172115471
generated by cgit v1.2.3 (git 2.39.1) at 2024-06-13 05:01:32 +0000