2

When taking a thread-dump, are we sure that what we're getting is necessarily coherent? With this I mean, that if it tells me that it's blocked it really is blocked? 

"subscription-akka.actor.default-dispatcher-16" #165 prio=5 os_prio=31 tid=0x00007fce799da000 nid=0xd70b waiting for monitor entry [0x0000700006b01000]
   java.lang.Thread.State: BLOCKED (on object monitor)
        at java.util.Formatter$Flags.parse(Formatter.java:4439)
        at java.util.Formatter$FormatSpecifier.flags(Formatter.java:2640)
        at java.util.Formatter$FormatSpecifier.<init>(Formatter.java:2709)

Because the example I have above is really strange, as Formatter.java:4439 points to

public static Flags parse(String s) {
            char[] ca = s.toCharArray();
  ->>> here Flags f = new Flags(0);
            for (int i = 0; i < ca.length; i++) {
                Flags v = parse(ca[i]);

which seems nonsensical (there doesn't seem to have been any changes recently in this class on OpenJDK 8 / Zulu (which I'm using).

Any (other) good explanation for the observed behavior?

Thanks

devoured elysium
  • 101,373
  • 131
  • 340
  • 557
  • 1
    I’d rather expect the line number to be wrong than the `BLOCKED` state. Or there’s Instrumentation going on. After all, there’s an allocation on this line and a monitoring tool recording allocations could cause the blocking. An interesting approach would be checking which other thread has the specified monitor and what that thread is doing. – Holger May 09 '19 at 13:51
  • @Holger I CTRL-F for "lock" or "synchr" and couldn't find anything on the whole file. Your suggestion is good, I'll see if I can get the whole thread-dump. – devoured elysium May 09 '19 at 13:53
  • 1
    Maybe, it’s this: https://stackoverflow.com/q/7067058/2711488 – Holger May 09 '19 at 14:12

0 Answers0