Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

android: persistent_android_resource_processor doesn't work when building AAR #9207

Closed
steeve opened this issue Aug 19, 2019 · 9 comments
Closed

android: persistent_android_resource_processor doesn't work when building AAR #9207

steeve opened this issue Aug 19, 2019 · 9 comments
Labels
P2 We'll consider working on this in future. (Assignee optional) stale Issues or PRs that are stale (no activity for 30 days) team-Android Issues for Android team type: bug

Comments

@steeve
Copy link
Contributor

steeve commented Aug 19, 2019

Description of the problem / feature request:

When building an AAR and using --persistent_android_resource_processor, the worker fails with the following:

Worker process did not return a WorkResponse:

---8<---8<--- Start of log, file at /private/var/tmp/_bazel_steeve/309ac22c92b055a3e3f78825fe63406b/bazel-workers/worker-36-AARGenerator.log ---8<---8<---
(empty)
---8<---8<--- End of log ---8<---8<---

Bugs: what's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

Build an AAR with --persistent_android_resource_processor

What operating system are you running Bazel on?

macos

What's the output of bazel info release?

0.29.0rc6
@steeve
Copy link
Contributor Author

steeve commented Aug 19, 2019

I did manage to reproduce when flipping only --internal_persistent_busybox_tools

@jin
Copy link
Member

jin commented Aug 19, 2019

For a quick workaround, pass --strategy=AARGenerator=sandboxed after --persistent_android_resource_processor.

Does the error show up at all if you don't use the persistent workers flag?

@jin jin added team-Android Issues for Android team untriaged labels Aug 19, 2019
@steeve
Copy link
Contributor Author

steeve commented Aug 19, 2019

@jin it doesn't. actually, I only need to use --internal_persistent_busybox_tools for it to show up

@steeve
Copy link
Contributor Author

steeve commented Aug 19, 2019

The workaround you suggested is working! Thanks

@ahumesky ahumesky added P2 We'll consider working on this in future. (Assignee optional) type: bug and removed untriaged labels Aug 27, 2019
@cgruber
Copy link
Contributor

cgruber commented Dec 10, 2019

Still seeing this, just to keep some life to it.

@justhecuke-zz justhecuke-zz mentioned this issue Mar 5, 2020
Closed
@nkoroste
Copy link
Contributor

Still an issue on version 2.2.0

bazel-io pushed a commit that referenced this issue Apr 19, 2020
@justhecuke-zz @copybara-github
Redirect android persistent worker stdout/stderr to buffer
b9d2afe 
In certain circumstances the various android compilation tools could output to stdout while operating as a persistent worker which would lead to a corruption of the response protobuf and ultimately lead to a failed build.

This PR solves that problem by redirecting all stdout and stderr emitted by the worker to an in-memory buffer that is later attached to the proto response as an output. In this way, all future tools added to the tool wrapper can benefit from having their output logged rather than cause a build failure.

#10527
#9207

Closes #10911.

PiperOrigin-RevId: 307252644
@nkoroste
Copy link
Contributor

Still an issue 3.3.1

luca-digrazia pushed a commit to luca-digrazia/DatasetCommitsDiffSearch that referenced this issue Sep 4, 2022
Redirect android persistent worker stdout/stderr to buffer
c88ca1a 
    In certain circumstances the various android compilation tools could output to stdout while operating as a persistent worker which would lead to a corruption of the response protobuf and ultimately lead to a failed build.

    This PR solves that problem by redirecting all stdout and stderr emitted by the worker to an in-memory buffer that is later attached to the proto response as an output. In this way, all future tools added to the tool wrapper can benefit from having their output logged rather than cause a build failure.

    bazelbuild/bazel#10527
    bazelbuild/bazel#9207

    Closes #10911.

    PiperOrigin-RevId: 307252644
@github-actions
Copy link

Thank you for contributing to the Bazel repository! This issue has been marked as stale since it has not had any activity in the last 2.5 years. It will be closed in the next 14 days unless any other activity occurs or one of the following labels is added: "not stale", "awaiting-bazeler". Please reach out to the triage team (@bazelbuild/triage) if you think this issue is still relevant or you are interested in getting the issue resolved.

@github-actions github-actions bot added the stale Issues or PRs that are stale (no activity for 30 days) label Mar 16, 2023
@github-actions
Copy link

This issue has been automatically closed due to inactivity. If you're still interested in pursuing this, please reach out to the triage team (@bazelbuild/triage). Thanks!

@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Mar 31, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
P2 We'll consider working on this in future. (Assignee optional) stale Issues or PRs that are stale (no activity for 30 days) team-Android Issues for Android team type: bug
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@steeve @cgruber @jin @nkoroste @ahumesky