IssueTracker

In the original case I had both the app and library's build-tools version set to 33.0.0.

Oddly, however, I still see the same issue if I leave either the app or the library's build-tools version set to 33.0.0.

Jean Luc, can you have a look asap that it is not a widespread issue, thanks !

Can confirm this issue is reproducible in windows. Aidl is exiting with non-zero exit code and without any message

> C:\Users\jeanlucncoelho\AppData\Local\Android\Sdk\build-tools\33.0.0\aidl.exe -pC:\Users\jeanlucncoelho\AppData\Local\Android\Sdk\platforms\an
droid-33\framework.aidl -oC:\Users\jeanlucncoelho\project\build\generated\aidl_source_output_dir\debug\out -IC:\Users\jeanlucncoelho\project\src\main\aidl -IC:\Users\jeanlucncoelho\project\src\debug\aidl -dC:\Users\JEANLU~1\AppData\Local\Temp\aidl7877085528088218597.d C:\Users\jeanlucncoelho\project\src\main\aidl\com\example\helloworld\IRenamed.aidl

> echo $LASTEXITCODE
-1073740940

What is strange to me is this argument

-dC:\Users\JEANLU~1\AppData\Local\Temp\aidl7877085528088218597.d

if I look for it windows will tell me it's there

> ls C:\Users\JEANLU~1\AppData\Local\Temp\aidl7877085528088218597.d


    Directory: C:\Users\jeanlucncoelho\AppData\Local\Temp


Mode                LastWriteTime         Length Name
----                -------------         ------ ----
-a----        6/28/2022   8:18 PM            726 aidl7877085528088218597.d

But the same thing goes if I replace it with my actual username

 ls C:\Users\jeanlucncoelho\AppData\Local\Temp\aidl7877085528088218597.d


    Directory: C:\Users\jeanlucncoelho\AppData\Local\Temp


Mode                LastWriteTime         Length Name
----                -------------         ------ ----
-a----        6/28/2022   8:24 PM            726 aidl7877085528088218597.d

and aidl seems to succeed if I replace it with my proper username.

I don't know if we are seeing the same bug.

Comment#1 can you please run the command AGP gives you when it fails (when it says Error while executing process ...\aidl.exe with arguments {-p...}) and the run echo $LASTEXITCODE` and tell me what it says?

@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.