Crash cooking Android ETC1 textures on OSX


I’m having a crash happen while cooking for Android ETC1 textures in OSX. To make it worse, the crash doesn’t fail the cooking and the editor will happily package the APK with missing content, messing up my automated build process.

This particular crash happens when trying to convert one of the engine’s own textures (VR_LaserPower_01, but I can’t see anything wrong with it), here’s the cook log:

link text

The crash seems to be happening inside the Qualcomm texture converter library. This only happens in OSX, I can build for Android ETC1 using Windows just fine. This is the crash callstack:

SIGSEGV: invalid attempt to access memory at address 0x20

std::_Rb_tree<unsigned int, std::pair<unsigned int const, unsigned int>, std::_Select1st<std::pair<unsigned int const, unsigned int> >, std::less<unsigned int>, std::allocator<std::pair<unsigned int const, unsigned int> > >::_M_insert_unique(std::_Rb_tree_iterator<std::pair<unsigned int const, unsigned int> >, std::pair<unsigned int const, unsigned int> const&) Address = 0x4ece7f27 (filename not found) [in libTextureConverter.dylib]
SetupExpectedIntermediateForamts() Address = 0x4ecf5c91 (filename not found) [in libTextureConverter.dylib]
Qonvert() Address = 0x4ecf7e45 (filename not found) [in libTextureConverter.dylib]
FTextureFormatAndroid::CompressImage(FImage const&, FTextureBuildSettings const&, bool, FCompressedImage2D&) const Address = 0x40116935 (filename not found) [in UE4Editor-TextureFormatAndroid.dylib]
FTextureCompressorModule::BuildTexture(TArray<FImage, FDefaultAllocator> const&, TArray<FImage, FDefaultAllocator> const&, FTextureBuildSettings const&, TArray<FCompressedImage2D, FDefaultAllocator>&) Address = 0x2e54c712 (filename not found) [in UE4Editor-TextureCompressor.dylib]
FTextureCacheDerivedDataWorker::BuildTexture() Address = 0xf1676a7  (filename not found) [in UE4Editor-Engine.dylib]
FTextureCacheDerivedDataWorker::DoWork() Address = 0xf14a532  (filename not found) [in UE4Editor-Engine.dylib]
FAsyncTask<FTextureCacheDerivedDataWorker>::DoWork() Address = 0xf164ad1  (filename not found) [in UE4Editor-Engine.dylib]
FAsyncTask<FTextureCacheDerivedDataWorker>::Abandon() Address = 0xf16418e  (filename not found) [in UE4Editor-Engine.dylib]
FQueuedThread::Run() Address = 0xc108eb8  (filename not found) [in UE4Editor-Core.dylib]
FRunnableThreadPThread::Run() Address = 0xc0ab1f8  (filename not found) [in UE4Editor-Core.dylib]
FRunnableThreadPThread::_ThreadProc(void*) Address = 0xc070c31  (filename not found) [in UE4Editor-Core.dylib]
_pthread_body() Address = 0x8d3d199d (filename not found) [in libsystem_pthread.dylib]
_pthread_body() Address = 0x8d3d191a (filename not found) [in libsystem_pthread.dylib]
thread_start() Address = 0x8d3cf351 (filename not found) [in libsystem_pthread.dylib]
  • Could you please provide us with your Mac specs?
  • Does it happen for any other Android build (ETC 2, ATSC, ALL, etc)?


Here are the Mac specs:

  Model Name:	Mac mini
  Model Identifier:	Macmini5,2
  Processor Name:	Intel Core i5
  Processor Speed:	2.5 GHz
  Number of Processors:	1
  Total Number of Cores:	2
  L2 Cache (per Core):	256 KB
  L3 Cache:	3 MB
  Memory:	8 GB

I can sidestep the problem by using a shared DCC folder between the Mac and our Windows PC, so I can cook the assets once on the PC and the Mac will reuse them, but since the Mac is used for automated builds this isn’t exactly ideal.

Our build system is hardcoded to make ETC Android builds, I’ll fire up the editor manually on the Mac to generate a build using other texture format (I’ll try to pick one that was never generated before, due to the shared DCC with PC being able to sidestep the problem).

I am glad that you were able to find a way to at least work around the issue, while we continue to investigate this for you.

I wanted to point out that your Mac is a little under what we recommend for specifications. But that should only cause it to run slower or possibly not work.

Are you using the source version of the engine? If so, please do the following before building UE4:

  • ShaderCompilerWorker (Development)
  • UnrealLightmass(Development)
  • CrashReporterClient(Shipping)

Then you can go ahead and build for UE4 and see if that resolves the issue you’re running in to.



We have not heard back from you in a few days, so we are marking this post as Resolved for tracking purposes. If you are still experiencing the issue you reported, please respond to this message with additional information and we will offer further assistance.

Thank you!

Hi,I have the same question. Is there any exact time when this problem be fixed? Thank you!