microsoft
MacOS std::string append will cause crash
- M1 arm64 MacOS Ventura 13.1 (22C65)
- mimalloc Build type: relwithdebinfo
std::string path = "/Users/xxxx/Library/Developer/Xcode/DerivedData/xxxxxxxxxx/Build/Intermediates.noindex/xxxxxxxxxxx/arm64/XX_lto.o/0.arm64.lto.o";
std::string path1 = "/Users/xxxx/Library/Developer/Xcode/DerivedData/xxxxxxxxxx/Build/Intermediates.noindex/xxxxxxxxxxx/arm64/XX_lto.o/1.arm64.lto.o";
std::cout << path + "\n>>> " + path1 + "\n>>> " << std::endl;
I tried to repro this with both the latest dev and dev-slice branch, both with dynamic overriding and static overriding and I could not reproduce it. Maybe it has been fixed since your version?
I have the same issue.
- M1 MacOS Ventura 13.2.1 (22D68)
- mimalloc 2.0.9 Build type: Release
I have a shared library linked to static mimalloc. The library loaded by a java application and it crashes during log file path forming. It works fine in debug though. I also tried @edisongz code and it crashed.
Thanks! I tried:
#include <iostream>
int main() {
std::string path = "/Users/xxxx/Library/Developer/Xcode/DerivedData/xxxxxxxxxx/Build/Intermediates.noindex/xxxxxxxxxxx/arm64/XX_lto.o/0.arm64.lto.o";
std::string path1 = "/Users/xxxx/Library/Developer/Xcode/DerivedData/xxxxxxxxxx/Build/Intermediates.noindex/xxxxxxxxxxx/arm64/XX_lto.o/1.arm64.lto.o";
std::cout << path + "\n>>> " + path1 + "\n>>> " << std::endl;
return 0;
}
and compiled as:
clang++ -g test-string.cpp
and ran in v2.0.9 release as:
DYLD_INSERT_LIBRARIES=./libmimalloc.dylib MIMALLOC_VERBOSE=1 ./a.out
but it worked fine. (also on M1, Ventura 13.2.1).
I am guessing you see the crash as you link mimalloc statically into a dynamically loaded library; I will try to replicate that as well but I need to figure out how to easily test this :-). Very strange it works in debug mode but not in release..
I am guessing you see the crash as you link mimalloc statically into a dynamically loaded library; I will try to replicate that as well but I need to figure out how to easily test this :-).
Thanks for your reply! Not sure if I understood correctly, maybe I wasn't very clear, so I'll try to explain a little more. I have a shared library that I link against several other, including mimalloc-static(the library was installed via vcpkg). The library is build in release or debug mode and is loaded by a java app on demand. If I put @edisongz code in JNI_OnLoad function it woould crash.
In my CmakeList.txt it looks like:
add_library(mylib SHARED ${sources}
target_link_libraries(mylib PRIVATE <several other libs including mimalloc-static>)
I might have fixed the issue .. can you try this with the latest dev or dev-slice (v2.x) branch?
I created a dylib from:
#include <iostream>
extern "C" int myentry() {
std::string path = "/Users/xxxx/Library/Developer/Xcode/DerivedData/xxxxxxxxxx/Build/Intermediates.noindex/xxxxxxxxxxx/arm64/XX_lto.o/0.arm64.lto.o";
std::string path1 = "/Users/xxxx/Library/Developer/Xcode/DerivedData/xxxxxxxxxx/Build/Intermediates.noindex/xxxxxxxxxxx/arm64/XX_lto.o/1.arm64.lto.o";
std::cout << path + "\n>>> " + path1 + "\n>>> " << std::endl;
return 0;
}
using
clang++ -dynamiclib -o libmydylib.dylib ../release/test-mydylib.cpp ./CMakeFiles/mimalloc-obj.dir/src/static.c.o
and loaded it dynamically as:
#include <iostream>
#include <dlfcn.h>
typedef int (*myentryfun)(void);
int main() {
void* lib = dlopen("./libmydylib.dylib",RTLD_NOW|RTLD_GLOBAL);
if (lib==NULL) {
std::cout << "failed to load library\n";
return 1;
}
myentryfun fun = (myentryfun)dlsym(lib,"myentry");
if (fun==NULL) {
std::cout << "failed to find 'myentry'\n";
return 2;
}
fun();
return 0;
}
compiled as:
clang++ -g test-load-mydylib.cpp
and using MIMALLOC_VERBOSE=1 ./a.out I got indeed a crash in release only; I think the release mode was optimizing away a thread local load which is needed for proper initialisation (since TLS storage on Mac calls malloc :-( )
Maybe there is still some other issue since I only get it if using MIMALLOC_VERBOSE=1..
I tried with the latest dev and it still crashes. If I comment out the line that causes the crash, then it crashes somewhere else(it's nondeterministic). There are some logs(trimmed down to keep brevity).
This one may occur when returning the result string from the function.
Current thread (0x00007fdd478e3800): JavaThread "JavaFX Application Thread" [_thread_in_native, id=259, stack(0x00000003090d8000,0x00000003098d8000)]
Stack: [0x00000003090d8000,0x00000003098d8000], sp=0x00000003098ced90, free space=8155k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C [librd.dylib+0x3abc72] _mi_free_generic(mi_segment_s const*, mi_page_s*, bool, void*)+0x52
C [librd.dylib+0x60140c] log::logFilePrefix()+0x20c
C [librd.dylib+0x601520] log::initLogging(log::LoggingSettings const&)+0x70
C [librd.dylib+0x5da764] JNI_OnLoad+0x94
C [libjava.dylib+0x3d5e] Java_jdk_internal_loader_NativeLibraries_load+0x13e
Next two are similar
C [librd.dylib+0x3abd20] mi_free+0x20
C [librd.dylib+0x7bf7] google::protobuf::internal::ArenaStringPtr::Destroy()+0x27
C [librd.dylib+0x75431f] proto::ResponceID::~ResponceID()+0x2f
C [librd.dylib+0x75cba1] proto::Responce::Clear()+0xb1
C [librd.dylib+0x3abd20] mi_free+0x20
C [librd.dylib+0x7bf7] google::protobuf::internal::ArenaStringPtr::Destroy()+0x27
C [librd.dylib+0x75a558] proto::Encryption::~Encryption()+0x38
C [librd.dylib+0x75cc19] proto::Responce::Clear()+0x129
As before, It works fine on other platforms and in debug mode on macos.
... I hope the latest release may work for you this time (v1.8.2 or v2.1.2). Can you try? Otherwise we need to look into this further where I can repro again. Thanks.
v2.1.2 is still crashing on macOS and Ubuntu. I observe crashes in std::unordered_map<std::string, void*>::find() with a C string as a key argument, it crashes in me_free().
If mimalloc is built with -DMI_DEBUG_FULL=ON, that line raises the warning before the crash:
mimalloc: warning: mi_free: pointer might not point to a valid heap region: 0x555555d72800
(this may still be a valid very large allocation (over 64MiB))
v1.8.2 crashes a bit differently in the same our code location:
