Open Leon-cam opened 1 month ago
Just updated my local environment for this issue.
Environment:
In some instances during testing, the REMOVE_EVENT did not arrive for a device that was successfully restored. Current solution might be causing an indefinite loop since the flag is not being reset properly. It might need another flag for this case.
I recommend adding a flag, such as int restore_started
to the idevicerestore_client_t
structure. This flag would indicate whether the restoration process is ongoing and would be reset in the callback upon receiving a REMOVE event. This approach allows the upper caller to check the flag within its thread before releasing the client instance, ensuring safe and proper cleanup. The previous use of ignore_device_add_events
is not suitable for this case.
Hello Nikias Bassen,
Could you please review the following content? I would greatly appreciate any insights or feedback you could provide.
Regarding the implementation in restore.c. There are two static variables declared:
static int restore_finished = 0;
static int restore_device_connected = 0;
It appears that the static variable restore_device_connected
is not utilized within the scope of the project. It may be an unnecessary artifact?
Additionally, it would be more efficient and maintainable to refactor the restore_finished variable. Instead of being a static variable, it would be better to integrate it into the idevicerestore_client_t C struct as a member variable.
Best regards, Leon
I also hope there is a version that supports multi-threaded concurrency
https://github.com/libimobiledevice/idevicerestore/issues/630
This problem may be similar to what you said
I'm encountering an issue when using idevicerestore in a multi-threaded application. The problem arises after the idevicerestore_start function finishes restoring an iOS device. The application releases the idevicerestore_client instance, but a remove event arrives later, causing the application to crash. The crash occurs at the
strcmp(event->udid, client->udid)
line in the callback function because the client instance has already been released.Here is the relevant part of the callback function that handles the remove event:
I attempted to manage the client release by waiting for the ignore_device_add_events flag to reset using the following code, but it did not work as expected:
Here is the full C++ code that demonstrates how the client instance is managed and released:
I would appreciate any suggestions or insights on how to properly manage the idevicerestore client release in a multi-threaded application. Specifically, I'm looking for guidance on ensuring that the remove event is handled correctly before releasing the client instance to prevent crashes.