Red Hat Bugzilla – Bug 1283352
[abrt] java-1.8.0-openjdk-devel: signalHandler(): java killed by SIGABRT
Last modified: 2015-11-24 10:03:07 EST
Version-Release number of selected component:
cmdline: /usr/lib/jvm/java-1.8.0-openjdk-22.214.171.124-3.b17.fc23.x86_64/bin/java -Xbootclasspath/a:/home/drindt/.bin/android-studio/bin/../lib/boot.jar -classpath /home/drindt/.bin/android-studio/bin/../lib/bootstrap.jar:/home/drindt/.bin/android-studio/bin/../lib/extensions.jar:/home/drindt/.bin/android-studio/bin/../lib/util.jar:/home/drindt/.bin/android-studio/bin/../lib/jdom.jar:/home/drindt/.bin/android-studio/bin/../lib/log4j.jar:/home/drindt/.bin/android-studio/bin/../lib/trove4j.jar:/home/drindt/.bin/android-studio/bin/../lib/jna.jar:/usr/lib/jvm/java-1.8.0-openjdk-126.96.36.199-3.b17.fc23.x86_64/lib/tools.jar -Xms256m -Xmx1280m -XX:MaxPermSize=350m -XX:ReservedCodeCacheSize=225m -XX:+UseConcMarkSweepGC -XX:SoftRefLRUPolicyMSPerMB=50 -da -Djna.nosys=true -Djna.boot.library.path= -Djna.debug_load=true -Djna.debug_load.jna=true -Dsun.io.useCanonCaches=false -Djava.net.preferIPv4Stack=true -Dawt.useSystemAAFontSettings=lcd -Dhidpi=true -Djb.vmOptionsFile=/home/drindt/.bin/android-studio/bin/studio64.vmoptions,/home/drindt/.AndroidStudio1.4/studio64.vmoptions -XX:ErrorFile=/home/drindt/java_error_in_STUDIO_%p.log -Djb.restart.code=88 -Didea.paths.selector=AndroidStudio1.4 -Didea.platform.prefix=AndroidStudio com.intellij.idea.Main
runlevel: N 5
Thread no. 0 (10 frames)
#5 signalHandler at /usr/src/debug/java-1.8.0-openjdk-188.8.131.52-3.b17.fc23.x86_64/openjdk/hotspot/src/os/linux/vm/os_linux.cpp:4222
#7 FreeChunk::next at /usr/src/debug/java-1.8.0-openjdk-184.108.40.206-3.b17.fc23.x86_64/openjdk/hotspot/src/share/vm/gc_implementation/concurrentMarkSweep/freeChunk.hpp:111
#8 FreeList<FreeChunk>::getFirstNChunksFromList at /usr/src/debug/java-1.8.0-openjdk-220.127.116.11-3.b17.fc23.x86_64/openjdk/hotspot/src/share/vm/memory/freeList.cpp:122
#9 CompactibleFreeListSpace::par_get_chunk_of_blocks_IFL at /usr/src/debug/java-1.8.0-openjdk-18.104.22.168-3.b17.fc23.x86_64/openjdk/hotspot/src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp:2765
#10 CompactibleFreeListSpace::par_get_chunk_of_blocks at /usr/src/debug/java-1.8.0-openjdk-22.214.171.124-3.b17.fc23.x86_64/openjdk/hotspot/src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp:2978
#11 CFLS_LAB::get_from_global_pool at /usr/src/debug/java-1.8.0-openjdk-126.96.36.199-3.b17.fc23.x86_64/openjdk/hotspot/src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp:2665
#12 CFLS_LAB::alloc at /usr/src/debug/java-1.8.0-openjdk-188.8.131.52-3.b17.fc23.x86_64/openjdk/hotspot/src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp:2623
#13 ConcurrentMarkSweepGeneration::par_promote at /usr/src/debug/java-1.8.0-openjdk-184.108.40.206-3.b17.fc23.x86_64/openjdk/hotspot/src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp:1388
#14 ParNewGeneration::copy_to_survivor_space_avoiding_promotion_undo at /usr/src/debug/java-1.8.0-openjdk-220.127.116.11-3.b17.fc23.x86_64/openjdk/hotspot/src/share/vm/gc_implementation/parNew/parNewGeneration.cpp:1202
#15 InstanceKlass::oop_oop_iterate_nv at /usr/src/debug/java-1.8.0-openjdk-18.104.22.168-3.b17.fc23.x86_64/openjdk/hotspot/src/share/vm/gc_implementation/parNew/parNewGeneration.hpp:393
Created attachment 1096208 [details]
Created attachment 1096209 [details]
Created attachment 1096210 [details]
Created attachment 1096211 [details]
Created attachment 1096212 [details]
Created attachment 1096213 [details]
Created attachment 1096214 [details]
Created attachment 1096215 [details]
Created attachment 1096216 [details]
Created attachment 1096217 [details]
Created attachment 1096218 [details]
Hi, is this issue always reproducible? If so, how can we reproduce it?
IntelliJ runs and i haven't used it at this time. It silently crashed.
Unfortunately we cannot investigate this further based on the info. Since it cannot be reproduced, I am going to close it, If it happens again, please re-open this and attach the hs_err file if possible.
Created attachment 1096840 [details]
Maybe this is the requested information, please have a check.
Ah, it is indeed.
Christine, based on the back trace and hs_err, can this be investigated further? Looks like it may be in GC code.
What's happening is that parNew is trying to promote an object to the
old generation (CMS) but there isn't anything available on the appropriate
sized free list. So it goes off to find some elements to add to the free list.
Unfortunately we were asked to find 966, but we only get as far as 964 before we hit a corrupted entry.
The code is just walking down a list looking for chunks or NULL and instead
it ends up with some weird corrupted address. This address (0xda561fd8d01fe320)
looks implausible and therefore smells like corrupted memory to me.
I can't even say for sure that the sig11 is a hardware problem, but I would be
very curious to see if they you can duplicate the bug on a different machine?
If it is a software problem, I don't have any way to figure out how the list got corrupted. Without a reproducible test case I don't know where to start looking.
Christine, thanks for your efforts. So you think the memory in the machine is broken? From my point i can just say i am working with this box everyday for lot of hours and so far no crashes or other problems are raised where i would think the memory seems broken. Also there are no other crashes happen. My question is now, should i do a memory test? If not what i can do else? Found in the log:
"Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again"
So what i can i do to provide more information on that? If it's required.
Let me know what i can do.
My best guess is that someone is stomping on memory. This happens at some point before the error is signalled. I really have no way of figuring out who did it unless we could repeat it and add a watchpoint on the bad memory location.
I don't see what we could do if we reopened this.
Thank you for your work and engagement to my problem.