Android: Build failed: Internal Server Error

To Whom It May Concern,

I am trying to do Android builds and 98% of the time, I keep getting “Build failed: Internal Server Error.” I’ve had better success, for some reason, when running the build from my local machine. Normally, there’s a Github action that fires of the eas build command when we have pull requests completed. The builds succeed in Android Studio, and again, they’ll succeed after Nth amount of retries with clearing the cache.

The size of file being built is 327mb. I’m not sure if that’s the problem. I believe it shouldn’t be because it’s just doing gradlew commands, and those same commands work locally. We’re on eas-cli 0.54.1, gradlew 7.5.1, expo 46. It’s to be noted our iOS builds perfectly fine.

Hi @lance_eate

Could you paste some of the logs around the “Internal Server Error”? I hope there’s more context in the logs. e.g. what is it trying to fetch when it gets the Internal Server Error? Is it the same every time?

@wodin,
Thanks for your fast reply. I’m unable, or unaware of how, to get a flat file of logs, so I provided the screenshot. There’s no hard error from gradle for me to actually debug. Are you able to track down logs via build IDs?

Thanks. Normally you should just copy and paste the text (although the formatting gets a bit messed up because of extra newlines that get inserted for some reason.)

Is line 6231 the last line in the “gradlew” logs?

Wild guess: I wonder if it’s running out of RAM or something like that.

I am not, but the Expo team members are able to do that, so not a bad idea to post a build URL in case one of them wants to investigate.

Gotcha, I provided the text below. I also think it’s something with memory on the build server. The file is 327mb due to having Square integrated. I’ve been retrying the same build for HOURS and it’s always internal server error

Unable to extract native debug metadata from /home/expo/workingdir/build/android/app/build/intermediates/merged_native_libs/betaRelease/out/lib/x86_64/libe36b.so because of non-zero exit value from objcopy.
6254 > Task :app:mergeExtDexBetaRelease
6255 > Task :app:extractBetaReleaseNativeSymbolTables
6256 Unable to extract native debug metadata from /home/expo/workingdir/build/android/app/build/intermediates/merged_native_libs/betaRelease/out/lib/x86/libe36b.so because of non-zero exit value from objcopy.
6257[stderr] /home/expo/Android/Sdk/ndk/21.4.7075529/toolchains/llvm/prebuilt/linux-x86_64/bin/llvm-objcopy: error: Info field value 20 in section .rel.plt is invalid
6258[stderr] /home/expo/Android/Sdk/ndk/21.4.7075529/toolchains/llvm/prebuilt/linux-x86_64/bin/llvm-objcopy: error: Info field value 18 in section .rela.plt is invalid
6259 Unable to extract native debug metadata from /home/expo/workingdir/build/android/app/build/intermediates/merged_native_libs/betaRelease/out/lib/arm64-v8a/libe36b.so because of non-zero exit value from objcopy.
6260 > Task :app:mergeExtDexBetaRelease
6261 Execution optimizations have been disabled for task ':app:mergeExtDexBetaRelease' to ensure correctness due to the following reasons:
6262 - Gradle detected a problem with the following location: '/home/expo/workingdir/build/android/app/build/intermediates/duplicate_classes_check/betaRelease'. Reason: Task ':app:mergeExtDexBetaRelease' uses this output of task ':expo-updates:copyBetaReleaseExpoManifest' without declaring an explicit or implicit dependency. This can lead to incorrect results being produced, depending on what order the tasks are executed. Please refer to https://docs.gradle.org/7.5.1/userguide/validation_problems.html#implicit_dependency for more details about this problem.
6263 - Gradle detected a problem with the following location: '/home/expo/workingdir/build/android/app/build/intermediates/external_file_lib_dex_archives/betaRelease'. Reason: Task ':app:mergeExtDexBetaRelease' uses this output of task ':expo-updates:copyBetaReleaseExpoManifest' without declaring an explicit or implicit dependency. This can lead to incorrect results being produced, depending on what order the tasks are executed. Please refer to https://docs.gradle.org/7.5.1/userguide/validation_problems.html#implicit_dependency for more details about this problem.

I see that the workers should have 12GB of RAM which sounds like it should be enough? I wonder if the MaxPermSize is too low, though.

Ah ha!!! @wodin, you may be onto something! I just checked the build.gradle, and I don’t even have the MaxPermSize defined. I know that the default can be 256mb in most cases. I’ll set that in the gradle, give it a go, and post back the outcome.

Perhaps you could try changing ~/.gradle/gradle.properties in a build hook:

If I understand correctly, the build workers have it set to 512m in the ~/.gradle/gradle.properties file, so you should probably overwrite that file (on the build worker) with the value you want to use.

Can you try my suggestions from this comment Android: EAS Build fails due to Internal Server Error · Issue #1410 · expo/eas-cli · GitHub ?

2 Likes

@wkozyra I’m now running it with “–resource-class large” in the command. I successfully updated the MaxPermSize like @wodin recommended, and it just failed doing that. Hopefully, this one solves it.

Wow!! @wkozyra it worked, and it was a lot faster. It completed in less than 13 minutes. My android builds have been between 25 and 32 minutes. Thank you so much for your help! Also, @wodin, thank you for your time and assistance with this too!

1 Like

Hi resource classes are an experimental feature for now, they may not be available in the free tier in the future, and queue time for them might be larger. I would still recommend investigating what is the root cause of the problem.

We deployed a fix yesterday that even if it does not fix the failure, should at least stop builds from returning internal server error and maybe throw something more descriptive.

It would help significantly if you could create some reproducible example that you could share, e.g. by taking your project and throwing out all the js code and everything else you can’t share publicly.

Thank you for the heads up. My company is on the Production Plan, so hopefully that plan will cover that. If not, think of your dear friend Lance_Eate when you all are making the decision :wink:. I’ll also make it task to make a shell of our project to help out.

1 Like

This topic was automatically closed 20 days after the last reply. New replies are no longer allowed.