s09bQ5

The macOS hex values are useless because of ASLR. I wonder why it isn't able to resolve the addresses. I'm relieved that it crashes as well with v2023.4. That rules...

I did not want to imply that ASLR caused the crash. ASLR just makes the debug output useless if the Free Pascal runtime is unable to resolve symbols. My best...

@AlpenAalAlex, can you test if this build still crashes?: https://ci.appveyor.com/project/s09bQ5/usdx/builds/46991121/job/vdww9nfqmfl5c36f/artifacts And can you check if the Error.log file contains any lines ending in `[TTextureUnit.LoadTexture]`? In your case it doesn't crash...

@GrueneNeun, do you get any nice error message window like AlpenAalAlex?

The `Could not convert surface` case is the one that would have crashed previously. Are you maybe running low on RAM? Or are we hitting the limit of 32 bit...

> I can't see any memory leak when running it here. I take that back. There were a few. @AlpenAalAlex, please try https://ci.appveyor.com/project/s09bQ5/usdx/builds/47023474/job/09gmrxa24tahqjke/artifacts

Please test s09bQ5/USDX@019b475ed50edc0d917312a3c02f20189d1a3723

> Exception Type: EXC_BAD_ACCESS (SIGKILL (Code Signature Invalid)) So Ventura at least on ARM64 insists that executables are signed? Or is it just when executing an application bundle? Or did...

> As I am still on Monterey, I did not need the code signing part, According to [some websites](https://wiki.lazarus.freepascal.org/Code_Signing_for_macOS) Apple applies different rules for ARM64 than for x86. On ARM64...

This is a common thing in the macOS ecosystem. Maybe we should change the Makefile to print the reminder about codesign at the end of a build instead of hiding...