I see the git log and find the change If53c236058a7237d735c2344a715cf0a36301f9b, it added a final value mIsBootImageOnDisk in the constructor function DeviceStorageMonitorService. But, it seems useless! Who can tell me?
I see the modification is for Bug: 17679443. Who can tell me where to see the bug information ?
enter image description here
There seems to be no entry for 17679443 in the Android Open Source Project - Issue Tracker. I'm going to guess that this is an internal bug number. The error comes from what the documentation describes as retrieving the boot class path from disk storage rather than the dirty pages in memory (the method itself calls isBootClassPathOnDisk which has a native implementation in the art runtime dalvik_system_VMRuntime.cc). I'm experiencing this error now as it processed the arm instruction set (the only instruction set processed by the system). I'm wondering if I'm experiencing a permission issue of some sort that does not allow the image header to be read properly.
The error message that results from not having enough storage space is completing misleading as I'm looking at a df listing where my system partition has 730 MB free and the data partition has 4.8 GB free (actually all the mounted partitions > 250 MB).
Hopefully, someone else will have a solution to this issue. I would hate to have to resort to stubbing out the method with a return true just to get rid of the notification -- there is probably an issue elsewhere in my firmware that needs to be fixed.
So my answer to this question, which I don't need clarification from the OP on to answer, is that there is nothing you can do right now. There are no obvious user forums either here on StackOverflow, in the AOSP issue tracker, or on another user forum like NXP/Freescale (for example) where a better answer or even background to this bug is provided.
Related
Suddenly my app started to crash enormously. I checked Crashlytics report but it doesn't tell me much. This is what it says, hopefully someone could give me a hint if had same/similar problem..
This seems to be related to a known jmDNS bug that was supposedly fixed a long time ago1:
https://sourceforge.net/p/jmdns/bugs/101/
https://sourceforge.net/p/jmdns/mailman/jmdns-discuss/thread/4EA5B242.4070003#gmail.com/
Apparently, the problem is triggered by lookup of malformed DNS names: see last email in discussion thread.
I suggest that you add some diagnostics to your app to find out what name your code is attempting to lookup.
1 - I have my doubts that it was actually fixed ... based on the discussion thread.
See here for original question.
I'm writing a Java service, using Jetty for Webserving and SQLite for database storage. Source is available here.
I found that, although the service ran stably from my laptop, when deployed to an EC2 instance it would crash with no obvious error message in output somewhere between 1 hour and 2 days from starting up. I added some logging options to the startup call (-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=...), and got this crashlog.
This is the first time I've encountered such a file, and at first glance it doesn't seem very obvious which part of it refers to the actual error and which parts are just giving contextual information, so I'd really appreciate any good guides to understanding it. In particular, it looks like it's trying to interact with ZipFiles, which I don't use in my project.
This answer links to a blog which was -1'd in the answer comments
This answer links to some Oracle documentation, which I would normally be overjoyed at, but it appears to be a general debugging guide - can't see anything in there about hs_err files (though that may become clear on further reading)
This result from Google claims that "whatever Java code you execute, JVM should never crash. If it does, it is just a JVM bug. So try to log a defect with Sun with all details and hopefully they will look into that.", which sounds pretty absolutist - I think it's highly unlikely that my little toy project has uncovered a JVM bug!
Crashes in Java_java_util_zip_ZipFile_getEntry are most often caused by concurrent access to .zip files, e.g. a file is overwritten while an open instance exists.
See JDK-8042197, JDK-8031691 for details.
BTW, as to original question, here is a presentation on JVM crash dump analysis.
Looking at the crashlog, it appears that something you were unpacking (jar file or zip file) resulted in a JVM crash.
If this occurs during startup, try adding this to your JVM command line to see which file it was possibly working on.
java -verbose:class [more command line]
When starting up an open-source Java service (Waarp, but I have the feeling this might not be connected to my problem, since it is used by other people as well), the logs show
The data area passed to a system call is too small.
I upgraded from Java 1.8.0.71 to 1.8.0.73: no difference.
In the log I find
-Djava.class.path=C:\Waarp\lib\WaarpR66-3.0.6.jar;C:\Waarp\lib\commons-codec-1.10.jar;C:\Waarp\lib\commons-compress-1.10.jar;C:\Waarp\lib\commons-daemon-1.0.15.jar;C:\Waarp\lib\commons-dbcp-1.4.jar;C:\Waarp\lib\commons-exec-1.3.jar;C:\Waarp\lib\commons-io-2.4.jar;C:\Waarp\lib\commons-lang3-3.1.jar;C:\Waarp\lib\commons-logging-1.2.jar;C:\Waarp\lib\commons-net-3.4-ftp.jar;C:\Waarp\lib\commons-pool-1.5.4.jar;C:\Waarp\lib\dom4j-1.6.1.jar;C:\Waarp\lib\ftp4j-1.7.2.jar;C:\Waarp\lib\hamcrest-core-1.3.jar;C:\Waarp\lib\httpclient-4.4.1.jar;C:\Waarp\lib\httpcore-4.4.1.jar;C:\Waarp\lib\jackson-annotations-2.7.0.jar;C:\Waarp\lib\jackson-core-2.7.0.jar;C:\Waarp\lib\jackson-databind-2.7.0.jar;C:\Waarp\lib\jackson-dataformat-smile-2.6.2.jar;C:\Waarp\lib\jackson-jaxrs-base-2.6.2.jar;C:\Waarp\lib\jackson-jaxrs-smile-provider-2.6.2.jar;C:\Waarp\lib\jackson-module-jaxb-annotations-2.6.2.jar;C:\Waarp\lib\javassist-3.20.0-GA.jar;C:\Waarp\lib\javasysmon-0.3.6.jar;C:\Waarp\lib\jaxen-1.1.6.jar;C:\Waarp\lib\joda-time-2.9
Upgrading from one version of Waarp to another (nope, didn't work before, just trying anything I could think of), I find that the length of the java.class.path always seems to be around 992 characters.
I made sure java_home doesn't contain any spaces.
I recently came across a bug with an unresolved issue in SDK 2.2 and, as its fixed in 2.5, decided to explore a switch.
Now I am new to GWT and I have no idea of the effects of doing such a switch, but figured it couldn't hurt to mess around locally. I went ahead and successfully updated to 2.5 locally to test and can run with no errors. However many of the text boxes have changed appearance and my navigation bar disappeared, etc...
Is this type of behavior normal after an update? If so I cant imagine why anyone would be in a hurry to do so, as spending enormous amounts of time to modify all pages is pretty unrealistic. Is there maybe some type of quick fix or an error i may have made to cause this?
If you want to put a lot of resources into a GWT project it is always a good idea to check regularly how the project is going on. On the release-note page you can check what's new and what has been deprecated. This way you can make an informed and rational decision whenever you want to update. This is very important since going from an old version (say 1.0) to a new one (i.e 2.5.1) might give some headaches to the programmers. Spendind half-an-hour checking what's going on every month will make your life easier.
GWT has an issue tracker where you can see the open issues and what has been resolved. Many issues have never been fixed, but I read the GWT team intend to solve the 100 most important issues for the next release. GWT is now open-source and you can contribute to its development whenever you know of to fix one of those issues.
Last but not least: many people say a lot of things, which are not always correct (including on Stack Overflow). Always dubble check before making important decisions.
Giving this advice is all I can do for you so far...
Yet, if you give me some info about that bug you expected to be fixed and the exact name of that "navigation bar" widget you might find out information on the sites above to check their status. But I can't search that for you if I don't know what the bug was and the name of the widget that is broken. Also, when you say "many of the textboxes" I understand it's not every textbox that's broken but some variant your are using in some particular places. More information would also be needed...
I have a simple test case producing a sure ArrayOutOfBoundException in jzlib
1.0.7 depending on the data subsequently written to one and the same instance
of ZOutputStream.
Stacktrace:
java.lang.ArrayIndexOutOfBoundsException: 587
at com.jcraft.jzlib.Tree.d_code(Tree.java:149)
at com.jcraft.jzlib.Deflate.compress_block(Deflate.java:691)
at com.jcraft.jzlib.Deflate._tr_flush_block(Deflate.java:897)
at com.jcraft.jzlib.Deflate.flush_block_only(Deflate.java:772)
at com.jcraft.jzlib.Deflate.deflate_slow(Deflate.java:1195)
at com.jcraft.jzlib.Deflate.deflate(Deflate.java:1567)
at com.jcraft.jzlib.ZStream.deflate(ZStream.java:133)
at com.jcraft.jzlib.ZOutputStream.write(ZOutputStream.java:102)
at com.jcraft.jzlib.JZLibTestCase.main(JZLibTestCase.java:51)
at JZLibTestCase.main(JZLibTestCase.java:28)
The problem occurs very rarely and depends on the data subsequentially
written to an open ZOutputStream from jzlib.
Do you have a hint how to fix this? Have you ever heard of this?
Near as I can tell you might've found a bug with JZlib. While searching around I came across other places that have your post with attached source and data files. It does not appear that you're doing anything wrong. You should be able to stream any sequence of bytes to ZOutputStream.
Is there a particular reason you're using JZlib? The two main reasons I understand to use it are support for Z_PARTIAL_FLUSH mode and licensing. If you don't need that flush mode and you're using the Oracle JVM, you should be just fine with the included DeflaterOutputStream. Substituting it in your code for ZOuputStream works without an exception.
I haven't found a concrete reason for using jzlib asking my co-workers, but for sure there has been a bug using java.util.zip somewhen in JRE 1.4 on multi-processor systems, although no one has been able to tell me concretely which one. From that time on we have been using jzlib, which has worked good for many years. Most probably it is already fixed. Nevertheless, using java.util.zip works with my simple test data in the same manner jzlib failed with, that's true.