[WORKAROUND] Bootloops due leaking handles with Xposed in Lollipop

Did you tried and it worked?

  • YES! It worked without problems.

    Votes: 110 64.3%
  • Yes, but not easy, required further editing.

    Votes: 12 7.0%
  • NO, unfortunately that did not helped.

    Votes: 24 14.0%
  • I don't understand what it is about....

    Votes: 25 14.6%

  • Total voters
    171
Status
Not open for further replies.
Search This thread

ondrejvaroscak

Senior Member
Jan 21, 2015
1,517
1,159
Aachen
Fix found and released:

http://forum.xda-developers.com/showthread.php?p=60454547

Downloads & instructions: http://forum.xda-developers.com/showthread.php?t=3034811

Discussion & Q&A:http://forum.xda-developers.com/xposed/official-xposed-lollipop-t3030118

I asked moderator to close this thread as issue was fixed by releasing new version of Xposed framework. Please send your further questions and post to respective thread.





This thread is about workaround found for bootloops of Xposed in XPERIA family Lollipop. Because of development progress, I have decided to remove historical development, you can see it here:

LATEST VERSION will be always posted at the END of this post

PLEASE READ INSTRUCTIONS .... The attachment IS NOT flashable!!! For flashables see EDIT 5 and bellow...

I hope I can present some good news for users with locked bootloaders who are getting bootloops with Xposed and Lollipop.

This is still continuous WIP. Know what you do, this is a development thread.

For time being, most complete solution by my opinion was made by @mionica, see EDIT 6 and hist post http://forum.xda-developers.com/showpost.php?p=60298690&postcount=123? and for latest development at http://forum.xda-developers.com/showpost.php?p=60333600&postcount=285

As you may already know, we have find out, that some undetected error is causing system to bootloop, if too many applications are installed.
Exact numbers are varying between different ROMs and devices, generally the maximum number of apps is about 320-330.
Debloating (uninstalling unnecessary apps) helps, but remains limiting and for many frustrating. After a research, we have found out,
that there is probably a bug, that is causing many files being left open when booting Lollipop with Xposed.

Users on unlocked bootloader may modify certain kernel parameters to raise number of open files. This can not be done on Locked Bootloader.
After some research and hours of experiments, I found a way, how to change the filelimit for Zygote and subsequent processes. Therefore every child of zygote (hence every app etc.) will inherit raised open files limit from 1024 to 4096.

This change should work on all 5.0 compatible system, not only XPERIAs, however I only tested it on Z3 D6603 fw 690. But the modification
is done on Linux system level, therefore it should teoretically work just everywhere... It should work also on Locked bootloaders as well.

The principle is easy, however implementation was a tricky, because of lack of native linux utils support on Android and fact that we can not
easily modify booting behaviour. But gladly enough we have XZDualRecovery (gret thanks @[NUT])....

XZDualRecovery enables to call init scripts on startup. I have created a startup script that waits for zygote process to come up, and calls
external program that changes open file limits for that process. This external program is compiled by me from source provided by http://lzone.de/cheat-sheet/ulimit

Prerequisities: Functional XZDualRecovery or other form of init.d support.

Installation:

Extract downloaded ZIP file, it contains:
flimit-binary executable for changing open file limits
01_flimit - shell script called by init
flimit.c - source code of binary executable

Enable init.d support in XZDualRecovery by editing XZDR.prop and change dr.initd.active=true
Dont forget to have enabled byeselinux (dr.keep.byeselinux=true)
copy flimit and 01_flimit to /data/local/tmp (or push adb)
remount /system rw (mount -o remount,rw /system)
create directory /data/flimit
copy flimit to /data/flimit and make executable (chmod 777)
create directory /system/etc/init.d with and chmod 777 /system/etc/init.d
copy 01_flimit to /system/etc/init.d and chmod 777 /system/etc/init.d/01_flimit

test run installation:
Code:
su
/data/flimit/flimit $(pgrep zygote)

output should be:
Code:
[email protected]:/data # /data/flimit/flimit $(pgrep zygote)                       
Previous limits: soft=1024; hard=4096
New limits: soft=4096; hard=4096

If not, check permissions etc.

Check script by running:
Code:
su
sh /system/etc/init.d/01_flimit

it should now give output (if you succesfully ran /data/flimit/flimit....):
Code:
[email protected]:/data # /data/flimit/flimit $(pgrep zygote)                       
Previous limits: soft=4096; hard=4096
New limits: soft=4096; hard=4096

reboot

Thats all. Now you can install and update lot more applications. Now I have about 455 packages reported by pm list packages and no bootloop.
But as soon as I disable the init.d support, it bootloops. So re-enable by edititng XZDR.prop and it again boots.

EDIT:Please let me know, if you had to modify the script or instructions to work on your device, so I can perhaps make better or more universal version. Thank you guys.

EDIT 2:While this workaround makes it possible to run Xposed on untouched vanilla Stock ROM, you may still consider debloating it, as debloating will make run your device more smoothly and saves battery. Guys who made debloating scripts made significant efforts in identifying which apps can be safely removed without harming any significant functionality.

EDIT 3:The ZIP is NOT flashable, follow instructions ^^^^ --- buddy @McBane87 is developing flashable version.

EDIT 4:Buddy @nurps found a bug causing Opera browser to quit upon starting. @mionica proposed lowering softlimits for open files to 2048 from 4096 in first version of script. Version 1.1 is released.

EDIT 5:Buddy @McBane87 created customized flashable version of this workaround, so you can flash it from recovery if you struggle with bootloops, dont like to wait fro 300apps to optimize after Dalvik wipe and mess with adb/terminal..
http://forum.xda-developers.com/showthread.php?p=60276913

EDIT 6:Buddy @mionica published another flashable zip. It is complete installer for the workaround, so far most sofisticated workaround from system point of view. The uninstaller completely removes Xposed if you are too tired of it and forgot to make backup :) Files are bellow, for instructions etc. check it out on http://forum.xda-developers.com/showpost.php?p=60298690&postcount=123 and for latest development at http://forum.xda-developers.com/showpost.php?p=60333600&postcount=285

Changelog:

v1: Initial release
v1.1: Changed limits to 2048 from 4096 as high limits caused Opera Webbrowsers to crash
v2.0 Reference script - for production please flash @mionica version of flashable, my script is published for educational purposes. added mionicas mod to detect only changed limits and subsequently remove only those that are child of zygote

***************************************
I would like to thank mainly to @[NUT] and to guys who made significant effort with debloating, made other discoveries or were an inspiration
for me, including but not limited to @serajr @moly82 @AndroPlus (for his work on file limits in kernel) @redincali and of course to @rovo89
for his Xposed framework. My apologies if I forgot someone, PM me, its 2 o'clock in morning :)

or in this post http://forum.xda-developers.com/showpost.php?p=60349914&postcount=354

While I have developed initial version (see history), other guys (mainly @mionica and @McBane87) greatly enhanced and redeveloped whole thing.

Current development version and downloadable files you can always find in @mionica post http://forum.xda-developers.com/showpost.php?p=60298690&postcount=123

@mionica managed to analyze boot process on both ROMs with and without Xposed and came to conclusion that leaks are caused by Xposed process leaking open file handles, see here http://forum.xda-developers.com/showpost.php?p=60373854&postcount=417

There is a current version of the workaround fix (see above), that seems to be the last possible, before Xposed will be released with patch addressing that issue. Good news is that thanks to @mionica precise analysis, @rovo89 - developer of Xposed is already aware of the problem nad it´s cause.


Recommended installation steps:

by @mionica
Anybody who is still having any kind of issues, for whatever reason, please do the following:
  • get into TWRP;
  • install, in this order, without rebooting:
    • xposed-uninstall-v1.1.zip
      • If you don't have an sd card, you'll need to reboot once after the uninstall .zip, boot the system normally, then get back in the recovery and install the other 3. This only applies to people who don't use an SD card
    • xzdr-busybox-enable-v1.0.zip
    • xposed-sdk21-arm-date.zip
    • xposed-leakplug-v1.2.zip
  • copy the logs to the PC, over USB:
    • uninstall_xposed.log
    • install_busybox.log
    • install_leakplug.log
    each of the 3 zip's will tell you where it saved the log (it's usually the external sdcard)
  • reboot to system :)
Thanks in advance for not asking any questions about whether you have to do any of these steps; yes, you have to.

If you follow other instructions than provided by @mionica please get then support from someone else than him.

The basic idea behind is that Xposed bootloops because of it exhausted resources available due to probably internal bug. The workaround basically provides higher limits for open files during boot and restores previous limits after device has booted. The latest flashable installer is very advanced and automates the installation, including necessary checks for proper XZDR configuration, busybox etc.

When you experience bootloops after installing Xposed, or you had Xposed working and it started to bootloop after you have installed new app or upgraded a system app, simply reboot to recovery and flash the zip. No need to wipe anything.

When installing new, I recommend flashing this zip first, then install Xposed usual way (flash, wipe, reboot, install Xposed apk, install modules).

Be aware that while the workaround works for about 80% of cases, there are people who have lots of applications or heavily modified system, experiencing random reboots. Cause is under investiogation, but most probably is in Xposed itself.
 
Last edited:

NetSkill

Senior Member
Aug 3, 2011
650
236
Slovakia
I am gonig to try this asap! Awesome job!
One more thing, if i understand right, now we can install as many apps as we want or the limit is just higher but still there?

Can we now use regular reboot button from power menu withouth getting bootloop?

--Guys lets go ahead and rape the thanks button :D
 
Last edited:

ondrejvaroscak

Senior Member
Jan 21, 2015
1,517
1,159
Aachen
I am gonig to try this asap! Awesome job!
One more thing, if i understand right, now we can install as many apps as we want or the limit is just higher but still there?

Can we now use regular reboot button from power menu withouth getting bootloop?

--Guys lets go ahead and rape the thanks button :D

Unless I will be blessed with some debugging skills, I have no clue... I think limit is just much higher. Once you reach limit you can simply edit script and change two numbers...

Yes, now regular reboot works.

Sent from my D6603 using XDA Free mobile app
 
Last edited:
  • Like
Reactions: NetSkill

ondrejvaroscak

Senior Member
Jan 21, 2015
1,517
1,159
Aachen
Thank you @ondrejvaroscak for this solution!

@rovo89 any chance this could be integrated in the xposed installer?

I think it will take time, because first @rovo89 would probably want to investigate, how much is it a bug, a constellation of coincidences and so on. I am not sure, if the same bootloops appear only on XPERIAs or it is a phenomenon on other brands as well... And given the fact, that big number of Samsungs can not run Xposed at all, maybe he will try to solve that Samsung puzzle as priority. But that is only guess..
 

hispanico957

Senior Member
Mar 14, 2011
1,543
347
Installation:

Extract downloaded ZIP file, it contains:
flimit - binary executable for changing open file limits
01_flimit - shell script called by init
flimit.c - source code of binary executable

Enable init.d support in XZDualRecovery by editing XZDR.prop and change dr.initd.active=true
Dont forget to have enabled byeselinux (dr.keep.byeselinux=true)
copy flimit and 01_flimit to /data/local/tmp (or push adb)
create directory /data/flimit
copy flimit to /data/flimit and make executable (chmod 777)
create directory /system/etc/init.d with and chmod 777 /system/etc/init.d
copy 01_flimit to /system/etc/init.d and chmod 777 /system/etc/init.d/01_flimit

Thank a lot for big news.... just a clarification:

Which xdual recovery we must have ? also the last 2.8.12 ?
The file XZDR.prop i have located on external memoery...it's correct ?
When you said create a directory /data/flimit.. in where ?
In which way i can "..enabled byeselinux (dr.keep.byeselinux=true).."

Thank
Hispa
 
Last edited:

ondrejvaroscak

Senior Member
Jan 21, 2015
1,517
1,159
Aachen
Thank a lot for big news.... just a clarification:

Which xdual recovery we must have ? also the last 2.8.12 ?
The file XZDR.prop i have located on external memoery...it's correct ?
When you said create a directory /data/flimit.. in where ?
In which way i can "..enabled byeselinux (dr.keep.byeselinux=true).."

Thank
Hispa

Any recovery that supports init.d and byeselinux. So if you find this two settings in your XZDR.prop, you just enable them by setting "true".
I tested with 2.8.12,
XZDR.prop is located in /sdcard1 so its External SD card. If no SD card, then its located in /cache.

/data/limit you create absolutely, it means in / is folder data (that already exists) and you create flimit in /data, so:
Code:
adb shell
su
mkdir /data/flimit

byeselinux you enable by setting "dr.keep.byeselinux=true" in XZDR.prop (it may be set to false by default depending on version fo XZDR you have).
 
  • Like
Reactions: hispanico957

hispanico957

Senior Member
Mar 14, 2011
1,543
347
Ok fine... for verify all you said:
9CDl9iq.jpg


dont find ? where i wrong ??? the folder and file are present

Thank
Hispa

P.S.
Whe you said :
But as soon as I disable the init.d support, it bootloops. So re-enable by edititng XZDR.prop and it again boots.

i mean to pu dr.initd.active=false ??

and last :) after all i can install xposed over .726 odexed ?
 
Last edited:

ondrejvaroscak

Senior Member
Jan 21, 2015
1,517
1,159
Aachen
Ok fine... for verify all you said:
9CDl9iq.jpg


dont find ? where i wrong ??? the folder and file are present

can you run "ls -l /data/flimit/*" and paste output to reply?

Whe you said :


i mean to pu dr.initd.active=false ??
Exactly, when you put dr.initd.active=false and have full stock, it should again bootloop. Then you replace the XZDR.prop file with version with init.d enabled and it should boot normally again.

and last :) after all i can install xposed over .726 odexed ?

I think without any problem. Deodexing has nothing to do with working Xposed, but it is may be necessary for some modules (Gravitybox?)?
 
Status
Not open for further replies.

Top Liked Posts

  • There are no posts matching your filters.
  • 164
    Fix found and released:

    http://forum.xda-developers.com/showthread.php?p=60454547

    Downloads & instructions: http://forum.xda-developers.com/showthread.php?t=3034811

    Discussion & Q&A:http://forum.xda-developers.com/xposed/official-xposed-lollipop-t3030118

    I asked moderator to close this thread as issue was fixed by releasing new version of Xposed framework. Please send your further questions and post to respective thread.





    This thread is about workaround found for bootloops of Xposed in XPERIA family Lollipop. Because of development progress, I have decided to remove historical development, you can see it here:

    LATEST VERSION will be always posted at the END of this post

    PLEASE READ INSTRUCTIONS .... The attachment IS NOT flashable!!! For flashables see EDIT 5 and bellow...

    I hope I can present some good news for users with locked bootloaders who are getting bootloops with Xposed and Lollipop.

    This is still continuous WIP. Know what you do, this is a development thread.

    For time being, most complete solution by my opinion was made by @mionica, see EDIT 6 and hist post http://forum.xda-developers.com/showpost.php?p=60298690&postcount=123? and for latest development at http://forum.xda-developers.com/showpost.php?p=60333600&postcount=285

    As you may already know, we have find out, that some undetected error is causing system to bootloop, if too many applications are installed.
    Exact numbers are varying between different ROMs and devices, generally the maximum number of apps is about 320-330.
    Debloating (uninstalling unnecessary apps) helps, but remains limiting and for many frustrating. After a research, we have found out,
    that there is probably a bug, that is causing many files being left open when booting Lollipop with Xposed.

    Users on unlocked bootloader may modify certain kernel parameters to raise number of open files. This can not be done on Locked Bootloader.
    After some research and hours of experiments, I found a way, how to change the filelimit for Zygote and subsequent processes. Therefore every child of zygote (hence every app etc.) will inherit raised open files limit from 1024 to 4096.

    This change should work on all 5.0 compatible system, not only XPERIAs, however I only tested it on Z3 D6603 fw 690. But the modification
    is done on Linux system level, therefore it should teoretically work just everywhere... It should work also on Locked bootloaders as well.

    The principle is easy, however implementation was a tricky, because of lack of native linux utils support on Android and fact that we can not
    easily modify booting behaviour. But gladly enough we have XZDualRecovery (gret thanks @[NUT])....

    XZDualRecovery enables to call init scripts on startup. I have created a startup script that waits for zygote process to come up, and calls
    external program that changes open file limits for that process. This external program is compiled by me from source provided by http://lzone.de/cheat-sheet/ulimit

    Prerequisities: Functional XZDualRecovery or other form of init.d support.

    Installation:

    Extract downloaded ZIP file, it contains:
    flimit-binary executable for changing open file limits
    01_flimit - shell script called by init
    flimit.c - source code of binary executable

    Enable init.d support in XZDualRecovery by editing XZDR.prop and change dr.initd.active=true
    Dont forget to have enabled byeselinux (dr.keep.byeselinux=true)
    copy flimit and 01_flimit to /data/local/tmp (or push adb)
    remount /system rw (mount -o remount,rw /system)
    create directory /data/flimit
    copy flimit to /data/flimit and make executable (chmod 777)
    create directory /system/etc/init.d with and chmod 777 /system/etc/init.d
    copy 01_flimit to /system/etc/init.d and chmod 777 /system/etc/init.d/01_flimit

    test run installation:
    Code:
    su
    /data/flimit/flimit $(pgrep zygote)

    output should be:
    Code:
    [email protected]:/data # /data/flimit/flimit $(pgrep zygote)                       
    Previous limits: soft=1024; hard=4096
    New limits: soft=4096; hard=4096

    If not, check permissions etc.

    Check script by running:
    Code:
    su
    sh /system/etc/init.d/01_flimit

    it should now give output (if you succesfully ran /data/flimit/flimit....):
    Code:
    [email protected]:/data # /data/flimit/flimit $(pgrep zygote)                       
    Previous limits: soft=4096; hard=4096
    New limits: soft=4096; hard=4096

    reboot

    Thats all. Now you can install and update lot more applications. Now I have about 455 packages reported by pm list packages and no bootloop.
    But as soon as I disable the init.d support, it bootloops. So re-enable by edititng XZDR.prop and it again boots.

    EDIT:Please let me know, if you had to modify the script or instructions to work on your device, so I can perhaps make better or more universal version. Thank you guys.

    EDIT 2:While this workaround makes it possible to run Xposed on untouched vanilla Stock ROM, you may still consider debloating it, as debloating will make run your device more smoothly and saves battery. Guys who made debloating scripts made significant efforts in identifying which apps can be safely removed without harming any significant functionality.

    EDIT 3:The ZIP is NOT flashable, follow instructions ^^^^ --- buddy @McBane87 is developing flashable version.

    EDIT 4:Buddy @nurps found a bug causing Opera browser to quit upon starting. @mionica proposed lowering softlimits for open files to 2048 from 4096 in first version of script. Version 1.1 is released.

    EDIT 5:Buddy @McBane87 created customized flashable version of this workaround, so you can flash it from recovery if you struggle with bootloops, dont like to wait fro 300apps to optimize after Dalvik wipe and mess with adb/terminal..
    http://forum.xda-developers.com/showthread.php?p=60276913

    EDIT 6:Buddy @mionica published another flashable zip. It is complete installer for the workaround, so far most sofisticated workaround from system point of view. The uninstaller completely removes Xposed if you are too tired of it and forgot to make backup :) Files are bellow, for instructions etc. check it out on http://forum.xda-developers.com/showpost.php?p=60298690&postcount=123 and for latest development at http://forum.xda-developers.com/showpost.php?p=60333600&postcount=285

    Changelog:

    v1: Initial release
    v1.1: Changed limits to 2048 from 4096 as high limits caused Opera Webbrowsers to crash
    v2.0 Reference script - for production please flash @mionica version of flashable, my script is published for educational purposes. added mionicas mod to detect only changed limits and subsequently remove only those that are child of zygote

    ***************************************
    I would like to thank mainly to @[NUT] and to guys who made significant effort with debloating, made other discoveries or were an inspiration
    for me, including but not limited to @serajr @moly82 @AndroPlus (for his work on file limits in kernel) @redincali and of course to @rovo89
    for his Xposed framework. My apologies if I forgot someone, PM me, its 2 o'clock in morning :)

    or in this post http://forum.xda-developers.com/showpost.php?p=60349914&postcount=354

    While I have developed initial version (see history), other guys (mainly @mionica and @McBane87) greatly enhanced and redeveloped whole thing.

    Current development version and downloadable files you can always find in @mionica post http://forum.xda-developers.com/showpost.php?p=60298690&postcount=123

    @mionica managed to analyze boot process on both ROMs with and without Xposed and came to conclusion that leaks are caused by Xposed process leaking open file handles, see here http://forum.xda-developers.com/showpost.php?p=60373854&postcount=417

    There is a current version of the workaround fix (see above), that seems to be the last possible, before Xposed will be released with patch addressing that issue. Good news is that thanks to @mionica precise analysis, @rovo89 - developer of Xposed is already aware of the problem nad it´s cause.


    Recommended installation steps:

    by @mionica
    Anybody who is still having any kind of issues, for whatever reason, please do the following:
    • get into TWRP;
    • install, in this order, without rebooting:
      • xposed-uninstall-v1.1.zip
        • If you don't have an sd card, you'll need to reboot once after the uninstall .zip, boot the system normally, then get back in the recovery and install the other 3. This only applies to people who don't use an SD card
      • xzdr-busybox-enable-v1.0.zip
      • xposed-sdk21-arm-date.zip
      • xposed-leakplug-v1.2.zip
    • copy the logs to the PC, over USB:
      • uninstall_xposed.log
      • install_busybox.log
      • install_leakplug.log
      each of the 3 zip's will tell you where it saved the log (it's usually the external sdcard)
    • reboot to system :)
    Thanks in advance for not asking any questions about whether you have to do any of these steps; yes, you have to.

    If you follow other instructions than provided by @mionica please get then support from someone else than him.

    The basic idea behind is that Xposed bootloops because of it exhausted resources available due to probably internal bug. The workaround basically provides higher limits for open files during boot and restores previous limits after device has booted. The latest flashable installer is very advanced and automates the installation, including necessary checks for proper XZDR configuration, busybox etc.

    When you experience bootloops after installing Xposed, or you had Xposed working and it started to bootloop after you have installed new app or upgraded a system app, simply reboot to recovery and flash the zip. No need to wipe anything.

    When installing new, I recommend flashing this zip first, then install Xposed usual way (flash, wipe, reboot, install Xposed apk, install modules).

    Be aware that while the workaround works for about 80% of cases, there are people who have lots of applications or heavily modified system, experiencing random reboots. Cause is under investiogation, but most probably is in Xposed itself.
    87
    workaround for xposed reboots

    EDIT: This fix is no longer required. No more bootloops, no more random reboots.
    To uninstall leakplug, remove /system/etc/init.d/01_flimit and /system/xbin/flimit; but only do that after the you flashed an xposed_arm zip no older than alpha #4 20150430.


    I had previously identified the cause of the problem; I also thought I had fixed it :( but I simply had the bad luck to get the fix for the bug I found in the Xposed source code, in the same build as the real fix.

    --------------------

    Hi guys,

    News:
    • xposed-uninstall v1.1
      • removes Xposed altogether (no parts left behind :D)
      • removes the Xposed app
      • removes leakplug, leak_workaround and/or sonyfix
      • wipes Dalvik cache and /cache
      • resets XZDR settings to no-initd / enforcing SElinux
    • xzdr-busybox-enable v1.0 - this enables all the applets of the XZDR busybox so you won't need an installer app
    • xposed-leakplug v1.2 (formerly xposed-leak_workaround) - now with the same debug capabilities as sonyfix, which is now deprecated
    .

    Anybody who is still having any kind of issues, for whatever reason, please do the following:
    • get into TWRP;
    • install, in this order, without rebooting:
      • xposed-uninstall-v1.1.zip
      • xzdr-busybox-enable-v1.0.zip
      • xposed-sdk21-arm-date.zip
      • xposed-leakplug-v1.2.zip
    • copy the logs to the PC, over USB:
      • uninstall_xposed.log
      • install_busybox.log
      • install_leakplug.log
      each of the 3 zip's will tell you where it saved the log (it's usually the external sdcard)
    • reboot to system
    • reinstall the Xposed .apk (which gets removed in the process)
    • enjoy!
    <rant target="noobs">
    Thanks in advance for not asking any questions about whether you have to do any of these steps; yes, you have to.
    If you didn't do exactly like I said, and it isn't working, please ask in another thread; this one is for people who are able to follow instructions.
    If you can't understand what you have to do, then this is NOT for you - please wait for the Xposed bugfix instead.

    All help requests will be ignored unless they have the following files attached: uninstall_xposed.log, install_busybox.log, install_leakplug.log
    </rant>

    This is still required for Xposed LP alpha3, which hasn't solved the leak yet (reported here :p).

    For non-Sony devices, xposed-leakplug should work, if your system has 1) init.d support; 2) permissive SElinux; 3) busybox (for busybox, I recommend you get rid of all installer apps, and use the attached zip). It will throw a few warnings about XZDR, I expect, but you can safely ignore those.

    This works by setting the soft file limit of the offending process (system_server) to the maximum allowed by the kernel. So it will still crash - it will do so, however, as late and as rarely as possible.

    ----

    Changelog: (click on a version number to see the expanded changelog for that version)
    • xposed-leakplug 1.2 - fixed a (XZDR upgrade-related) bug that caused the script to be started twice - generating massive system instability
    • xposed-leakplug 1.1 - merged the debug features from xposed-sonyfix into xposed-leak_workaround, thus deprecating xposed-sonyfix
    • xposed-leak_workaround - a simpler version of sonyfix 3.0b which only did what was required to maximize the runtime despite the leaks
    • xposed-sonyfix 3.0b:
      • v3.0b: prints a very nice process list with details to the log, after boot completes
      • v3.0a: fixed a nasty installer bug - the 2nd script (98*) of v2.x wasn't properly removed - which immediately trigger issues
      • fully automated (.prop file was removed), single-script;
      • the flimits are set correctly on boot (v2.x missed a bunch of early processes)
      • the soft flimit is only restored on boot completion for processes who don't have a lot of open files at that time
        • for processes with a lot of open files, the limit is set to a reasonable number - that process is allowed to open at least 512 more files
      • the flimit update procedures are repeated as many times as it takes
      • now only logging to /tmp/flist.log; logcat is sampled once before waiting for the boot to finish, once when we're done - at which time, dmesg is also sampled; these logs, in .log.bz2 format, are available in /tmp
      • other changes of lesser importance (code cleanup etc.)
    • xposed-sonyfix 2.5a, 2.5:
      • cleaned up and improved the process of restoring flimits
      • since this version, it is strongly recommended to be on the latest XZDR!
      • got rid of the hardcoded 1024 4096 flimits for restore; the original values of zygote are used instead
        • however, fl.after.boot.* props are still honored (they take precedence), and flimit restoring can still be disabled altogether
      • the init.d scripts log everything they do
      • dmesg is sampled after the 98* script completes; 4 logcat samples are captured (before waiting for zygote to load, after the 01* script completes, before waiting for boot completion and after the 98* script completes)
      • .prop file setting were added, allowing the dating and copying to the internal sdcard of those log samples (one setting for dmesg, another one for the logcat's); these options are off by default, but the logs are still available under /tmp
      • if saving either kind is enabled, the flimit log (both 01* and 98*) is also dated and saved
      • the flimit.prop.sample in the .zip was updated with these new options
      • other minor changes
    • xposed-sonyfix 2.4:
      • flimits are reverted for the entire zygote process tree (previously, only zygote and its first-order children were restored - bug)
      • accepts configuration from a flimit.prop placed in the same folder as XZDR.prop (/storage/sdcard1/XZDualRecovery)
      • a sample .prop file exists in the .zip, and explains the syntax; it is not extracted, extract it yourself
      • the .prop file is not required; if it's missing, the default values are exactly the same as for 2.3 and below;
      • the .prop also allows you to leave the boot limits in place after boot completes;
      • timing and other minor changes
    • xposed-sonyfix 2.3:
      • vastly improved busybox installer, which also cleans up after previous (busybox) installations
    • xposed-sonyfix 2.2:
      • fully self-contained - includes a busybox install/update script that makes sure that the needed busybox applets exist under /system/xbin; if you have XZDR, the existing XZDR busybox will be used, if not, the XZDR busybox will be installed (to /system/xbin)
      • made sure the init.d scripts use specifically, and only, those applets from /system/xbin
    • xposed-sonyfix 2.1:
      • changed the granularity of the boot completed check from 1s to 100ms
      • faster flimits restore, by only looking at zygote and its descendants (from here, thanks @ondrejvaroscak!)
    • xposed-sonyfix 2.0:
      • added cleanup after the XZDR.prop installer bug in v1;
      • fixed the installer bug
      • changed the inter-step delay to 100ms when reverting flimit changes
    • xposed-sonyfix:
      • initial release
    43
    Hey Guys,

    Just create two flashable ZIP-Files.
    Hopefully it will be easier for you this way.

    XZDR-Init.d-Enabler:

    This Script will search for your XZDR.prop-File in 3 ways (one other another):
    1. Try to find File in "/storage/sdcard1/XZDualRecovery" (CWM)
    2. Try to find FIle in "/external_sd/XZDualRecovery" (TWRP)
    3. Try to find File via [find / -name XZDR.prop 2>/dev/null] , but will only use finding if there is only one XZDR.prop-FIle in System found.

    After that it will edit your XZDR.prop and adds the two props @ondrejvaroscak mentioned:
    Code:
    sed -i '/dr.initd.active/d' $XZDR_File
    echo "dr.initd.active=true" >> $XZDR_File
    sed -i '/dr.keep.byeselinux/d' $XZDR_File
    echo "dr.keep.byeselinux=true" >> $XZDR_File

    Finally it will create init.d folder in: /system/etc/init.d

    FLimit Flashable:
    This will copy the binary "flimit" to "/system/bin" (did it it little bit different here) and "01_flimit" to "/system/etc/init.d/"

    ondrejvaroscak just released v1.1, so files are:

    v1.0 = flimit_flashable_4096.zip
    v1.1 = flimit_flashable_2048.zip

    Instruction:
    Just flash both Zip-Files via CWM or TWRP
    1. XZDR_Inid-Enabler
    2. flimit_flashable_2048 or flimit_flashable_4096
    3. Reboot (no wipes necessary)

    If the first Script isn't working, then you can edit "/sdcard1/XZDualRecovery/XZDR.prop" on your own.
    Just modify/add those lines:
    Code:
    dr.initd.active=true
    dr.keep.byeselinux=true
    If you did that you only need to flash "flimit_flashable_XXXX"

    Newest Flashable
    @mionica created a more experienced version of the workaround as flashable,
    which will revert all changes after boot is finished. Because we only need this workaround for boot.
    After that we should use android as Google/Sony intended ;)
    http://forum.xda-developers.com/showpost.php?p=60298690&postcount=123


    Undo Workaround:
    As requested here are two options for undo Workaround.
    Edit: Will now undo mionica Workaround, too.

    Undo Workaround, but keep init.d-Support of XZDR:
    flimit_undo_flashable.zip

    Undo Workaround completly:
    flimit_undo_full_flashable.zip

    -
    25
    Evrika!

    So here's how zygote's process tree looks with no Xposed installed:
    Code:
      PID FILES TASKS CONTEXT              [CMDLINE] EXECUTABLE
      663    18     6 u:r:zygote:s0        [zygote] /system/bin/app_process32_original
    [b] 1422   [color=blue]250[/color]   111 u:r:system_server:s0 [system_server] /system/bin/app_process32_original[/b]
     2100    25    13 u:r:platform_app:s0  [com.sonyericsson.capabilities] /system/bin/app_process32_original
     2117    82    35 u:r:platform_app:s0  [com.android.systemui] /system/bin/app_process32_original
     2141    45    21 u:r:untrusted_app:s0 [android.process.media] /system/bin/app_process32_original
     2305    83    31 u:r:untrusted_app:s0 [com.google.android.wearable.app] /system/bin/app_process32_original
     2318   353    27 u:r:untrusted_app:s0 [com.getpebble.android:framework] /system/bin/app_process32_original
     2340    24    13 u:r:platform_app:s0  [com.sonymobile.coverapp] /system/bin/app_process32_original
     2348    37    14 u:r:untrusted_app:s0 [com.anddoes.notifier] /system/bin/app_process32_original
     2367    25    16 u:r:untrusted_app:s0 [org.pocketworkstation.pckeyboard] /system/bin/app_process32_original
    ...
    Then, here's how the same process tree looks on the first boot after clearing /cache (using xposed-sdk21-arm-20150426.zip):
    Code:
      PID FILES TASKS CONTEXT              [CMDLINE] EXECUTABLE
      665    36     6 u:r:zygote:s0        [zygote] /system/bin/app_process32_xposed
      997     7     1 u:r:untrusted_app:s0 [logcat-vtime-sXposedStartupMarker:DXposed:Iappproc:IXposedInstaller:Iart:Flibc:FDEBUG:I] /system/bin/logcat
      998     9     3 u:r:system_server:s0 [xposed_service_system] /system/bin/app_process32_xposed
      999     9     4 u:r:untrusted_app:s0 [xposed_service_app] /system/bin/app_process32_xposed
     1005     8     1 u:r:untrusted_app:s0 [xposed_logcat] /system/bin/app_process32_xposed
    [b] 2217   [color=orange]358[/color]   112 u:r:system_server:s0 [system_server] /system/bin/app_process32_xposed[/b]
    17716    91    32 u:r:platform_app:s0  [com.android.systemui] /system/bin/app_process32_xposed
    17738    49    13 u:r:platform_app:s0  [com.sonyericsson.capabilities] /system/bin/app_process32_xposed
    17764    59    17 u:r:untrusted_app:s0 [android.process.media] /system/bin/app_process32_xposed
    17878    93    30 u:r:untrusted_app:s0 [com.google.android.wearable.app] /system/bin/app_process32_xposed
    ...
    And finally, here's the same process tree, on the second boot:
    Code:
      PID FILES TASKS CONTEXT              [CMDLINE] EXECUTABLE
      659    55     6 u:r:zygote:s0        [zygote] /system/bin/app_process32_xposed
     1002     7     1 u:r:untrusted_app:s0 [logcat-vtime-sXposedStartupMarker:DXposed:Iappproc:IXposedInstaller:Iart:Flibc:FDEBUG:I] /system/bin/logcat
     1003     9     3 u:r:system_server:s0 [xposed_service_system] /system/bin/app_process32_xposed
     1004     9     4 u:r:untrusted_app:s0 [xposed_service_app] /system/bin/app_process32_xposed
     1008     8     1 u:r:untrusted_app:s0 [xposed_logcat] /system/bin/app_process32_xposed
    [b] 1680   [color=red]951[/color]   111 u:r:system_server:s0 [system_server] /system/bin/app_process32_xposed[/b]
     2244   125    35 u:r:platform_app:s0  [com.android.systemui] /system/bin/app_process32_xposed
     2268    68    13 u:r:platform_app:s0  [com.sonyericsson.capabilities] /system/bin/app_process32_xposed
     2296    88    21 u:r:untrusted_app:s0 [android.process.media] /system/bin/app_process32_xposed
     2436   129    30 u:r:untrusted_app:s0 [com.google.android.wearable.app] /system/bin/app_process32_xposed
    ...
    Hence the question: what the hell is happening? So let's look at what files are opened by system_server in this later case:
    Code:
    busybox ls -l /proc/1680/fd/|busybox awk '{print $9 " " $11}'|busybox sort -n
    Code:
    0 /dev/null
    1 /dev/null
    2 /dev/null
    3 socket:[10961]
    4 [b][color=blue]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    5 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    6 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    7 /sys/kernel/debug/tracing/trace_marker
    8 /dev/__properties__
    9 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    10 /system/framework/framework-res.apk
    11 /system/framework/SemcGenericUxpRes/SemcGenericUxpRes.apk
    12 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    13 /system/vendor/overlay/android-res-305.apk
    14 /data/resource-cache/[email protected]@[email protected]
    15 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    16 /system/framework/XposedBridge.jar
    17 /data/app/com.mohammadag.shortcutinappinfo-2/base.apk
    18 /data/app/com.mohammadag.shortcutinappinfo-2/base.apk
    19 /system/framework/core-libart.jar
    20 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    21 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    22 /data/app/com.egingell.downloads2sd-1/base.apk
    23 /data/app/com.egingell.downloads2sd-1/base.apk
    24 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    25 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    26 /data/app/at.jclehner.appopsxposed-1/base.apk
    27 /data/app/at.jclehner.appopsxposed-1/base.apk
    28 /data/app/at.jclehner.appopsxposed-1/base.apk
    29 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    30 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    31 /data/app/ma.wanam.youtubeadaway-1/base.apk
    32 /data/app/ma.wanam.youtubeadaway-1/base.apk
    33 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    34 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    35 /data/app/com.oasisfeng.greenify-1/base.apk
    36 /data/app/com.oasisfeng.greenify-1/base.apk
    37 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    38 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    39 /data/app/com.germainz.dynamicalarmicon-1/base.apk
    40 /data/app/com.germainz.dynamicalarmicon-1/base.apk
    41 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    42 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    43 /data/app/com.pyler.nosafevolumewarning-1/base.apk
    44 /data/app/com.pyler.nosafevolumewarning-1/base.apk
    45 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    46 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    47 /data/app/com.p1ngu1n.playstorechangelog-1/base.apk
    48 /data/app/com.p1ngu1n.playstorechangelog-1/base.apk
    49 /system/framework/framework.jar
    50 socket:[12060]
    51 /dev/cpuctl/apps/tasks
    52 /dev/cpuctl/apps/bg_non_interactive/tasks
    53 /dev/alarm
    54 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    55 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    ... [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    60 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    61 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    62 /dev/binder
    63 pipe:[12650]
    64 pipe:[12650]
    65 anon_inode:[eventpoll]
    66 socket:[12651]
    67 socket:[12652]
    68 /sys/power/wake_lock
    69 /sys/power/wake_unlock
    70 pipe:[8997]
    71 pipe:[8997]
    72 anon_inode:inotify
    73 socket:[8998]
    74 pipe:[12184]
    75 socket:[9002]
    76 socket:[9007]
    77 socket:[9009]
    78 socket:[9011]
    79 socket:[9018]
    80 socket:[9023]
    81 socket:[9028]
    82 socket:[9033]
    83 socket:[9038]
    84 socket:[9043]
    85 socket:[9048]
    86 socket:[9053]
    87 socket:[9058]
    88 pipe:[12184]
    89 anon_inode:[eventpoll]
    90 socket:[12657]
    91 pipe:[9074]
    92 pipe:[9074]
    93 anon_inode:[eventpoll]
    94 pipe:[9077]
    95 pipe:[9077]
    96 anon_inode:[eventpoll]
    97 anon_inode:inotify
    98 pipe:[9081]
    99 pipe:[9081]
    100 anon_inode:[eventpoll]
    101 pipe:[12188]
    102 pipe:[12188]
    103 anon_inode:[eventpoll]
    104 pipe:[12191]
    105 pipe:[12191]
    106 anon_inode:[eventpoll]
    107 pipe:[12194]
    108 pipe:[12194]
    109 anon_inode:[eventpoll]
    110 /proc/sysrq-trigger
    111 pipe:[12197]
    112 pipe:[12197]
    113 anon_inode:[eventpoll]
    114 /sys/power/wake_lock
    115 /sys/power/wake_unlock
    116 /sys/power/state
    117 /sys/power/wakeup_count
    118 pipe:[11235]
    119 socket:[11231]
    120 pipe:[11235]
    121 anon_inode:[eventpoll]
    122 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    123 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    ... [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    424 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    425 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    426 /system/priv-app/SettingsProvider/SettingsProvider.apk
    427 /data/data/com.android.providers.settings/databases/settings.db
    428 /system/vendor/overlay/com.android.providers.settings-res-305.apk
    429 /system/app/Theme000/Theme000.apk
    430 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    431 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    432 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    433 /system/app/IntelligentRotation/IntelligentRotation.apk
    434 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    435 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    ... [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    439 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    440 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    441 /system/app/SuperStamina/SuperStamina.apk
    442 /system/framework/com.sonyericsson.uxpres.jar
    443 /system/vendor/overlay/SuperStamina-Overlay-275.apk
    444 /system/framework/com.google.protobuf-2.3.0.jar
    445 /system/framework/com.sonyericsson.idd.jar
    446 /data/data/com.sonymobile.superstamina/databases/AppStats.db
    447 /data/data/com.sonymobile.superstamina/databases/AppStats.db
    448 /data/data/com.sonymobile.superstamina/databases/AppStats.db
    449 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    450 /data/data/com.sonymobile.superstamina/databases/AppStats.db
    451 /data/data/com.sonymobile.superstamina/databases/AppStats.db
    452 /dev/alarm
    453 anon_inode:[eventpoll]
    454 anon_inode:inotify
    455 pipe:[13709]
    456 pipe:[13709]
    457 pipe:[13710]
    458 pipe:[13710]
    459 anon_inode:[eventpoll]
    460 socket:[15583]
    461 socket:[13712]
    462 socket:[15584]
    463 /dev/ashmem
    464 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    465 socket:[14723]
    466 socket:[12883]
    467 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    468 [b][color=red]/data/dalvik-cache/arm/sys[email protected]@boot.oat[/color][/b]
    469 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    470 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    471 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    472 /dev/input/event8
    473 /dev/input/event7
    474 pipe:[18422]
    475 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    476 /dev/input/event5
    477 pipe:[18422]
    478 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    479 /dev/input/event2
    480 /dev/input/event1
    481 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    482 /dev/input/event0
    483 anon_inode:[eventpoll]
    484 socket:[20968]
    485 /dev/input/event3
    486 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    487 pipe:[14729]
    488 pipe:[14729]
    489 anon_inode:[eventpoll]
    490 socket:[14732]
    491 socket:[13720]
    492 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    493 pipe:[13726]
    494 pipe:[13726]
    495 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    496 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    497 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    498 anon_inode:[eventpoll]
    499 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    500 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    501 pipe:[13729]
    502 pipe:[13729]
    503 anon_inode:[eventpoll]
    504 pipe:[13732]
    505 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    506 pipe:[13732]
    507 anon_inode:[eventpoll]
    508 pipe:[13735]
    509 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    510 pipe:[13735]
    511 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    512 anon_inode:[eventpoll]
    513 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    514 pipe:[13741]
    515 pipe:[13741]
    516 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    517 anon_inode:[eventpoll]
    518 pipe:[13744]
    519 pipe:[13744]
    520 anon_inode:[eventpoll]
    521 pipe:[13747]
    522 pipe:[13747]
    523 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    524 anon_inode:[eventpoll]
    525 socket:[15602]
    526 pipe:[15608]
    527 pipe:[15608]
    528 anon_inode:[eventpoll]
    529 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    530 pipe:[12896]
    531 pipe:[12896]
    532 anon_inode:[eventpoll]
    533 pipe:[14748]
    534 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    535 pipe:[14748]
    536 anon_inode:[eventpoll]
    537 /data/system/locksettings.db
    538 /dev/kgsl-3d0
    539 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    540 anon_inode:dmabuf
    541 anon_inode:dmabuf
    542 /dev/ion
    543 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    544 /dev/ion
    545 socket:[20059]
    546 /dev/ashmem
    547 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    548 socket:[20925]
    549 socket:[20153]
    550 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    551 /data/system/locksettings.db-wal
    552 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    553 /data/system/locksettings.db-shm
    554 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    555 /data/system/locksettings.db
    556 /data/system/locksettings.db-wal
    557 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    558 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    559 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    560 pipe:[12909]
    561 pipe:[12909]
    562 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    563 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    564 anon_inode:[eventpoll]
    565 pipe:[12912]
    566 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    567 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    568 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    569 pipe:[12912]
    570 anon_inode:[eventpoll]
    571 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    572 pipe:[12915]
    573 pipe:[12915]
    574 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    575 socket:[15564]
    576 anon_inode:[eventpoll]
    577 pipe:[12918]
    578 pipe:[12918]
    579 anon_inode:[eventpoll]
    580 pipe:[12921]
    581 pipe:[12921]
    582 anon_inode:[eventpoll]
    583 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    584 socket:[14752]
    585 socket:[15614]
    586 socket:[14753]
    587 socket:[20489]
    588 anon_inode:inotify
    589 socket:[15617]
    590 socket:[15630]
    592 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    593 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    ... [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    658 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    659 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    660 socket:[12926]
    661 socket:[21895]
    662 socket:[20490]
    663 pipe:[17065]
    664 pipe:[17065]
    665 anon_inode:[eventpoll]
    666 socket:[17081]
    668 socket:[20499]
    669 /data/misc/location/gpsone_d/gpsone_loc_api_q
    670 pipe:[17084]
    671 pipe:[17084]
    672 /data/misc/location/gpsone_d/gpsone_loc_api_resp_q
    673 /data/misc/location/gpsone_d/quipc_ctrl_q
    674 /data/misc/location/gpsone_d/msapm_ctrl_q
    675 /data/misc/location/gpsone_d/msapu_ctrl_q
    676 socket:[18648]
    677 /dev/ashmem
    678 pipe:[18697]
    679 pipe:[18697]
    680 anon_inode:[eventpoll]
    681 pipe:[17179]
    682 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    683 pipe:[17179]
    684 anon_inode:[eventpoll]
    685 socket:[21209]
    686 pipe:[38415]
    687 pipe:[38415]
    688 anon_inode:[eventpoll]
    689 socket:[49484]
    690 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    691 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    ... [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    695 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    696 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    697 /system/app/SemcSimDetection/SemcSimDetection.apk
    698 pipe:[53978]
    699 /system/app/YouTube/YouTube.apk
    700 pipe:[53978]
    701 anon_inode:[eventpoll]
    702 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    703 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    ... [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    709 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    710 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    711 socket:[15770]
    712 socket:[15771]
    713 /system/app/SemcPowerSaveModule/SemcPowerSaveModule.apk
    714 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    715 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    716 /system/framework/com.sonyericsson.sysmon.jar
    717 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    718 pipe:[57347]
    719 pipe:[57347]
    720 anon_inode:[eventpoll]
    721 /dev/ashmem
    722 /dev/ashmem
    723 /dev/ashmem
    724 /dev/ashmem
    725 socket:[58435]
    726 /dev/ashmem
    727 /dev/ashmem
    728 socket:[57348]
    729 pipe:[56209]
    730 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    731 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    732 /dev/ashmem
    733 pipe:[16648]
    734 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    735 pipe:[16648]
    736 anon_inode:[eventpoll]
    737 socket:[16622]
    738 /dev/diag
    739 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    740 socket:[69518]
    741 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    742 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    743 socket:[20770]
    744 socket:[19818]
    745 [b][color=red]/data/dalvik-cache/arm/[email protected][email protected][/color][/b]
    746 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    747 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    748 socket:[18055]
    749 socket:[16643]
    750 socket:[16644]
    751 pipe:[16645]
    752 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    753 pipe:[16645]
    754 socket:[19819]
    755 pipe:[56209]
    756 anon_inode:[eventpoll]
    757 pipe:[59486]
    758 pipe:[59486]
    759 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    760 anon_inode:[eventpoll]
    761 socket:[16708]
    762 socket:[16709]
    763 pipe:[16710]
    764 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    765 pipe:[16710]
    766 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    767 pipe:[57673]
    768 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    769 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    770 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    771 pipe:[57673]
    772 anon_inode:[eventpoll]
    773 socket:[56213]
    774 socket:[82486]
    775 socket:[18219]
    776 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    777 socket:[18220]
    778 socket:[16921]
    780 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    781 /data/system/users/0/accounts.db
    782 /dev/ashmem
    784 socket:[63788]
    785 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    786 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    787 /dev/ashmem
    788 /dev/ashmem
    789 socket:[84341]
    790 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    791 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    ... [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    795 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    797 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    798 /system/priv-app/com.qualcomm.location/com.qualcomm.location.apk
    799 /system/framework/com.android.location.provider.jar
    800 socket:[81214]
    801 socket:[76255]
    804 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    805 socket:[73558]
    806 socket:[81286]
    807 socket:[77738]
    808 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    809 /data/app/org.pocketworkstation.pckeyboard-1/base.apk
    810 socket:[79440]
    812 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    814 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    ... [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    1041 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    1058 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    1079 socket:[15521]
    1095 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    1096 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    ... [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    1135 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    1136 [b][color=red]/data/dalvik-cache/arm/[email protected]@boot.oat[/color][/b]
    1137 pipe:[15520]
    1138 pipe:[15520]
    1139 anon_inode:[eventpoll]
    That is, the exact same file is opened by a single process for 688 ****ing times.

    At this stage, I'm pretty darn sure we know exactly
    • what gets leaked (file handles to /data/dalvik-cache/arm/[email protected]@boot.oat),
    • when that happens (all the time, though the rate is extremely low during the first boot, when the system recompiles everything) and
    • why we're seeing crashes (those leaks accumulate to the point where the kernel runs out of file handles; the more apps you have, the sooner that happens).
    I rest my case, and have reported this here.

    Failure analysis
    • The fact that only handles to one specific file are leaked seems to suggest that the point of failure is unique
    • Comparing the number of file handles between a non-Xposed boot and the first Xposed boot, it's appears likely that the point of failure is on a path that's also exercised during the first boot, but which results in a lot of fopen() errors; more specifically, I expect that that .oat file is kept open with a write lock by the process that recompiles the applications for ART, thus prevending the Xposed system server from opening it, thus giving it nothing to leak
    • Furthermore, the fact that the first boot appears stable, is probably just an appearence; meaning, given enough time, a first-booted system will still be killed by the leak;
    • The reason why the first boot is so much more stable is probably a consequence of the rate at which handles are leaked after boot completes, i.e. if the rate is much slower than during boot, it can be reasonably expected that the first boot will appear stable for a long time
    • The above is also supprted by the fact that, if the leaking rate were constant, everybody would see reboots within 25mins of resetting the device
    • This is further supported (intuitively) by the fact that, at boot (on boot #2 and subsequents), 687 handles have already been leaked, which happens to be almost 20% of the total number of files the kernel could keep open on our Sony's;
    • The rate at which handles are leaked seems to strongly correlate with the number of processes/apps on a system; the experienced lifetime of systems with few applications (such as mine or the OP's) is high, appearing to be stable (though I've seen my first random reboot yesterday :D), whereas people who use cartloads of applications could see reboots within hours or less;
    • The above seems to indicate that the affected Xposed code path has to do with resuming or loading apps.
    Oh btw - if you like those process lists, I've attached the thing that makes them possible ;)