Re: Content provider dies while a client is in the middle of a query

[Jeffrey Blattman]

would really like to have an answer to this as well. it makes it very difficult to build an app that is resilient against crashes in another app that hosts a content provider.

On Wednesday, December 19, 2012 7:31:14 PM UTC-8, Agus Santoso wrote:

Hi everyone,

On android platforms (confirmed on ICS), if a content provider dies while a client is in the middle of a query (i.e. has a open cursor) the framework decides to kill the client processes holding a open cursor.

Here is a logcat output when i tried this with a download manager query that sleeps after doing a query. The "sleep" was to reproduce the problem. you can imagine it happening in a regular use case when the provider dies at the right/wrong time. And then do a kill of com.android.media (which hosts the downloadProvider).

"Killing com.example (pid 12234) because provider com.android.providers.downloads.DownloadProvider is in dying process android.process.media"

I tracked the code for this in ActivityManagerService::removeDyingProviderLocked

10203     private final void removeDyingProviderLocked(ProcessRecord proc,

10204             ContentProviderRecord cpr) {

10205         synchronized (cpr) {

10206             cpr.launchingApp = null;

10207             cpr.notifyAll();

10208         }

10210         mProvidersByClass.remove(cpr.name);

10211         String names[] = cpr.info.authority.split(";");

10212         for (int j = 0; j < names.length; j++) {

10213             mProvidersByName.remove(names[j]);

10214         }

10215

 10216         Iterator<ProcessRecord> cit = cpr.clients.iterator();

10217         while (cit.hasNext()) {

10218             ProcessRecord capp = cit.next();

10219             if (!capp.persistent && capp.thread != null

10220                     && capp.pid != 0

10221                     && capp.pid != MY_PID) {

10222                 Slog.i(TAG, "Kill " + capp.processName

10223                         + " (pid " + capp.pid + "): provider " + cpr.info.name

10224                         + " in dying process " + (proc != null ? proc.processName : "??"));

10225                 EventLog.writeEvent(EventLogTags.AM_KILL, capp.pid,

10226                         capp.processName, capp.setAdj, "dying provider "

10227                                 + cpr.name.toShortString());

10228                 Process.killProcessQuiet(capp.pid);

10229             }

10230         }

10231

 10232         mLaunchingProviders.remove(cpr);

10233     }

Is this a policy decision or is the cursor access unsafe after the provider has died?

It looks like the client cursor is holding a fd for an ashmem location populated by the CP. Is this the reason the clients are killed instead of throwing an exception like Binders when the server (provider) dies ?

[Jean-Baptiste Queru]

The best approach is probably to contribute a change that shows the kind of API change that'd satisfy your needs. That way, we'll have something concrete to discuss.

JBQ

--
You received this message because you are subscribed to the Google Groups "android-platform" group.

To unsubscribe from this group and stop receiving emails from it, send an email to android-platfo...@googlegroups.com.

To post to this group, send email to android-...@googlegroups.com.

Visit this group at http://groups.google.com/group/android-platform.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
Jean-Baptiste M. "JBQ" Queru
Technical Lead, Android Open Source Project, Google.

Questions sent directly to me that have no reason for being private will likely get ignored or forwarded to a public forum with no further warning.

[Arun Joseph]

Hello,

Was there a change already submitted on this?

Regards,

Arun