Large error stack traces can cause FAILED BINDER TRANSACTION #269
Comments
|
Hi @brettchabot , thanks for looking into this. Do you know if this is going to be part of the 1.1.2 release? |
|
No sorry, a fix for this isn't currently scheduled for the next release. |
|
Hi @brettchabot , thank you for your reply. How often do you ship your releases? Can you give me a rough time estimate for this? Is there any workaround that I can try? This is at the moment causing 100% of our test runs to fail. Thanks in advance, |
|
Sorry I cannot provide a timeline for the fix. I've seen this error before when a test is failing and dumping a very large stack trace. So I'd suggest to look at the logcat, figure out what test is failing, and fix the root cause. |
|
Thank you for the response. If possible please try to prioritize this, the tests are passing locally so we are not sure where the failure comes from. Thanks again, |
|
Im having the same issue right now |
|
Hey @brettchabot, still seeing this from time to time. Would it be possible for you to maybe trim the bottom part of the stack trace or something if you know that it cannot fit and it's going to crash? Do you accept contributions? Happy to try to fix this. |
|
I am also facing bug #286 on Firebase test lab. After a few tests, the orchestrator crashes and no further tests are executed. Stacktrace:
The logcat is not very useful. |
This is not as straightforward as it sounds, especially if we don't even get the stacktrace. Is it any reasonably simple way we can work around this in a local fork for example, just to be able to debug issues? |
|
Having the same issue. |
|
Have the same issue too. Reproduced only in TestLab and runs successfully on local machine with androidx.test:orchestrator:1.1.0 |
|
We figured out that actual problem was in huge error trace from our failed tests. |
|
It happens to me too, with this stack trace Is it trying to send the whole test_result_2378417933931616849.xml file with Parcelable? And this is in the loggcat before Maybe this is the test that produces too long stacktrace. |
|
Is there any way how to configure bigger transaction (parcel data) size on the emulator? |
|
What about just limit result string size in to value which fit the maximum bundle size? At least like a quick fix solution. |
|
I removed the test that causing this issue locally (on Windows) and it still failing on another one on the Linux CI server, it looks the limit of binder transaction is different od different platforms or stack trace is different. Both on the same emulators :-( Currently is it is a huge blocker for us. @brettchabot do you thin that makes sense my previous post about limit size in createResultBundle() method? Since this library not using standard builds tools is an investment to build it locally very hard, but if you think that it can help and you are not planning to fix it, I would go in my own fork way. |
|
@tprochazka |
Yes. I proposed it as a quick solution, it is definitely better than crash complete test suit, because then you have nothing. You even don't know which test caused it. You need to investigate logcat from the emulator. |
|
@tprochazka i am thinking about writing the entire stack trace in a file. what do you think? |
|
Of course that like a long solution this will be much better. |
|
Do we have any working solution for this issue? |
|
No. I'm not running every test as separate TeamCity job, so if one fails, it will not harm all others :-( |
… classic/non-orchestrator modes.
This change should clean up test failure reporting by:
- Remove test runner framework related stack frames
- Truncate stack traces to a 64KB size when running under orchestrator
to attempt to avoid binder transaction limits.
This limit is already enforced when running in classic/non-orchestrator mode
JUnit 4.13 has a really nice getTrimmedStackTrace feature, but androidx.test
is fixed to 4.12 for the time being. So as a temporary workaround, copy
the relevant JUnit utilty class into this project.
Fixes #729, and hopefully #269
PiperOrigin-RevId: 329797783
… classic/non-orchestrator modes.
This change should clean up test failure reporting by:
- Remove test runner framework related stack frames
- Truncate stack traces to a 64KB size when running under orchestrator
to attempt to avoid binder transaction limits.
This limit is already enforced when running in classic/non-orchestrator mode
JUnit 4.13 has a really nice getTrimmedStackTrace feature, but androidx.test
is fixed to 4.12 for the time being. So as a temporary workaround, copy
the relevant JUnit utilty class into this project.
Fixes #729, and hopefully #269
PiperOrigin-RevId: 329797783
… classic/non-orchestrator modes.
This change should clean up test failure reporting by:
- Remove test runner framework related stack frames
- Truncate stack traces to a 64KB size when running under orchestrator
to attempt to avoid binder transaction limits.
This limit is already enforced when running in classic/non-orchestrator mode
JUnit 4.13 has a really nice getTrimmedStackTrace feature, but androidx.test
is fixed to 4.12 for the time being. So as a temporary workaround, copy
the relevant JUnit change junit-team/junit4#1028 into this project.
Fixes #729, and hopefully #269
PiperOrigin-RevId: 329797783
… classic/non-orchestrator modes.
This change should clean up test failure reporting by:
- Remove test runner framework related stack frames
- Truncate stack traces to a 64KB size when running under orchestrator
to attempt to avoid binder transaction limits.
This limit is already enforced when running in classic/non-orchestrator mode
JUnit 4.13 has a really nice getTrimmedStackTrace feature, but androidx.test
is fixed to 4.12 for the time being. So as a temporary workaround, copy
the relevant JUnit change junit-team/junit4#1028 into this project.
Fixes #729, and hopefully #269
PiperOrigin-RevId: 329797783
… classic/non-orchestrator modes.
This change should clean up test failure reporting by:
- Remove test runner framework related stack frames
- Truncate stack traces to a 64KB size when running under orchestrator
to attempt to avoid binder transaction limits.
This limit is already enforced when running in classic/non-orchestrator mode
JUnit 4.13 has a really nice getTrimmedStackTrace feature, but androidx.test
is fixed to 4.12 for the time being. So as a temporary workaround, copy
the relevant JUnit change junit-team/junit4#1028 into this project.
Fixes #729, and hopefully #269
PiperOrigin-RevId: 329797783
… classic/non-orchestrator modes.
This change should clean up test failure reporting by:
- Remove test runner framework related stack frames
- Truncate stack traces to a 64KB size when running under orchestrator
to attempt to avoid binder transaction limits.
This limit is already enforced when running in classic/non-orchestrator mode
JUnit 4.13 has a really nice getTrimmedStackTrace feature, but androidx.test
is fixed to 4.12 for the time being. So as a temporary workaround, copy
the relevant JUnit change junit-team/junit4#1028 into this project.
Fixes #729, and hopefully #269
PiperOrigin-RevId: 332051125
|
Please give 1.3.1-alpha01 a try. Stack traces should be slightly smaller by default, and will get truncated to 64KB in size. https://github.com/android/android-test/releases/tag/androidx-test-1.3.1-alpha01 |
|
Thanks a lot! I will test it. We have now 1.2.0 version, so I hope that upgrade will be easy. |
|
We try hard to make releases backwards compatible - let us know if you hit any snags upgrading. |
|
I just tested it and it really looks that this fix helps. |
|
1.3.1-alpha01 fixes it indeed, but now the stacktrace is truncated and you can't see where the test failed exactly. |
|
Agreed, the view dump is not too useful if we don't know which check/perform failed. |
Tracking b/118760175
The text was updated successfully, but these errors were encountered: