Chromium Code Reviews
|
|
Chromium Code Reviews
Issue
1375933003:
Add SetAbortOnUncaughtExceptionCallback API (Closed)
|
Created:
5 years, 2 months ago by julien.gilli Modified:
5 years, 2 months ago CC:
v8-reviews_googlegroups.com, Paweł Hajdan Jr. Base URL:
git@github.com:v8/v8.git@master Target Ref:
refs/pending/heads/master Project:
v8 Visibility:
Public. |
DescriptionAdd SetAbortOnUncaughtExceptionCallback API
The --abort-on-uncaught-exception command line switch makes
Isolate::Throw abort if the error being thrown cannot be caught by a
try/catch block.
Embedders may want to use other mechanisms than try/catch blocks to
handle uncaught exceptions. For instance, Node.js has "domain" objects
that have error handlers that can handle uncaught exception like
following:
var d = domain.create();
d.on('error', function onError(err) {
console.log('Handling error');
});
d.run(function() {
throw new Error("boom");
});
These error handlers are called by isolates' message listeners.
If --abort-on-uncaught-exception is *not* used, the isolate's
message listener will be called, which will in turn call the domain's
error handler. The process will output 'Handling error' and will exit
successfully (not due to an uncaught exception). This is the behavior
that Node.js users expect.
However, if --abort-on-uncaught-exception is used and when throwing an
error within a domain that has an error handler, the process will abort
and the domain's error handler will not be called. This is not the
behavior that Node.js users expect.
Having a SetAbortOnUncaughtExceptionCallback API allows embedders to
determine when it's not appropriate to abort and instead handle the
exception via the isolate's message listener.
In the example above, Node.js would set a custom callback with
SetAbortOnUncaughtExceptionCallback that would be implemented as
following (the sample code has been simplified to remove what's not
relevant to this change):
bool ShouldAbortOnUncaughtException(Isolate* isolate) {
return !IsDomainActive();
}
Now when --abort-on-uncaught-exception is used, Isolate::Throw would
call that callback and determine that it should not abort if a domain
with an error handler is active. Instead, the isolate's message listener
would be called and the error would be handled by the domain's error
handler.
I believe this can also be useful for other embedders.
BUG=
R=bmeurer@chromium.org
Committed: https://crrev.com/1ee712ab8687e5f4dec93d45da068d37d28feb8b
Cr-Commit-Position: refs/heads/master@{#31111}
Patch Set 1 #
Total comments: 22
Patch Set 2 : Update according to code review #
Total comments: 10
Patch Set 3 : Update after second code review #
Messages
Total messages: 28 (4 generated)
On 2015/09/30 22:09:56, julien.gilli wrote: Please note that I'm submitting this as a request for comments and feedback. Also, I've tried to use gtest "death tests" in the "AbortOnUncaughtExceptionDefault" test in test/cctest/test-abort-on-uncaught-exception.cc to make sure that by default, V8 aborts when throwing an uncaught exception. However, I haven't been able to use gtest's death tests macros cleanly within test/cctest tests. I would need to link cctest against test-utils.cc to use the TestWithIsolate class' implementation, but I'm not sure this is the way to go. Any guidance on this would be appreciated if the API addition suggested sounds like a good idea.
bmeurer@chromium.org changed reviewers: + jochen@chromium.org, verwaest@chromium.org
API changes should be reviewed by the bindings team.
mstarzinger@chromium.org changed reviewers: + mstarzinger@chromium.org
I don't have a strong opinion on whether we want to support this as part of the API or not. I'll defer to the bindings folks (i.e. Jochen) to make that call. But I can do a review. https://codereview.chromium.org/1375933003/diff/1/include/v8.h File include/v8.h (right): https://codereview.chromium.org/1375933003/diff/1/include/v8.h#newcode5383 include/v8.h:5383: * If FLAG_abort_on_uncaught_exception is true, then V8 will abort if either: nit: The "FLAG_abort_on_uncaught_exception" is an internal variable, in the public API I would rather reference the "--abort-on-uncaught-exception" command line flag, as that is something that the embedder can actually control. Also I would rephrase the wording slightly to say "no internal handler is predicted to catch the exception", because whether a finally-handler will re-throw an exception or not is essentially an undecidable problem and hence cannot be predicted at throw time. We essentially "predict" every finally-handler will re-throw, which is just an assumption/guess on V8's part. Also it might make sense to mentioned explicitly that if "--abort-on-uncaught-exception" is not set, then the callback will never fire. https://codereview.chromium.org/1375933003/diff/1/src/api.cc File src/api.cc (right): https://codereview.chromium.org/1375933003/diff/1/src/api.cc#newcode7106 src/api.cc:7106: nit: Two empty newlines between top-level declarations. https://codereview.chromium.org/1375933003/diff/1/src/api.cc#newcode7112 src/api.cc:7112: nit: Two empty newlines between top-level declarations. https://codereview.chromium.org/1375933003/diff/1/src/isolate.cc File src/isolate.cc (right): https://codereview.chromium.org/1375933003/diff/1/src/isolate.cc#newcode1019 src/isolate.cc:1019: // abort nit: Punctuation. https://codereview.chromium.org/1375933003/diff/1/src/isolate.h File src/isolate.h (right): https://codereview.chromium.org/1375933003/diff/1/src/isolate.h#newcode658 src/isolate.h:658: typedef bool (*AbortOnUncaughtExceptionCallback)(v8::Isolate*); The "v8::AbortOnUncaughtExceptionCallback" typedef should be available here, no need to re-typedef it in the internal namespace IMHO. https://codereview.chromium.org/1375933003/diff/1/test/cctest/cctest.gyp File test/cctest/cctest.gyp (right): https://codereview.chromium.org/1375933003/diff/1/test/cctest/cctest.gyp#newc... test/cctest/cctest.gyp:179: 'test-abort-on-uncaught-exception.cc' nit: Please keep this list alpha-sorted.
https://codereview.chromium.org/1375933003/diff/1/include/v8.h File include/v8.h (right): https://codereview.chromium.org/1375933003/diff/1/include/v8.h#newcode5383 include/v8.h:5383: * If FLAG_abort_on_uncaught_exception is true, then V8 will abort if either: On 2015/10/01 16:34:38, Michael Starzinger wrote: > nit: The "FLAG_abort_on_uncaught_exception" is an internal variable, in the > public API I would rather reference the "--abort-on-uncaught-exception" command > line flag, as that is something that the embedder can actually control. > > Also I would rephrase the wording slightly to say "no internal handler is > predicted to catch the exception", because whether a finally-handler will > re-throw an exception or not is essentially an undecidable problem and hence > cannot be predicted at throw time. We essentially "predict" every > finally-handler will re-throw, which is just an assumption/guess on V8's part. > > Also it might make sense to mentioned explicitly that if > "--abort-on-uncaught-exception" is not set, then the callback will never fire. Actually, I just realized: We conservatively assume any finally clause will behave as if the exception were consumed. But that doesn't change the above argument.
On 2015/09/30 22:09:56, julien.gilli wrote:
Thank you for the review. Updated this changelist according to it, PTAL. https://codereview.chromium.org/1375933003/diff/1/include/v8.h File include/v8.h (right): https://codereview.chromium.org/1375933003/diff/1/include/v8.h#newcode5383 include/v8.h:5383: * If FLAG_abort_on_uncaught_exception is true, then V8 will abort if either: On 2015/10/01 16:34:38, Michael Starzinger wrote: > nit: The "FLAG_abort_on_uncaught_exception" is an internal variable, in the > public API I would rather reference the "--abort-on-uncaught-exception" command > line flag, as that is something that the embedder can actually control. > > Also I would rephrase the wording slightly to say "no internal handler is > predicted to catch the exception", because whether a finally-handler will > re-throw an exception or not is essentially an undecidable problem and hence > cannot be predicted at throw time. We essentially "predict" every > finally-handler will re-throw, which is just an assumption/guess on V8's part. > > Also it might make sense to mentioned explicitly that if > "--abort-on-uncaught-exception" is not set, then the callback will never fire. Acknowledged. https://codereview.chromium.org/1375933003/diff/1/include/v8.h#newcode5383 include/v8.h:5383: * If FLAG_abort_on_uncaught_exception is true, then V8 will abort if either: On 2015/10/01 16:36:30, Michael Starzinger wrote: > On 2015/10/01 16:34:38, Michael Starzinger wrote: > > nit: The "FLAG_abort_on_uncaught_exception" is an internal variable, in the > > public API I would rather reference the "--abort-on-uncaught-exception" > command > > line flag, as that is something that the embedder can actually control. > > > > Also I would rephrase the wording slightly to say "no internal handler is > > predicted to catch the exception", because whether a finally-handler will > > re-throw an exception or not is essentially an undecidable problem and hence > > cannot be predicted at throw time. We essentially "predict" every > > finally-handler will re-throw, which is just an assumption/guess on V8's part. > > > > Also it might make sense to mentioned explicitly that if > > "--abort-on-uncaught-exception" is not set, then the callback will never fire. > > Actually, I just realized: We conservatively assume any finally clause will > behave as if the exception were consumed. But that doesn't change the above > argument. Acknowledged. https://codereview.chromium.org/1375933003/diff/1/src/api.cc File src/api.cc (right): https://codereview.chromium.org/1375933003/diff/1/src/api.cc#newcode7106 src/api.cc:7106: On 2015/10/01 16:34:38, Michael Starzinger wrote: > nit: Two empty newlines between top-level declarations. For some reason, it seems tools/presubmit.py didn't catch this one, but I remember it telling me about two empty newlines missing at other places. https://codereview.chromium.org/1375933003/diff/1/src/api.cc#newcode7106 src/api.cc:7106: On 2015/10/01 16:34:38, Michael Starzinger wrote: > nit: Two empty newlines between top-level declarations. Acknowledged. https://codereview.chromium.org/1375933003/diff/1/src/api.cc#newcode7112 src/api.cc:7112: On 2015/10/01 16:34:38, Michael Starzinger wrote: > nit: Two empty newlines between top-level declarations. Acknowledged. https://codereview.chromium.org/1375933003/diff/1/src/isolate.cc File src/isolate.cc (right): https://codereview.chromium.org/1375933003/diff/1/src/isolate.cc#newcode1019 src/isolate.cc:1019: // abort On 2015/10/01 16:34:38, Michael Starzinger wrote: > nit: Punctuation. Acknowledged. https://codereview.chromium.org/1375933003/diff/1/src/isolate.h File src/isolate.h (right): https://codereview.chromium.org/1375933003/diff/1/src/isolate.h#newcode658 src/isolate.h:658: typedef bool (*AbortOnUncaughtExceptionCallback)(v8::Isolate*); On 2015/10/01 16:34:38, Michael Starzinger wrote: > The "v8::AbortOnUncaughtExceptionCallback" typedef should be available here, no > need to re-typedef it in the internal namespace IMHO. Acknowledged. https://codereview.chromium.org/1375933003/diff/1/test/cctest/cctest.gyp File test/cctest/cctest.gyp (right): https://codereview.chromium.org/1375933003/diff/1/test/cctest/cctest.gyp#newc... test/cctest/cctest.gyp:179: 'test-abort-on-uncaught-exception.cc' On 2015/10/01 16:34:38, Michael Starzinger wrote: > nit: Please keep this list alpha-sorted. Acknowledged.
can you explain why you don't just make the message handler abort if no domain is active?
On 2015/10/02 13:19:13, jochen wrote: > can you explain why you don't just make the message handler abort if no domain > is active? The problem with aborting in the message handler is that, at that point, none of the JavaScript stack frames we're interested in are on the stack anymore. That makes using post-mortem debugging tools to analyze call stacks from core files impossible.
On 2015/10/02 at 17:04:23, julien.gilli wrote: > On 2015/10/02 13:19:13, jochen wrote: > > can you explain why you don't just make the message handler abort if no domain > > is active? > > The problem with aborting in the message handler is that, at that point, none of the > JavaScript stack frames we're interested in are on the stack anymore. That makes using > post-mortem debugging tools to analyze call stacks from core files impossible. fair enough, so overall approach lgtm, but please wait for mstarzinger to complete his review
LGTM on the implementation with one last suggestion. Two comments about the tests, I would just move the second test-case into test-api.cc, drop the first test-case and not introduce a new cctest file. https://codereview.chromium.org/1375933003/diff/20001/src/isolate.cc File src/isolate.cc (right): https://codereview.chromium.org/1375933003/diff/20001/src/isolate.cc#newcode1020 src/isolate.cc:1020: bool should_abort = !abort_on_uncaught_exception_callback_ || Suggestion: I would even inline the whole predicate into the if-statement below and not have the "should_abort" local variable actually. But that's just taste, it's up to you. https://codereview.chromium.org/1375933003/diff/20001/test/cctest/test-abort-... File test/cctest/test-abort-on-uncaught-exception.cc (right): https://codereview.chromium.org/1375933003/diff/20001/test/cctest/test-abort-... test/cctest/test-abort-on-uncaught-exception.cc:29: EXPECT_EXIT(foo->Call(global_object, 0, NULL);, There isn't really a way I can think of to model this with our cctests. The only way I can think of would be to add a permanent test expectation, but I don't like that approach. So I would be fine with dropping this test completely. https://codereview.chromium.org/1375933003/diff/20001/test/cctest/test-abort-... test/cctest/test-abort-on-uncaught-exception.cc:40: TEST(AbortOnUncaughtExceptionUncaughtExceptionCallbackNoAbort) { If we are left with only one test case, then I suggest moving it to test-api.cc instead, adding a new cc-file doesn't seem to be worth it in that case.
https://codereview.chromium.org/1375933003/diff/20001/test/cctest/test-abort-... File test/cctest/test-abort-on-uncaught-exception.cc (right): https://codereview.chromium.org/1375933003/diff/20001/test/cctest/test-abort-... test/cctest/test-abort-on-uncaught-exception.cc:37: bool NoAbortOnUncaughtException(v8::Isolate* isolate) { return false; } Also, we could check that this callback was actually called once, by incrementing a static count initialized to 0 and then checking at the end of the test case that {count == 1} holds.
On 2015/10/05 15:12:06, jochen wrote: > On 2015/10/02 at 17:04:23, julien.gilli wrote: > > On 2015/10/02 13:19:13, jochen wrote: > > > can you explain why you don't just make the message handler abort if no > domain > > > is active? > > > > The problem with aborting in the message handler is that, at that point, none > of the > > JavaScript stack frames we're interested in are on the stack anymore. That > makes using > > post-mortem debugging tools to analyze call stacks from core files impossible. > > fair enough, so overall approach lgtm, but please wait for mstarzinger to > complete his review Thank you for the feedback, it is very much appreciated.
On 2015/10/05 15:12:06, jochen wrote: > On 2015/10/02 at 17:04:23, julien.gilli wrote: > > On 2015/10/02 13:19:13, jochen wrote: > > > can you explain why you don't just make the message handler abort if no > domain > > > is active? > > > > The problem with aborting in the message handler is that, at that point, none > of the > > JavaScript stack frames we're interested in are on the stack anymore. That > makes using > > post-mortem debugging tools to analyze call stacks from core files impossible. > > fair enough, so overall approach lgtm, but please wait for mstarzinger to > complete his review Thank you for the feedback, it is very much appreciated.
Updated according to latest code review comments, PTAL and thank you all for your feedback. https://codereview.chromium.org/1375933003/diff/1/include/v8.h File include/v8.h (right): https://codereview.chromium.org/1375933003/diff/1/include/v8.h#newcode5383 include/v8.h:5383: * If FLAG_abort_on_uncaught_exception is true, then V8 will abort if either: On 2015/10/01 16:34:38, Michael Starzinger wrote: > nit: The "FLAG_abort_on_uncaught_exception" is an internal variable, in the > public API I would rather reference the "--abort-on-uncaught-exception" command > line flag, as that is something that the embedder can actually control. > > Also I would rephrase the wording slightly to say "no internal handler is > predicted to catch the exception", because whether a finally-handler will > re-throw an exception or not is essentially an undecidable problem and hence > cannot be predicted at throw time. We essentially "predict" every > finally-handler will re-throw, which is just an assumption/guess on V8's part. > > Also it might make sense to mentioned explicitly that if > "--abort-on-uncaught-exception" is not set, then the callback will never fire. Done. https://codereview.chromium.org/1375933003/diff/1/include/v8.h#newcode5383 include/v8.h:5383: * If FLAG_abort_on_uncaught_exception is true, then V8 will abort if either: On 2015/10/01 16:36:30, Michael Starzinger wrote: > On 2015/10/01 16:34:38, Michael Starzinger wrote: > > nit: The "FLAG_abort_on_uncaught_exception" is an internal variable, in the > > public API I would rather reference the "--abort-on-uncaught-exception" > command > > line flag, as that is something that the embedder can actually control. > > > > Also I would rephrase the wording slightly to say "no internal handler is > > predicted to catch the exception", because whether a finally-handler will > > re-throw an exception or not is essentially an undecidable problem and hence > > cannot be predicted at throw time. We essentially "predict" every > > finally-handler will re-throw, which is just an assumption/guess on V8's part. > > > > Also it might make sense to mentioned explicitly that if > > "--abort-on-uncaught-exception" is not set, then the callback will never fire. > > Actually, I just realized: We conservatively assume any finally clause will > behave as if the exception were consumed. But that doesn't change the above > argument. Done. https://codereview.chromium.org/1375933003/diff/1/src/api.cc File src/api.cc (right): https://codereview.chromium.org/1375933003/diff/1/src/api.cc#newcode7106 src/api.cc:7106: On 2015/10/01 16:34:38, Michael Starzinger wrote: > nit: Two empty newlines between top-level declarations. Done. https://codereview.chromium.org/1375933003/diff/1/src/api.cc#newcode7112 src/api.cc:7112: On 2015/10/01 16:34:38, Michael Starzinger wrote: > nit: Two empty newlines between top-level declarations. Done. https://codereview.chromium.org/1375933003/diff/1/src/isolate.cc File src/isolate.cc (right): https://codereview.chromium.org/1375933003/diff/1/src/isolate.cc#newcode1019 src/isolate.cc:1019: // abort On 2015/10/01 16:34:38, Michael Starzinger wrote: > nit: Punctuation. Done. https://codereview.chromium.org/1375933003/diff/1/src/isolate.h File src/isolate.h (right): https://codereview.chromium.org/1375933003/diff/1/src/isolate.h#newcode658 src/isolate.h:658: typedef bool (*AbortOnUncaughtExceptionCallback)(v8::Isolate*); On 2015/10/01 16:34:38, Michael Starzinger wrote: > The "v8::AbortOnUncaughtExceptionCallback" typedef should be available here, no > need to re-typedef it in the internal namespace IMHO. Done. https://codereview.chromium.org/1375933003/diff/1/test/cctest/cctest.gyp File test/cctest/cctest.gyp (right): https://codereview.chromium.org/1375933003/diff/1/test/cctest/cctest.gyp#newc... test/cctest/cctest.gyp:179: 'test-abort-on-uncaught-exception.cc' On 2015/10/01 16:34:38, Michael Starzinger wrote: > nit: Please keep this list alpha-sorted. Done. https://codereview.chromium.org/1375933003/diff/20001/src/isolate.cc File src/isolate.cc (right): https://codereview.chromium.org/1375933003/diff/20001/src/isolate.cc#newcode1020 src/isolate.cc:1020: bool should_abort = !abort_on_uncaught_exception_callback_ || On 2015/10/05 16:13:57, Michael Starzinger wrote: > Suggestion: I would even inline the whole predicate into the if-statement below > and not have the "should_abort" local variable actually. But that's just taste, > it's up to you. I agree that the "should_abort" local variable doesn't make things any clearer. What about moving the predicate in the if-statement above like following: if (FLAG_abort_on_uncaught_exception && PredictExceptionCatcher() != CAUGHT_BY_JAVASCRIPT && (!abort_on_uncaught_exception_callback_ || abort_on_uncaught_exception_callback_( reinterpret_cast<v8::Isolate*>(this)))) { ? https://codereview.chromium.org/1375933003/diff/20001/src/isolate.cc#newcode1020 src/isolate.cc:1020: bool should_abort = !abort_on_uncaught_exception_callback_ || On 2015/10/05 16:13:57, Michael Starzinger wrote: > Suggestion: I would even inline the whole predicate into the if-statement below > and not have the "should_abort" local variable actually. But that's just taste, > it's up to you. Done. https://codereview.chromium.org/1375933003/diff/20001/test/cctest/test-abort-... File test/cctest/test-abort-on-uncaught-exception.cc (right): https://codereview.chromium.org/1375933003/diff/20001/test/cctest/test-abort-... test/cctest/test-abort-on-uncaught-exception.cc:29: EXPECT_EXIT(foo->Call(global_object, 0, NULL);, On 2015/10/05 16:13:57, Michael Starzinger wrote: > There isn't really a way I can think of to model this with our cctests. The only > way I can think of would be to add a permanent test expectation, but I don't > like that approach. So I would be fine with dropping this test completely. Done. https://codereview.chromium.org/1375933003/diff/20001/test/cctest/test-abort-... test/cctest/test-abort-on-uncaught-exception.cc:37: bool NoAbortOnUncaughtException(v8::Isolate* isolate) { return false; } On 2015/10/05 16:18:39, Michael Starzinger wrote: > Also, we could check that this callback was actually called once, by > incrementing a static count initialized to 0 and then checking at the end of the > test case that {count == 1} holds. Done. https://codereview.chromium.org/1375933003/diff/20001/test/cctest/test-abort-... test/cctest/test-abort-on-uncaught-exception.cc:40: TEST(AbortOnUncaughtExceptionUncaughtExceptionCallbackNoAbort) { On 2015/10/05 16:13:57, Michael Starzinger wrote: > If we are left with only one test case, then I suggest moving it to test-api.cc > instead, adding a new cc-file doesn't seem to be worth it in that case. Done.
Yep, still looks good, ready for CQ from my end. https://codereview.chromium.org/1375933003/diff/20001/src/isolate.cc File src/isolate.cc (right): https://codereview.chromium.org/1375933003/diff/20001/src/isolate.cc#newcode1020 src/isolate.cc:1020: bool should_abort = !abort_on_uncaught_exception_callback_ || On 2015/10/05 17:24:25, julien.gilli wrote: > On 2015/10/05 16:13:57, Michael Starzinger wrote: > > Suggestion: I would even inline the whole predicate into the if-statement > below > > and not have the "should_abort" local variable actually. But that's just > taste, > > it's up to you. > > I agree that the "should_abort" local variable doesn't make things any clearer. > What about moving the predicate in the if-statement above like following: > > if (FLAG_abort_on_uncaught_exception && > PredictExceptionCatcher() != CAUGHT_BY_JAVASCRIPT && > (!abort_on_uncaught_exception_callback_ || > abort_on_uncaught_exception_callback_( > reinterpret_cast<v8::Isolate*>(this)))) { > > ? Acknowledged. Works for me.
On 2015/10/05 17:39:06, Michael Starzinger wrote: > Yep, still looks good, ready for CQ from my end. Should I just trigger a CQ dry run, or an actual commit?
On 2015/10/05 17:41:08, julien.gilli wrote: > On 2015/10/05 17:39:06, Michael Starzinger wrote: > > Yep, still looks good, ready for CQ from my end. > > Should I just trigger a CQ dry run, or an actual commit? Actual commit is fine. The dry-run is mostly for checking CLs mid-flight to see if they would pass. The CQ will only commit if all try-jobs turn green, otherwise it will abort.
The CQ bit was checked by julien.gilli@joyent.com
The patchset sent to the CQ was uploaded after l-g-t-m from jochen@chromium.org, mstarzinger@chromium.org Link to the patchset: https://codereview.chromium.org/1375933003/#ps40001 (title: "Update after second code review")
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patch-status/1375933003/40001 View timeline at https://chromium-cq-status.appspot.com/patch-timeline/1375933003/40001
On 2015/10/05 17:48:20, commit-bot: I haz the power wrote: > CQ is trying da patch. Follow status at > https://chromium-cq-status.appspot.com/patch-status/1375933003/40001 > View timeline at > https://chromium-cq-status.appspot.com/patch-timeline/1375933003/40001 https://chromium-cq-status.appspot.com/patch-status/1375933003/40001 says that "tree is closed". What is the best way to follow what's going on and have an ETA of when the tree will be open again?
On 2015/10/05 18:32:57, julien.gilli wrote: > On 2015/10/05 17:48:20, commit-bot: I haz the power wrote: > > CQ is trying da patch. Follow status at > > https://chromium-cq-status.appspot.com/patch-status/1375933003/40001 > > View timeline at > > https://chromium-cq-status.appspot.com/patch-timeline/1375933003/40001 > > https://chromium-cq-status.appspot.com/patch-status/1375933003/40001 says that > "tree is closed". > What is the best way to follow what's going on and have an ETA of when the tree > will be open again? Already open, just wait. Follow tree here: http://build.chromium.org/p/client.v8/console
Message was sent while issue was closed.
Committed patchset #3 (id:40001)
Message was sent while issue was closed.
Patchset 3 (id:??) landed as https://crrev.com/1ee712ab8687e5f4dec93d45da068d37d28feb8b Cr-Commit-Position: refs/heads/master@{#31111}
Message was sent while issue was closed.
On 2015/10/05 18:55:25, commit-bot: I haz the power wrote: > Patchset 3 (id:??) landed as > https://crrev.com/1ee712ab8687e5f4dec93d45da068d37d28feb8b > Cr-Commit-Position: refs/heads/master@{#31111} Thank you Michael, jochen and Benedikt for your help! |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
