Skip to content

Prevent "Unknown app_id" crashes #2

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 11 commits into
base: master
Choose a base branch
from

Conversation

lbielski
Copy link

@lbielski lbielski commented Jun 2, 2015

applicationSentListing is invoked when tab is changed. Sometimes there can be situation when the tab's app id is not in the hash table
It can occur when Safari was in background when proxy was launched or Safari goes into background and comes back again (SafariLauncher).
When such situation occur just ignore the update and don't crash the proxy

jchuong and others added 11 commits December 15, 2014 12:42
Appium / instruments was sending a new message that wasn't handled
previously, applicationUpdated.  It seems to be changing one PID
to a new PID, so we remove the old PID from the hash table, and
insert the new one.
Skipping print statement that segfaults
Trying to swap the two app_ids to fix error.
Cleaned up iwdp_on_applicationUpdated()
applicationSentListing would often error out with Unknown app [app_id]
since connectedApplications would be sent an empty list of connected
apps. Thus, all apps were removed from the hash table, even though
automated testing was going on.

This isn't particularly pretty work around for automated testers,
but outside of long stress tests of multiple apps, this should be
no issue
applicationSentListing is invoked when tab is changed. Sometimes there can be situation when the tab's app id is not in the hash table
It can occur when Safari was in background when proxy was launched or Safari goes into background and comes back again (SafariLauncher).
When such situation occur just ignore the update and don't crash the proxy
@jchuong
Copy link
Owner

jchuong commented Jun 6, 2015

Sorry I haven't replied to this yet. I think that this method is a bit heavy handed in the solution, basically chucking out any sort of errors and assume it's fine... I think most people will find this is a good enough solution that will solve most issues for the future due to plist changes but of course there might be an actual issue that arises and is simply passed off with this patch. I will mull it over for a bit, maybe you can put this PR on the Google repository instead and see what other's think.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants