With a non-mainstream language, it is pretty much always a compiler bug I use Pascal, because it is very fast and has automated reference counting (ARC) for mo

With a non-mainstream language, it is pretty much always a compiler bug I use Pascal, because it is very fast and has automated reference counting (ARC) for most types, so it is almost memory safe. It was the only way to get C-like speed, fast compilation and no memory issues. With ARC you never get uninitialized values, you never get a use-after-free, and you never get a double-free. A few days ago, I ran my program in valgrind's memcheck: double-free detected That was hard to debug. Valgrind told me where the value was created, but not where it was freed the first time. Turns out, FreePascal just put an unmatch refcount decrement after a string comparison: https://github.com/benibela/internettools/commit/4c510e8c977b7773b78fd1b586156b1cef421065 https://github.com/benibela/internettools/commit/4c510e8c977... Time to update FreePascal. I use "nightly" builds of FreePascal because the stable version did not have Android aarch64 support (although the newest stable does support it. but there were other issues with the standard library). Last time I tried to update it, it stopped working on Android x86 and some floating point computations failed. But those issues have been fixed now. -- Even worse than compiler bugs are CPU bugs. Or emulator bugs if you run it on an emulated CPU. I just had the problem that my app did not start on the aarch64 Android emulator. JNI ExceptionCheck always returned 1. This function here: https://github.com/benibela/internettools/commit/d9fafc9274a25f07bca353028e9e97f4687ca813 https://github.com/benibela/internettools/commit/d9fafc9274a... Two instructions added to the assembly and it is fixed and returns 0, but those instructions should not have changed anything