You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by "Karl Pauls (Jira)" <ji...@apache.org> on 2023/02/07 15:35:00 UTC

[jira] [Assigned] (FELIX-6591) Memory leak in Felix Framework Security extension

     [ https://issues.apache.org/jira/browse/FELIX-6591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Karl Pauls reassigned FELIX-6591:
---------------------------------

    Assignee: Karl Pauls

> Memory leak in Felix Framework Security extension
> -------------------------------------------------
>
>                 Key: FELIX-6591
>                 URL: https://issues.apache.org/jira/browse/FELIX-6591
>             Project: Felix
>          Issue Type: Bug
>          Components: Framework Security
>    Affects Versions: framework.security-2.8.3
>            Reporter: Chris Rankin
>            Assignee: Karl Pauls
>            Priority: Major
>              Labels: MemoryLeak, memory-leak
>
> Our project loads and unloads a lot of bundles over time, and we have noticed that the JVM quickly spends the majority of its time collecting its garbage.
> We have identified the Framework Security extension as one source of this problem. Specifically, the suspiciously large number of {{Conditions}} and {{Permissions}} objects in every heap dump.
> The {{Permissions}} objects are _definitely_ leaking because {{Permission.Entry.hashCode()}} should use {{Arrays.hashCode(entry)}} instead of {{entry.hashCode()}} when {{entry}} is an array.
> I have also reimplemented {{Conditions}} to listen for {{BundleEvent.UNINSTALLED}} instead of relying on multiple {{{}WeakHashMap{}}}s. This is consistent with a TODO comment for this class, and allows the {{Conditions}} objects to be deleted _immediately_ instead of waiting for the garbage collector to realise that they are no longer referenced.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)