JDK 13 EA: 100% CPU use with no Java threads runnable

[Stefan Reich]

I will also try the gdb method... that one sounds like a very smart idea.

On Sat, 14 Sep 2019 at 23:49, Stefan Reich <
stefan.reich.maker.of.eye at googlemail.com> wrote:

> Hi,
>
> thanks for your answer. Unfortunately, I still don't know what triggers
> the "bad" state, so no test case... It happens randomly, but as I said,
> once it does, it doesn't go away anymore. (Still happening right now.)
>
> Would the result from Thread.getAllStackTraces() help? I attached that to
> this email.
>
> Many greetings,
> Stefan
>
>
> On Sat, 14 Sep 2019 at 23:43, Ioi Lam <ioi.lam at oracle.com> wrote:
>
>> Hi Stefan,
>>
>> Is it possible for you to create a test case that reproduce this problem?
>>
>> If not, try running the program inside a Linux terminal, and when the
>> CPU goes at 100%, type "Ctrl-\" (Control + Backslash). It lists the
>> states of all the threads that the JVM knows about. It might give you
>> some idea what's happening.
>>
>> An alternative is to run your program inside gdb,
>>
>> $ gdb jdk13/bin/java
>> (gdb) handle SIGSEGV noprint
>> (gdb) handle SIGSEGV nostop
>> (gdb) set print thread-events off
>> (gdb) set height 0
>> (gdb) run -cp myapp.jar App
>>
>> (When the program enters the 100% CPU state, type Ctrl-C)
>>
>> ^C
>> Thread 1 "java" received signal SIGINT, Interrupt.
>> 0x00007ffff779798d in pthread_join (threadid=140737353910016,
>> thread_return=0x7fffffff8508) at pthread_join.c:90
>> 90    pthread_join.c: No such file or directory.
>> (gdb) thread apply all where
>>
>> This will list all stacks of all the threads, including ones that the
>> JVM may not be aware of. This should tell you who is spinning the CPU.
>>
>> Thanks
>> - Ioi
>>
>>
>>
>>
>> On 9/14/19 1:57 PM, Stefan Reich wrote:
>> > Hi,
>> >
>> > I was advised by Oracle's Fairoz Matte to contact this list.
>> >
>> > I am seeing a Java process use 100% of one CPU core continuously, but no
>> > Java threads are runnable (as evidenced by internal thread sampling as
>> well
>> > as VisualVM).
>> >
>> > Whenever it occurs, the problem does not seem to go away until the Java
>> VM
>> > exits.
>> >
>> > I think I am using a single native library (OSHI), the rest is pure
>> Java.
>> >
>> > Older versions of the JDK have exhibited the same problem, but most
>> > interestingly, the bug is happening right now on a Linux machine
>> > (Peppermint 7 I think) with OpenJDK 13 EA Build 31.
>> >
>> > I can perform any test on this machine that you instruct me to.
>> >
>> > Please advise,
>> > Stefan
>> >
>>
>>
>
> --
> Stefan Reich
> BotCompany.de // Java-based operating systems
>


-- 
Stefan Reich
BotCompany.de // Java-based operating systems