| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
Temporary solution finding the SkylarkCallable fields using reflection,
mirroring the existing handling of ClassObject.
PiperOrigin-RevId: 204779295
|
|
|
|
|
| |
TYPE_CHANGE_OK=Proto hasn't yet been used
PiperOrigin-RevId: 202705882
|
|
|
|
|
|
| |
unless necessary.
PiperOrigin-RevId: 202317115
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
PiperOrigin-RevId: 202151257
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- 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
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
A minor serialization improvement. I'm planning to refactor this code
significantly, but wanted to get this in before I forgot.
PiperOrigin-RevId: 200453925
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
Mostly 'debug' level logs that won't appear by default.
PiperOrigin-RevId: 200072597
|
|
|
|
|
|
|
| |
This is almost always desirable -- if a thread is paused, the IDE expects
to know the context.
PiperOrigin-RevId: 199865078
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
set in ThreadPausedEvents.
PiperOrigin-RevId: 199847385
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
Small self-contained part of the debug server (see unknown commit for the
larger picture).
PiperOrigin-RevId: 197140094
|
|
|
|
|
|
|
| |
To handle a common debugging workflow where you want to pause
execution of one/all threads.
PiperOrigin-RevId: 195657472
|
|
|
|
|
|
|
|
|
|
|
| |
- 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
|
|
|
|
|
|
| |
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
|
|
PiperOrigin-RevId: 172115471
|