ClassLoader.isAncestorOf(ClassLoader) Bug

by Daniel Janev » Tue, 24 Mar 2009 21:52:24 GMT


Sponsored Links
 Hello All,

Please someone from Google to comment this issue!

My colleagues has found a bug in the java.lang.ClassLoader
implementation of the cupcake tag of the Android platform. Here is a
short descriptions:

We try to invoke ClassLoader.getSystemClassLoader() in one of our OSGi
implementation classes and afterwards we have endless loop. Here are the
bodies of the methods:

public static ClassLoader getSystemClassLoader() {
  SecurityManager smgr = System.getSecurityManager();

  if (smgr != null) {
    ClassLoader caller = VMStack.getCallingClassLoader();
    if (caller != null && !caller.isAncestorOf(SystemClassLoader.loader)) {
      smgr.checkPermission(new RuntimePermission("getClassLoader"));
    }
  }
  return SystemClassLoader.loader;
}
...
and in isAncestorOf method we have:

final boolean isAncestorOf(ClassLoader child) {
  for (ClassLoader current = child; current != null; current =
child.parent) {
    if (current == this) {
      return true;
    }
  }
  return false;
}

In a dynamic environment like an OSGi implementation with set security
manager the isAncestorOf(...) follows to an endless loop. As you can see
- if the child is a custom class loader, which has another class loader
as a parent. The problem is that current is always is set to
child.parent but the child is never changed. The following code fixes
the problem:

final boolean isAncestorOf(ClassLoader child) {
  for (ClassLoader current = child; current != null; current =
current.parent) {
    if (current == this) {
      return true;
    }
  }
  return false;
}

I hope that you will be able to fix this as soon as possible and to
update the cupcake branch too. Please notify me when this is ready.

Thanks in advance!!

-- 

Best Regards,
    Daniel
---------------------------------------------------------------
Daniel Janev  Department Manager/Core Platform and Smart Home
ProSyst Software GmbH
1606 Sofia, Bulgaria  Vladajska Str. 48
Tel. +359 (0)2 952 35 81/109  Fax +359 (0)2 953 26 17
Mobile Phone +359 (0)888 678 670
 http://www.prosyst.com   d.ja...@prosyst.com
---------------------------------------------------------------
stay in touch with your product.
---------------------------------------------------------------

--~--~---------~--~----~------------~-------~--~----~



ClassLoader.isAncestorOf(ClassLoader) Bug

by Mark Murphy » Tue, 24 Mar 2009 22:00:35 GMT


 


Did you file this on  http://b.android.com ? That is the issue tracker for
Android. I do not see your issue out there, so I strongly encourage you
to file it there.


If you would take the time to file this on  http://b.android.com , you
will automatically be notified of progress on the issue.

-- 
Mark Murphy (a Commons Guy)
 http://commonsware.com 
Warescription: Three Android Books, Plus Updates, $35/Year

--~--~---------~--~----~------------~-------~--~----~


Sponsored Links


ClassLoader.isAncestorOf(ClassLoader) Bug

by Daniel Janev » Tue, 24 Mar 2009 22:14:12 GMT


 Thanks Mark,

I've posted the bug there.







-- 

Best Regards,
    Daniel
---------------------------------------------------------------
Daniel Janev  Department Manager/Core Platform and Smart Home
ProSyst Software GmbH
1606 Sofia, Bulgaria  Vladajska Str. 48
Tel. +359 (0)2 952 35 81/109  Fax +359 (0)2 953 26 17
Mobile Phone +359 (0)888 678 670
 http://www.prosyst.com   d.ja...@prosyst.com
---------------------------------------------------------------
stay in touch with your product.
---------------------------------------------------------------

--~--~---------~--~----~------------~-------~--~----~



Other Threads

1. Default video player application:rotation problem

I think you just want to use the video app portrait mode.
Just modify the Androidmanifest.xml file in video app's folder
orientation=landscape to portrait.




> website:

2. Context.getExternalFilesDir() folder is removed on app upgrade? Where to store data?

Greetings all,

Since API 8 (Froyo) we have a standard place to store application
files on external storage (read this article for more info:
http://developer.android.com/intl/fr/guide/topics/data/data-storage.html)

My existing application downloads a fair chunk of data to SD card on
the user's command to save space on the internal phone storage, which
as we all know is quite limited on most devices.  Previously I was
storing the data in a folder on the external storage root but thought
the "accepted" location was a good idea, especially since 2.2+ will
delete that folder when the app is uninstalled (which of course is not
the case for the folder I'm currently using, not to mention it messies
up the user's SD card).

The problem?  The folder is deleted when the application is upgraded,
not just installed.  This really defeats the purpose, since I don't
want to require my users to re-download the data (several megabytes)
every time I issue a bug fix (or any other) release.  I can't just
rely on installing the app to SD along with all the data in the apk
since the majority of devices do not yet have 2.2, and probably won't
for a long while.

Note that I can't verify that a market upgrade leaves the folder
intact, since I don't want to publish my new version until I know that
it won't delete the folder.  Can anyone speak if market upgrades do in
fact leave the folder intact?  Reinstalling via adb sure doesn't, so I
suspect the Market upgrade behavior is the same.

If that folder cannot be used, what's a better alternative than what
I'm doing now?  Ideally I'd like a folder that gets removed on
*uninstall*, but not *upgrade*.

Thanks for any good ideas.  :-)

Regards,
Jean-Guy

-- 

3. Memory Leak in Contact List

4. Gtalk tidak mau sign in

5. Fasilitas Video call android

6. Barnacle Wifi Tether (buat android kita sebagai hotspot)

7. Proxy support on Froyo