Sorry for newbie question.I have libnative_exception_handler.so with breakpad init:
google_breakpad::MinidumpDescriptor descriptor(".");
google_breakpad::ExceptionHandler eh(descriptor, NULL, breakpad_callback, NULL, true, -1);
and libfunc.so with unsafe functions.
Both libs are loaded in android using System.loadLibrary();
if breakpad init is done in libnative_exception_handler.so signals are not catched and breakpad callback is not invoked. if i change libfunc.so source to init breakpad signals are catched. So does breakpad need to be init in the same library where unsafe function are?.
Update: I've create lib and demo app to demonstrate the issue: https://github.com/4ntoine/Acra-breakpad
google_breakpad::ExceptionHandler eh needs to be init in heap, not in stack.
Related
I have a little bit of a fight with Kotlin Native and the runtime. In short: I am building a jvmti agent, linking a dynamic library.
Now I have following case, what I like to achieve can be expressed in C like:
char* class_sig;
(*jvmti)->GetClassSignature(object_klass, &class_sig, NULL)
do something with class_sig....
(*jvmti)->Deallocate((unsigned char*) class_sig);
So in that case the jvmti environment allocates the memory for class_sig, that is why I have to deallocate through the jvmti environment.
How can this be achieved in Kotlin? I am a little on the fence regarding calling nativeheap.alloc, wouldn't that cause a memory leak because the jvmti environment already allocates memory?
Or can I just do:
val signaturePtr = nativeHeap.alloc<CPointerVar<ByteVar>>()
jvmti?.pointed?.pointed?.GetClassSignature?.invoke(jvmti, klass, signaturePtr.ptr, null)
Call jvmti dealloc?
Kotlin Native way is to use memScoped blocks for such task. Take a look at official guide for C interop
If you write
memScoped {
val signaturePtr = alloc<CPointerVar<ByteVar>>()
//...
}
Kotlin will take care of memory deallocation inside memScoped block, no need to invoke jmti Deallocate
I'm learning DirectX 2D.
When i close my application, i have noticed there is a problem in IWICImagingFactory* type variable.
I use only one IWICImagingFactory* variable in whole program. So i initiate it once when i start program and destroy(release) once when i close my program.
But if i release IWICImagingFactory* variable after call CoUninitialize() function, there is error.
Factorys::~Factorys()
{
SAFE_RELEASE(mpD2DFactory);
SAFE_RELEASE(mpWICFactory);
}
↓ Is is korean, meaning : error throw, access violation, "this->mpWICFactory->" is 0x6EEFC7D8
enter image description here
I noticed "this->mpWICFactory->" has problem when i try to release WICFactory after call CoUninitialize(). So i read about CoUninitialize() in here : "https://learn.microsoft.com/en-us/windows/win32/api/combaseapi/nf-combaseapi-couninitialize"
And i read this part in the link : Closes the COM library on the current thread, unloads all DLLs loaded by the thread.
Quetion 1 : When i call CoUninitialize() function, WICfactory is released automatically?
Quetion 2 : Do i have to release WICFactory before call CoUninitialize() function?
Yes, as you mention in the question, CoUninitialize will unload all dependent loaded libraries (WICFactory being one of them).
So trying to unload an already unloaded library will get you an AV or another Error.
It's not "really necessary" to release WICFactory, since CoUninitialize will also do it (and since you release when program closes anyway, even if you don't call CoUninitialize the Operating System will do it for you).
However, I strongly recommend that you still release your resources (so yes, release WICFactory, then call CoUninitialize ), having code that knows how to do correct cleanup will always be better in the long term (no matter if you use smart pointers or not, that is up to you).
I have an ObjectiveC++ project. In the ObjectiveC context I am using ARC and iPhoneSDK 6. In C++ I am using a C++11 compiler.
Lambda functions in C++11 are capturing variables with references. This concept is not really supported by ObjectiveC and by "try and error" I came up with the following solution. Are there any pitfalls I am not aware of?
Is there a better solution to this problem?
typedef std::function<void ()> MyLambdaType;
...
// m_myView will not go away. ARC managed.
UIView * __strong m_myView;
...
// In Objective C context I create a lambda function that calls my Objective C object
UIView &myViewReference = *m_myView;
MyLambdaType myLambda = [&myViewReference]() {
UIView *myViewBlockScope = &myViewReference;
// Do something with `myViewBlockScope`
}
..
// In C++11 context I call this lambda function
myLambda();
The straightforward thing to do would be to let the lambda capture the object pointer variable m_myView (I am assuming from your snippet that this is a local variable), and use it normally inside the lambda:
MyLambdaType myLambda = [m_myView]() {
// Do something with `m_myView`
}
The only concern would be the memory management of m_myView. To be generally correct, the lambda needs to retain m_myView when it is created, and release it when it is destroyed (just like blocks do; because the lambda could be used in a scope where m_myView does not exist).
Reading through the ARC docs, I don't see this situation mentioned specifically, but I believe that it should handle it properly, because (1) captured variables of a C++11 lambda are stored as fields of an anonymous class, which are initialized to the captured value when the lambda is constructed, and (2) ARC properly handles the retaining and releasing of Objective-C object fields of C++ classes on construction and destruction. Unless it says something specifically about lambdas to the contrary, or there's a compiler bug, I see no reason why it should not work.
I have a dynamic library which I load using dlopen() and then unload using dlclose();
If I dont include any objective c code dlopen() needs one dlclose() call which is expected behavior. But when I include any objective c code to target, I have problem that I need to do two dlclose() calls to the loaded library in order to unload.
Is this something expected behavior? How can I fix it?
I realize that you are using dlopen, not CFBundle or NSBundle. Nevertheless, the Code Loading Programming Topics manual says this:
In Cocoa applications, you should not use CFBundle routines to load and unload executable code, because CFBundle does not natively support the Objective-C runtime. NSBundle correctly loads Objective-C symbols into the runtime system, but there is no way to unload Cocoa bundles once loaded due to a runtime limitation.
and this:
Because of a limitation in the Objective-C runtime system, NSBundle cannot unload executable code.
This makes me suspect that when you load your library, it registers itself with the Objective-C runtime, and the runtime calls dlopen on the library again (or somehow increases the library's reference count).
I searched the Objective-C runtime source code and found this:
// dylibs are not allowed to unload
// ...except those with image_info and nothing else (5359412)
if (result->mhdr->filetype == MH_DYLIB && _hasObjcContents(result)) {
dlopen(result->os.dl_info.dli_fname, RTLD_NOLOAD);
}
So yes, the Objective-C runtime is calling dlopen on your library specifically to prevent it from being unloaded. If you cheat and call dlclose twice, you should expect bad things to happen.
In my singleton release method, I have it doing nothing:
-(void) release {
//A whole lot of nothing.
}
But it produces this warning:
Warning: Conflicting distributed object modifiers on return type in implementation of 'release'
I googled and saw others have the same error, but no explanation of the warning. Anyone know what the warning is about?
You need to declare it oneway.
- (oneway void) release {}
oneway is a keyword used with distributed objects to indicate that the call can be made asynchronously. Since the NSObject header uses it when it declares the release method, you must also use it. It won't affect your program unless you use distributed objects, but it will satisfy the compiler.
In NSObject.h, the definition of the release method returns a oneway void.
The oneway keyword is used for distributed objects.
Since Xcode4.2 and LLVM, checkings are more strong and if it was accepted by previous versions of Xcode or by gcc, you now need to add this oneway keyword so that the LLVM compiler stops warning about this.
-(oneway void) release { /* do nothing */ }
This won't have any incident on your code.