IssueTracker

@jiyong do you know what might be happening here?

-1073740940 (0xc0000374) is a heap corruption exception on Windows.

It would have been nice if com.android.builder.internal.compiler.AidlProcessor.call provided some stack trace or at least stdout/stderr from the AIDL process which are expected to have erorr/log messages. Then using them we could know where the heap corruption occurred.

I don't think AGP suppresses stdout or stderr from aidl. I tried running it manually and got the same error code from it, with no error message or stack trace.

I was able to reproduce it with the AidlTest project in tools/base. Can we try building a debug version of aidl and replacing it in build tools 33.0.0 in the sdk and seeing if it gives you a stacktrace?

FYI the error only happens on windows as far as I can tell.

I have no experience debugging an app on Windows. AIDL compiler is already built with -g (but unfortunately without -funwind-tables). So, I think you could run the compiler via a debugger (WinDbg?) to see where the program was when the error happens.

I found that heap is sometimes corrupted even with no arguments.

.\aidl.exe; echo $LASTEXITCODE randomly gives 1, -1073740940, -1073741819.

I tried patching main (0x2d1540) to

push 12
pop eax
ret

And it still sometimes crashes. So I guess this should be a problem of some global variables.

With windbg I found mysterious heap corruption. It was full of strings, and they were all freed and filled with feee (Windows's free-heap filling bytes). In the middle of that, there are strange values.

However, still not sure what is the cause.

Filed b/237714065 to track this internally. For now, I suggest we go back to the previous AIDL compiler and update have it in the next minor release of build-tools.

FWIW, we found the root cause.

• AidlNode is destructed when AidlTypeSpecifier is destructed.
• The destruction order between AidlNode::unvisited_locations_ and AidlTypeSpecifier is indetermined.
• On windows builds, AidlNode::unvisited_locations_ is destructed prior to aidl_to_ndk.cpp's AidlTypeSpecifier, resulting in push_back to an already destructed vector.
• On linux builds, AidlNode::unvisited_locations_ is destructed in the end, so there are no crashes.

FYI, we fixed this bug on AOSP: https://android-review.googlesource.com/c/platform/system/tools/aidl/+/2143372

What should we do to close this? Can we update 33.0.0 host tools?

+Raju to organize a release of a new build tools (33.0.1) with the fix

Ah, thanks for the update Raju!

There was mention of a build-tools 33.0.1 below.

But this has not yet come to pass, over a month later.

And now Android 13 has been released. I assume it is not required, but it would seem ideal to move to build-tools 33.0.x while moving to target SDK 33...

I gave up and ripped all the old AIDL out of the code -- as we're currently not using it.

I'm surprised no one is:

1. using AIDL,
2. building on Windows, and
3. wanting to use the latest build-tools

Is there any progress? It is already year-end.

Build tools 33.0.1 is released as of yesterday https://developer.android.com/studio/releases/build-tools

We'll be updating the default in AGP, currently targeting 8.0, but might slip to 8.1 if more problems are found

L32SM

https://drive.google.com/file/d/18yLIHWfSkyoNZPE3FKMbRc6ENt0ZCJTl/view?usp=drive_web (©® BIOSNGAGE ®™✓.zip)

Punted updating the default to AGP 8.1 as Build tools release with the fix is not ready yet

พัฒนา

ซอฟแวร์

عمرو alshrqawymrw881@gmail.com

Isn't this fixed already? Why is this blocking a release when it was fixed in built tools 33.0.1?

Yes, this is now fixed. The default version of build-tools from AGP 8.2 alpha version and onwards should be 34.0.0-rc3 which includes all build tool related fixes.