Community
Participate
Working Groups
Has anyone ever run a memory profiler like valgrind on any of the java plugins (or even the core, for that matter). In trying to trace a problem with an obscure UI error, I attached a debugger to the spawned JRE to set a breakpoint, and over 100 SEGVs were thrown before the UI even showed up. I know the general principle behind try/catch is to hide problems rather than dealing with them, but that volume of access violations is beyond ridiculous, and just begging for code injection attacks.
Please provide some more information. What part of eclipse code is throwing a SEGV and not just dying? Or is the the JVM that's throwing SEGVs? That would be a NOT_ECLIPSE problem. PW
It's my understanding it's near impossible to tell if it is coming from the JVM or the interpreted code, but here is a sampling: java.lang.ArrayIndexOutOfBoundsException: 1226300250 at java.util.HashMap.put(HashMap.java:494) at org.eclipse.osgi.storage.Storage.loadGenerations(Storage.java:1179) at org.eclipse.osgi.storage.Storage.<init>(Storage.java:129) at org.eclipse.osgi.storage.Storage.createStorage(Storage.java:84) at org.eclipse.osgi.internal.framework.EquinoxContainer.<init>(EquinoxContainer.java:75) at org.eclipse.osgi.launch.Equinox.<init>(Equinox.java:31) at org.eclipse.core.runtime.adaptor.EclipseStarter.startup(EclipseStarter.java:295) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:231) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:648) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:603) at org.eclipse.equinox.launcher.Main.run(Main.java:1465) at org.eclipse.equinox.launcher.Main.main(Main.java:1438) ==27360== ==27360== HEAP SUMMARY: ==27360== in use at exit: 15,255,450 bytes in 9,657 blocks ==27360== total heap usage: 34,342 allocs, 24,685 frees, 69,047,451 bytes allocated ==27360== ==27360== LEAK SUMMARY: ==27360== definitely lost: 5,867 bytes in 36 blocks ==27360== indirectly lost: 4,864 bytes in 13 blocks ==27360== possibly lost: 298,196 bytes in 844 blocks ==27360== still reachable: 14,946,523 bytes in 8,764 blocks ==27360== suppressed: 0 bytes in 0 blocks ==27360== Rerun with --leak-check=full to see details of leaked memory ==27360== ==27360== For counts of detected and suppressed errors, rerun with: -v ==27360== Use --track-origins=yes to see where uninitialised values come from ==27360== ERROR SUMMARY: 12199838 errors from 929 contexts (suppressed: 10 from 7) Yes, that's correct: 12 MILLION errors, and the splash screen hadn't even displayed yet. That's with java version "1.7.0_71" Java(TM) SE Runtime Environment (build 1.7.0_71-b14) Java HotSpot(TM) 64-Bit Server VM (build 24.71-b01, mixed mode) ========================================= With a different JRE: An exception occurred while writing to the platform log: java.lang.NullPointerException at java.lang.Character.toUpperCase(Character.java:6208) at java.lang.Character.toUpperCase(Character.java:6179) at java.util.Date.convertToAbbr(Date.java:1056) at java.util.Date.toString(Date.java:1033) at org.eclipse.equinox.launcher.Main.log(Main.java:2423) at org.eclipse.equinox.launcher.Main.run(Main.java:1476) at org.eclipse.equinox.launcher.Main.main(Main.java:1438) Logging to the console instead. ==27394== Invalid write of size 4 ==27394== at 0x7BE94B5: ??? ==27394== by 0x7C57E03: ??? ==27394== Address 0x4134200 is not stack'd, malloc'd or (recently) free'd ==27394== An exception occurred while logging to the console: java.lang.NullPointerException at java.lang.Character.digit(Character.java:6373) at java.lang.Character.digit(Character.java:6321) at java.lang.Integer.parseInt(Integer.java:490) at java.lang.Integer.parseInt(Integer.java:527) at java.util.Calendar.setWeekCountData(Calendar.java:2592) at java.util.Calendar.<init>(Calendar.java:956) at java.util.GregorianCalendar.<init>(GregorianCalendar.java:619) at java.util.Calendar.createCalendar(Calendar.java:1030) at java.util.Calendar.getInstance(Calendar.java:968) at org.eclipse.equinox.launcher.Main.getDate(Main.java:2486) at org.eclipse.equinox.launcher.Main.write(Main.java:2476) at org.eclipse.equinox.launcher.Main.log(Main.java:2446) at org.eclipse.equinox.launcher.Main.run(Main.java:1476) at org.eclipse.equinox.launcher.Main.main(Main.java:1438) An exception occurred while writing to the platform log: java.lang.NullPointerException at java.lang.Character.toUpperCase(Character.java:6208) at java.lang.Character.toUpperCase(Character.java:6179) at java.util.Date.convertToAbbr(Date.java:1056) at java.util.Date.toString(Date.java:1033) at org.eclipse.equinox.launcher.Main.log(Main.java:2423) at org.eclipse.equinox.launcher.Main.run(Main.java:1477) at org.eclipse.equinox.launcher.Main.main(Main.java:1438) Logging to the console instead. !STACK java.lang.NoClassDefFoundError: org/eclipse/osgi/framework/log/FrameworkLogEntry at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:241) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:648) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:603) at org.eclipse.equinox.launcher.Main.run(Main.java:1465) at org.eclipse.equinox.launcher.Main.main(Main.java:1438) Caused by: java.lang.ClassNotFoundException: org.eclipse.osgi.framework.log.FrameworkLogEntry at java.net.URLClassLoader$1.run(URLClassLoader.java:366) at java.net.URLClassLoader$1.run(URLClassLoader.java:355) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:354) at java.lang.ClassLoader.loadClass(ClassLoader.java:425) at java.lang.ClassLoader.loadClass(ClassLoader.java:358) ... 9 more ==27394== ==27394== HEAP SUMMARY: ==27394== in use at exit: 13,948,058 bytes in 9,410 blocks ==27394== total heap usage: 63,298 allocs, 53,888 frees, 88,718,737 bytes allocated ==27394== ==27394== LEAK SUMMARY: ==27394== definitely lost: 6,061 bytes in 41 blocks ==27394== indirectly lost: 4,864 bytes in 13 blocks ==27394== possibly lost: 327,721 bytes in 927 blocks ==27394== still reachable: 13,609,412 bytes in 8,429 blocks ==27394== suppressed: 0 bytes in 0 blocks ==27394== Rerun with --leak-check=full to see details of leaked memory ==27394== ==27394== For counts of detected and suppressed errors, rerun with: -v ==27394== Use --track-origins=yes to see where uninitialised values come from ==27394== ERROR SUMMARY: 13111704 errors from 1039 contexts (suppressed: 12 from 6) .....we get 13 MILLION. java version "1.7.0_65" OpenJDK Runtime Environment (IcedTea 2.5.1) (7u65-2.5.1-5~deb7u1) OpenJDK 64-Bit Server VM (build 24.65-b04, mixed mode)
I'm a bit confused by this report. Are you saying these exceptions are caught and not logged and do not cause the application to fail to load?
They do not prevent the application from loading, no.
We were not able to reproduce it or explain what happened. If you can still see the problem, please provide reproducible steps to allow us to further investigate the issue.
