[jira] [Commented] (NETBEANS-3900) Using netbeans to profile a Play1 app crashes the app after a while
[
https://issues.apache.org/jira/browse/NETBEANS-3900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17159506#comment-17159506
]
David Costanzo commented on NETBEANS-3900:
--
I tried using Net Beans 12 because it includes the fix for NETBEANS-1248, but
profiling still crashed my web application. I'm going to continue to use the
private build of the profiling library that you created for me in the meantime.
> Using netbeans to profile a Play1 app crashes the app after a while
> ---
>
> Key: NETBEANS-3900
> URL: https://issues.apache.org/jira/browse/NETBEANS-3900
> Project: NetBeans
> Issue Type: Bug
> Components: profiler - Base
>Affects Versions: 11.0, 11.2
> Environment: JDK: OpenJDK 11 or HotSpot Java 8.
> OS: 64-bit Ubuntu or OpenSUSE
>Reporter: David Costanzo
>Priority: Major
> Attachments: hs_err_pid24234.log, hs_err_pid24980.log
>
>
> When I use NetBeans 11.2 to profile a stand alone web application that is
> based on the Play 1 framework, the profiling works for a little while, then
> the JVM that's being profiled crashes.
> I cannot reproduce a crash when using a java command-line tool, only my web
> apps crash.
> I am able to profile using visualvm.
> If I use Java 8 for both the target app's JVM and netbean's JVM, I can still
> reproduce the crash. (Mixing a Java 8 app with a Java 11 netbeans makes it
> so that the profiler cannot attach).
> If I drop down to NetBeans 9, I can still reproduce the crash. (NetBeans 8.2
> cannot attach a profiler).
> Unfortunately, I have been unsuccessful at creating a small, isolated repro.
> All of our applications rely heavily our corporate file system, our corporate
> databases, and ancillary services that are only available on our LAN. When I
> try to remove these dependencies, I also lose the repro.
> Also unfortunate is that I don't understand how a Java profiler is
> implemented, so I don't know how to investigate this. I also don't know how
> to build a profiler with symbols, which I assume would help.
> A possibly relevant bit for one log is (included for searchability):
> {noformat}
> --- T H R E A D ---
> Current thread (0x7fae40021000): JavaThread "*** Profiler Agent
> Communication Thread" daemon [_thread_in_vm, id=5892,
> stack(0x7fad2b68b000,0x7fad2b78c000)]
> Stack: [0x7fad2b68b000,0x7fad2b78c000], sp=0x7fad2b78a560, free
> space=1021k
> Native frames: (J=compiled Java code, A=aot compiled Java code,
> j=interpreted, Vv=VM code, C=native code)
> V [libjvm.so+0xb8a836] Method::checked_resolve_jmethod_id(_jmethodID*)+0x26
> V [libjvm.so+0x9ac918] jvmti_GetMethodDeclaringClass+0x1d8
> Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
> j
> org.netbeans.lib.profiler.server.system.Stacks.getMethodNamesForJMethodIds(I[I[I)[B+0
> j
> org.netbeans.lib.profiler.server.ProfilerInterface.getMethodNamesForJMethodIds([I)Lorg/netbeans/lib/profiler/wireprotocol/MethodNamesResponse;+20
> j
> org.netbeans.lib.profiler.server.ProfilerServer.handleClientCommand(Lorg/netbeans/lib/profiler/wireprotocol/Command;)V+691
> j org.netbeans.lib.profiler.server.ProfilerServer.listenToClient()V+48
> j org.netbeans.lib.profiler.server.ProfilerServer.run()V+22
> v ~StubRoutines::call_stub
> siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr:
> 0x00020010
> Register to memory mapping:
> RAX=0x0002 is an unknown value
> RBX=0x7fae0020 points into unknown readable memory: 00 00 00 00 02 00
> 00 00
> RCX=0x7fad2b8954c0: in
> /local/netbeans_11_2/profiler/lib/deployed/jdk16/linux-amd64/libprofilerinterface.so
> at 0x7fad2b78c000
> RDX=0x7faed95ee300: in
> /scharp/xapps/fw/share/jdk-11.0.5_10-hotspot/lib/server/libjvm.so at
> 0x7faed8f72000
> RSP=0x7fad2b78a560 is pointing into the stack for thread:
> 0x7fae40021000
> RBP=0x7fad2b78a570 is pointing into the stack for thread:
> 0x7fae40021000
> RSI=0x7fae40021000 is a thread
> RDI=0x7fae points into unknown readable memory: 20 00 00 00 ae 7f
> 00 00
> R8 =0x0002 is an unknown value
> R9 =0x00ad is an unknown value
> R10=0x0011 is an unknown value
> R11=0x7faeda5ae4c0: in
> /lib/x86_64-linux-gnu/libc.so.6 at 0x7faeda3ff000
> R12=0x7fae3401cdc0 points into unknown readable memory: 60 49 38 da ae 7f
> 00 00
> R13=0x7fad2b78a650 is pointing into the stack for thread:
> 0x7fae40021000
> R14=0x7fae points into unknown readable memory: 20 00 00 00 ae 7f
> 00 00
> R15=0x7fad2b78a5a0 is pointing into the stack for thread:
> 0x7fae40021000
> {noformat}
> I have opened this bug at the suggestion of [~pete
[jira] [Commented] (NETBEANS-3900) Using netbeans to profile a Play1 app crashes the app after a while
[
https://issues.apache.org/jira/browse/NETBEANS-3900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17047658#comment-17047658
]
David Costanzo commented on NETBEANS-3900:
--
{quote}Anyway, can you tell me, did you see any error lines starting "***
PROFILER INTERFACE Error request for method XXX which is not known" in the NB
output tab?
{quote}
I'm not sure if I'm looking at the right thing, but if I select "View -> IDE
Log", an "Output - IDE Log" tab appears. In it, after a successful profiling
run which would have crashed in NB 11.2, I don't see that line. I do see the
other line you were talking about `*** PROFILER INTERFACE 200223` in the server
console output of the app being profiled.
{quote}Would you mind continuing to use this version for a while to check that
the problem doesn't recur?
{quote}
Hah, just try and stop me. I've been profiling like crazy now that I can
again. Years ago, when lambda functions were added to Java, there was a
similar problem and I had to use a private build of netbeans to profile my
applications. I used it for years. So I have no problem using this one and
I'll recommend that everyone on my team also use it.
I don't know how important it is to you that you understand _why_ your new
profiler library fixes my crash, but, if you want, I can try running with a
profiler that doesn't have the fix NETBEANS-1428 or anything else you like.
Unrelated to this ticketI've noticed that the "Total Time (CPU)" includes
time that threads were explicitly waiting and not taking CPU (for example,
blocked on a socket select) and this interferes a little with analysis of the
profiling information. Is it appropriate to open tickets for that kind of
thing? If so, is that profiler-base or somewhere else?
> Using netbeans to profile a Play1 app crashes the app after a while
> ---
>
> Key: NETBEANS-3900
> URL: https://issues.apache.org/jira/browse/NETBEANS-3900
> Project: NetBeans
> Issue Type: Bug
> Components: profiler - Base
>Affects Versions: 11.0, 11.2
> Environment: JDK: OpenJDK 11 or HotSpot Java 8.
> OS: 64-bit Ubuntu or OpenSUSE
>Reporter: David Costanzo
>Priority: Major
> Attachments: hs_err_pid24234.log, hs_err_pid24980.log
>
>
> When I use NetBeans 11.2 to profile a stand alone web application that is
> based on the Play 1 framework, the profiling works for a little while, then
> the JVM that's being profiled crashes.
> I cannot reproduce a crash when using a java command-line tool, only my web
> apps crash.
> I am able to profile using visualvm.
> If I use Java 8 for both the target app's JVM and netbean's JVM, I can still
> reproduce the crash. (Mixing a Java 8 app with a Java 11 netbeans makes it
> so that the profiler cannot attach).
> If I drop down to NetBeans 9, I can still reproduce the crash. (NetBeans 8.2
> cannot attach a profiler).
> Unfortunately, I have been unsuccessful at creating a small, isolated repro.
> All of our applications rely heavily our corporate file system, our corporate
> databases, and ancillary services that are only available on our LAN. When I
> try to remove these dependencies, I also lose the repro.
> Also unfortunate is that I don't understand how a Java profiler is
> implemented, so I don't know how to investigate this. I also don't know how
> to build a profiler with symbols, which I assume would help.
> A possibly relevant bit for one log is (included for searchability):
> {noformat}
> --- T H R E A D ---
> Current thread (0x7fae40021000): JavaThread "*** Profiler Agent
> Communication Thread" daemon [_thread_in_vm, id=5892,
> stack(0x7fad2b68b000,0x7fad2b78c000)]
> Stack: [0x7fad2b68b000,0x7fad2b78c000], sp=0x7fad2b78a560, free
> space=1021k
> Native frames: (J=compiled Java code, A=aot compiled Java code,
> j=interpreted, Vv=VM code, C=native code)
> V [libjvm.so+0xb8a836] Method::checked_resolve_jmethod_id(_jmethodID*)+0x26
> V [libjvm.so+0x9ac918] jvmti_GetMethodDeclaringClass+0x1d8
> Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
> j
> org.netbeans.lib.profiler.server.system.Stacks.getMethodNamesForJMethodIds(I[I[I)[B+0
> j
> org.netbeans.lib.profiler.server.ProfilerInterface.getMethodNamesForJMethodIds([I)Lorg/netbeans/lib/profiler/wireprotocol/MethodNamesResponse;+20
> j
> org.netbeans.lib.profiler.server.ProfilerServer.handleClientCommand(Lorg/netbeans/lib/profiler/wireprotocol/Command;)V+691
> j org.netbeans.lib.profiler.server.ProfilerServer.listenToClient()V+48
> j org.netbeans.lib.profiler.server.ProfilerServer.run()V+22
> v ~StubRoutines::call_stub
> siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr:
> 0x0002000
[jira] [Commented] (NETBEANS-3900) Using netbeans to profile a Play1 app crashes the app after a while
[
https://issues.apache.org/jira/browse/NETBEANS-3900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17046883#comment-17046883
]
Peter Hull commented on NETBEANS-3900:
--
I'm going to take that as a positive.
I apologise, it wasn't clear from my comment but the changes here are in
addition to the ones I did for NETBEANS-1428 which I thought would only help
Windows and be neutral for everything else.
It's possible that just recompiling fixed something (a library or ABI issue) -
as far as I can tell, the native code is not rebuilt by Jenkins (the libraries
are dated approx 2017)
Anyway, can you tell me, did you see any error lines starting "*** PROFILER
INTERFACE Error request for method XXX which is not known" in the NB output tab?
Would you mind continuing to use this version for a while to check that the
problem doesn't recur? I hope that I can get fixes for this and NETBEANS-1428
merged in the NB 12.0 window.
Thanks,
Peter
> Using netbeans to profile a Play1 app crashes the app after a while
> ---
>
> Key: NETBEANS-3900
> URL: https://issues.apache.org/jira/browse/NETBEANS-3900
> Project: NetBeans
> Issue Type: Bug
> Components: profiler - Base
>Affects Versions: 11.0, 11.2
> Environment: JDK: OpenJDK 11 or HotSpot Java 8.
> OS: 64-bit Ubuntu or OpenSUSE
>Reporter: David Costanzo
>Priority: Major
> Attachments: hs_err_pid24234.log, hs_err_pid24980.log
>
>
> When I use NetBeans 11.2 to profile a stand alone web application that is
> based on the Play 1 framework, the profiling works for a little while, then
> the JVM that's being profiled crashes.
> I cannot reproduce a crash when using a java command-line tool, only my web
> apps crash.
> I am able to profile using visualvm.
> If I use Java 8 for both the target app's JVM and netbean's JVM, I can still
> reproduce the crash. (Mixing a Java 8 app with a Java 11 netbeans makes it
> so that the profiler cannot attach).
> If I drop down to NetBeans 9, I can still reproduce the crash. (NetBeans 8.2
> cannot attach a profiler).
> Unfortunately, I have been unsuccessful at creating a small, isolated repro.
> All of our applications rely heavily our corporate file system, our corporate
> databases, and ancillary services that are only available on our LAN. When I
> try to remove these dependencies, I also lose the repro.
> Also unfortunate is that I don't understand how a Java profiler is
> implemented, so I don't know how to investigate this. I also don't know how
> to build a profiler with symbols, which I assume would help.
> A possibly relevant bit for one log is (included for searchability):
> {noformat}
> --- T H R E A D ---
> Current thread (0x7fae40021000): JavaThread "*** Profiler Agent
> Communication Thread" daemon [_thread_in_vm, id=5892,
> stack(0x7fad2b68b000,0x7fad2b78c000)]
> Stack: [0x7fad2b68b000,0x7fad2b78c000], sp=0x7fad2b78a560, free
> space=1021k
> Native frames: (J=compiled Java code, A=aot compiled Java code,
> j=interpreted, Vv=VM code, C=native code)
> V [libjvm.so+0xb8a836] Method::checked_resolve_jmethod_id(_jmethodID*)+0x26
> V [libjvm.so+0x9ac918] jvmti_GetMethodDeclaringClass+0x1d8
> Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
> j
> org.netbeans.lib.profiler.server.system.Stacks.getMethodNamesForJMethodIds(I[I[I)[B+0
> j
> org.netbeans.lib.profiler.server.ProfilerInterface.getMethodNamesForJMethodIds([I)Lorg/netbeans/lib/profiler/wireprotocol/MethodNamesResponse;+20
> j
> org.netbeans.lib.profiler.server.ProfilerServer.handleClientCommand(Lorg/netbeans/lib/profiler/wireprotocol/Command;)V+691
> j org.netbeans.lib.profiler.server.ProfilerServer.listenToClient()V+48
> j org.netbeans.lib.profiler.server.ProfilerServer.run()V+22
> v ~StubRoutines::call_stub
> siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr:
> 0x00020010
> Register to memory mapping:
> RAX=0x0002 is an unknown value
> RBX=0x7fae0020 points into unknown readable memory: 00 00 00 00 02 00
> 00 00
> RCX=0x7fad2b8954c0: in
> /local/netbeans_11_2/profiler/lib/deployed/jdk16/linux-amd64/libprofilerinterface.so
> at 0x7fad2b78c000
> RDX=0x7faed95ee300: in
> /scharp/xapps/fw/share/jdk-11.0.5_10-hotspot/lib/server/libjvm.so at
> 0x7faed8f72000
> RSP=0x7fad2b78a560 is pointing into the stack for thread:
> 0x7fae40021000
> RBP=0x7fad2b78a570 is pointing into the stack for thread:
> 0x7fae40021000
> RSI=0x7fae40021000 is a thread
> RDI=0x7fae points into unknown readable memory: 20 00 00 00 ae 7f
> 00 00
> R8 =0x0002 is an unknown value
> R9 =0x00ad is an unknown value
> R10=0x000
[jira] [Commented] (NETBEANS-3900) Using netbeans to profile a Play1 app crashes the app after a while
[
https://issues.apache.org/jira/browse/NETBEANS-3900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17046746#comment-17046746
]
David Costanzo commented on NETBEANS-3900:
--
I cannot reproduce the problem with profilerinterface200223.zip. After not
being able to reproduce it with profilerinterface200223.zip, I reproduced it on
the mainline netbeans 11.2 (twice) just to make sure it wasn't something that
changed on my machine in the meantime.
I guess the extra check made a difference. Either that or you compiled better
than Jenkins did.
> Using netbeans to profile a Play1 app crashes the app after a while
> ---
>
> Key: NETBEANS-3900
> URL: https://issues.apache.org/jira/browse/NETBEANS-3900
> Project: NetBeans
> Issue Type: Bug
> Components: profiler - Base
>Affects Versions: 11.0, 11.2
> Environment: JDK: OpenJDK 11 or HotSpot Java 8.
> OS: 64-bit Ubuntu or OpenSUSE
>Reporter: David Costanzo
>Priority: Major
> Attachments: hs_err_pid24234.log, hs_err_pid24980.log
>
>
> When I use NetBeans 11.2 to profile a stand alone web application that is
> based on the Play 1 framework, the profiling works for a little while, then
> the JVM that's being profiled crashes.
> I cannot reproduce a crash when using a java command-line tool, only my web
> apps crash.
> I am able to profile using visualvm.
> If I use Java 8 for both the target app's JVM and netbean's JVM, I can still
> reproduce the crash. (Mixing a Java 8 app with a Java 11 netbeans makes it
> so that the profiler cannot attach).
> If I drop down to NetBeans 9, I can still reproduce the crash. (NetBeans 8.2
> cannot attach a profiler).
> Unfortunately, I have been unsuccessful at creating a small, isolated repro.
> All of our applications rely heavily our corporate file system, our corporate
> databases, and ancillary services that are only available on our LAN. When I
> try to remove these dependencies, I also lose the repro.
> Also unfortunate is that I don't understand how a Java profiler is
> implemented, so I don't know how to investigate this. I also don't know how
> to build a profiler with symbols, which I assume would help.
> A possibly relevant bit for one log is (included for searchability):
> {noformat}
> --- T H R E A D ---
> Current thread (0x7fae40021000): JavaThread "*** Profiler Agent
> Communication Thread" daemon [_thread_in_vm, id=5892,
> stack(0x7fad2b68b000,0x7fad2b78c000)]
> Stack: [0x7fad2b68b000,0x7fad2b78c000], sp=0x7fad2b78a560, free
> space=1021k
> Native frames: (J=compiled Java code, A=aot compiled Java code,
> j=interpreted, Vv=VM code, C=native code)
> V [libjvm.so+0xb8a836] Method::checked_resolve_jmethod_id(_jmethodID*)+0x26
> V [libjvm.so+0x9ac918] jvmti_GetMethodDeclaringClass+0x1d8
> Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
> j
> org.netbeans.lib.profiler.server.system.Stacks.getMethodNamesForJMethodIds(I[I[I)[B+0
> j
> org.netbeans.lib.profiler.server.ProfilerInterface.getMethodNamesForJMethodIds([I)Lorg/netbeans/lib/profiler/wireprotocol/MethodNamesResponse;+20
> j
> org.netbeans.lib.profiler.server.ProfilerServer.handleClientCommand(Lorg/netbeans/lib/profiler/wireprotocol/Command;)V+691
> j org.netbeans.lib.profiler.server.ProfilerServer.listenToClient()V+48
> j org.netbeans.lib.profiler.server.ProfilerServer.run()V+22
> v ~StubRoutines::call_stub
> siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr:
> 0x00020010
> Register to memory mapping:
> RAX=0x0002 is an unknown value
> RBX=0x7fae0020 points into unknown readable memory: 00 00 00 00 02 00
> 00 00
> RCX=0x7fad2b8954c0: in
> /local/netbeans_11_2/profiler/lib/deployed/jdk16/linux-amd64/libprofilerinterface.so
> at 0x7fad2b78c000
> RDX=0x7faed95ee300: in
> /scharp/xapps/fw/share/jdk-11.0.5_10-hotspot/lib/server/libjvm.so at
> 0x7faed8f72000
> RSP=0x7fad2b78a560 is pointing into the stack for thread:
> 0x7fae40021000
> RBP=0x7fad2b78a570 is pointing into the stack for thread:
> 0x7fae40021000
> RSI=0x7fae40021000 is a thread
> RDI=0x7fae points into unknown readable memory: 20 00 00 00 ae 7f
> 00 00
> R8 =0x0002 is an unknown value
> R9 =0x00ad is an unknown value
> R10=0x0011 is an unknown value
> R11=0x7faeda5ae4c0: in
> /lib/x86_64-linux-gnu/libc.so.6 at 0x7faeda3ff000
> R12=0x7fae3401cdc0 points into unknown readable memory: 60 49 38 da ae 7f
> 00 00
> R13=0x7fad2b78a650 is pointing into the stack for thread:
> 0x7fae40021000
> R14=0x7fae points into unknown readable memory: 20 00 00 00 ae 7f
> 00 00
> R15=0x7fad2
[jira] [Commented] (NETBEANS-3900) Using netbeans to profile a Play1 app crashes the app after a while
[
https://issues.apache.org/jira/browse/NETBEANS-3900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17045320#comment-17045320
]
Peter Hull commented on NETBEANS-3900:
--
This looks like it's going to be tricky because of the byte-code rewriting
stuff, which I am not an expert in. However as a start I've recompiled the
native interface with an extra check to see how we get on.
It's in the profilerinterface200223.zip fie here:
[https://github.com/pedro-w/netbeans/releases/tag/v0.200223]
and the source code for your information on this branch:
[https://github.com/pedro-w/netbeans/tree/support-3900]
You should see a line starting "*** PROFILER INTERFACE" in the Netbeans output
tab, then you can be sure it's using the new version.
Let me know if this changes anything.
> Using netbeans to profile a Play1 app crashes the app after a while
> ---
>
> Key: NETBEANS-3900
> URL: https://issues.apache.org/jira/browse/NETBEANS-3900
> Project: NetBeans
> Issue Type: Bug
> Components: profiler - Base
>Affects Versions: 11.0, 11.2
> Environment: JDK: OpenJDK 11 or HotSpot Java 8.
> OS: 64-bit Ubuntu or OpenSUSE
>Reporter: David Costanzo
>Priority: Major
> Attachments: hs_err_pid24234.log, hs_err_pid24980.log
>
>
> When I use NetBeans 11.2 to profile a stand alone web application that is
> based on the Play 1 framework, the profiling works for a little while, then
> the JVM that's being profiled crashes.
> I cannot reproduce a crash when using a java command-line tool, only my web
> apps crash.
> I am able to profile using visualvm.
> If I use Java 8 for both the target app's JVM and netbean's JVM, I can still
> reproduce the crash. (Mixing a Java 8 app with a Java 11 netbeans makes it
> so that the profiler cannot attach).
> If I drop down to NetBeans 9, I can still reproduce the crash. (NetBeans 8.2
> cannot attach a profiler).
> Unfortunately, I have been unsuccessful at creating a small, isolated repro.
> All of our applications rely heavily our corporate file system, our corporate
> databases, and ancillary services that are only available on our LAN. When I
> try to remove these dependencies, I also lose the repro.
> Also unfortunate is that I don't understand how a Java profiler is
> implemented, so I don't know how to investigate this. I also don't know how
> to build a profiler with symbols, which I assume would help.
> A possibly relevant bit for one log is (included for searchability):
> {noformat}
> --- T H R E A D ---
> Current thread (0x7fae40021000): JavaThread "*** Profiler Agent
> Communication Thread" daemon [_thread_in_vm, id=5892,
> stack(0x7fad2b68b000,0x7fad2b78c000)]
> Stack: [0x7fad2b68b000,0x7fad2b78c000], sp=0x7fad2b78a560, free
> space=1021k
> Native frames: (J=compiled Java code, A=aot compiled Java code,
> j=interpreted, Vv=VM code, C=native code)
> V [libjvm.so+0xb8a836] Method::checked_resolve_jmethod_id(_jmethodID*)+0x26
> V [libjvm.so+0x9ac918] jvmti_GetMethodDeclaringClass+0x1d8
> Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
> j
> org.netbeans.lib.profiler.server.system.Stacks.getMethodNamesForJMethodIds(I[I[I)[B+0
> j
> org.netbeans.lib.profiler.server.ProfilerInterface.getMethodNamesForJMethodIds([I)Lorg/netbeans/lib/profiler/wireprotocol/MethodNamesResponse;+20
> j
> org.netbeans.lib.profiler.server.ProfilerServer.handleClientCommand(Lorg/netbeans/lib/profiler/wireprotocol/Command;)V+691
> j org.netbeans.lib.profiler.server.ProfilerServer.listenToClient()V+48
> j org.netbeans.lib.profiler.server.ProfilerServer.run()V+22
> v ~StubRoutines::call_stub
> siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr:
> 0x00020010
> Register to memory mapping:
> RAX=0x0002 is an unknown value
> RBX=0x7fae0020 points into unknown readable memory: 00 00 00 00 02 00
> 00 00
> RCX=0x7fad2b8954c0: in
> /local/netbeans_11_2/profiler/lib/deployed/jdk16/linux-amd64/libprofilerinterface.so
> at 0x7fad2b78c000
> RDX=0x7faed95ee300: in
> /scharp/xapps/fw/share/jdk-11.0.5_10-hotspot/lib/server/libjvm.so at
> 0x7faed8f72000
> RSP=0x7fad2b78a560 is pointing into the stack for thread:
> 0x7fae40021000
> RBP=0x7fad2b78a570 is pointing into the stack for thread:
> 0x7fae40021000
> RSI=0x7fae40021000 is a thread
> RDI=0x7fae points into unknown readable memory: 20 00 00 00 ae 7f
> 00 00
> R8 =0x0002 is an unknown value
> R9 =0x00ad is an unknown value
> R10=0x0011 is an unknown value
> R11=0x7faeda5ae4c0: in
> /lib/x86_64-linux-gnu/libc.so.6 at 0x7faeda3ff000
> R12=0x7fae3401cdc0 points into unknown readab
[jira] [Commented] (NETBEANS-3900) Using netbeans to profile a Play1 app crashes the app after a while
[
https://issues.apache.org/jira/browse/NETBEANS-3900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17040524#comment-17040524
]
David Costanzo commented on NETBEANS-3900:
--
{quote}I appreciate you can't share your web app source over the internet but
would you be OK with replacing the native component of the NetBeans profiler
(libprofilerinterface.so) with a custom version that had more checks or more
logging? Obviously I would give you the source code so you can audit or rebuild
yourself.
{quote}
I can share the source code of my web apps, but they're complicated and can't
be run except on a few machines within my LAN. I don't expect they'd be
enlightening.
I would be happy to replace my libprofilerinterface.so. That seems like the
easiest way forward. My dev machine at work is locked down and doesn't have
any native build tools, so it'll be easier if you provide me with the compiled
binary.
The Play framework does a lot of weird stuff in Java. It's got an embedded
compiler so that it can re-compile the app if any source code changes. (I
disable the recompiling when profiling.) It's got some kind of byte code
rewriting library to be able to "enhance" classes at runtime. It's got
continuations where execution pauses and resumes with a different stack on the
same thread. I don't know if any of that matters, but it might not be the
normal byte code or control flow that javac produces. Even so, I used to be
able to profile these apps with NetBeans and now I can't. The machine I used
to use has been wiped, so I can't use it as a reference.
> Using netbeans to profile a Play1 app crashes the app after a while
> ---
>
> Key: NETBEANS-3900
> URL: https://issues.apache.org/jira/browse/NETBEANS-3900
> Project: NetBeans
> Issue Type: Bug
> Components: profiler - Base
>Affects Versions: 11.0, 11.2
> Environment: JDK: OpenJDK 11 or HotSpot Java 8.
> OS: 64-bit Ubuntu or OpenSUSE
>Reporter: David Costanzo
>Priority: Major
> Attachments: hs_err_pid24234.log, hs_err_pid24980.log
>
>
> When I use NetBeans 11.2 to profile a stand alone web application that is
> based on the Play 1 framework, the profiling works for a little while, then
> the JVM that's being profiled crashes.
> I cannot reproduce a crash when using a java command-line tool, only my web
> apps crash.
> I am able to profile using visualvm.
> If I use Java 8 for both the target app's JVM and netbean's JVM, I can still
> reproduce the crash. (Mixing a Java 8 app with a Java 11 netbeans makes it
> so that the profiler cannot attach).
> If I drop down to NetBeans 9, I can still reproduce the crash. (NetBeans 8.2
> cannot attach a profiler).
> Unfortunately, I have been unsuccessful at creating a small, isolated repro.
> All of our applications rely heavily our corporate file system, our corporate
> databases, and ancillary services that are only available on our LAN. When I
> try to remove these dependencies, I also lose the repro.
> Also unfortunate is that I don't understand how a Java profiler is
> implemented, so I don't know how to investigate this. I also don't know how
> to build a profiler with symbols, which I assume would help.
> A possibly relevant bit for one log is (included for searchability):
> {noformat}
> --- T H R E A D ---
> Current thread (0x7fae40021000): JavaThread "*** Profiler Agent
> Communication Thread" daemon [_thread_in_vm, id=5892,
> stack(0x7fad2b68b000,0x7fad2b78c000)]
> Stack: [0x7fad2b68b000,0x7fad2b78c000], sp=0x7fad2b78a560, free
> space=1021k
> Native frames: (J=compiled Java code, A=aot compiled Java code,
> j=interpreted, Vv=VM code, C=native code)
> V [libjvm.so+0xb8a836] Method::checked_resolve_jmethod_id(_jmethodID*)+0x26
> V [libjvm.so+0x9ac918] jvmti_GetMethodDeclaringClass+0x1d8
> Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
> j
> org.netbeans.lib.profiler.server.system.Stacks.getMethodNamesForJMethodIds(I[I[I)[B+0
> j
> org.netbeans.lib.profiler.server.ProfilerInterface.getMethodNamesForJMethodIds([I)Lorg/netbeans/lib/profiler/wireprotocol/MethodNamesResponse;+20
> j
> org.netbeans.lib.profiler.server.ProfilerServer.handleClientCommand(Lorg/netbeans/lib/profiler/wireprotocol/Command;)V+691
> j org.netbeans.lib.profiler.server.ProfilerServer.listenToClient()V+48
> j org.netbeans.lib.profiler.server.ProfilerServer.run()V+22
> v ~StubRoutines::call_stub
> siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr:
> 0x00020010
> Register to memory mapping:
> RAX=0x0002 is an unknown value
> RBX=0x7fae0020 points into unknown readable memory: 00 00 00 00 02 00
> 00 00
> RCX=0x7fad2b8954c0:
[jira] [Commented] (NETBEANS-3900) Using netbeans to profile a Play1 app crashes the app after a while
[
https://issues.apache.org/jira/browse/NETBEANS-3900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17040458#comment-17040458
]
Peter Hull commented on NETBEANS-3900:
--
This is definitely helpful, thanks. I can have a think about what might be the
cause of this. I appreciate you can't share your web app source over the
internet but would you be OK with replacing the native component of the
NetBeans profiler (libprofilerinterface.so) with a custom version that had more
checks or more logging? Obviously I would give you the source code so you can
audit or rebuild yourself.
For info, the last bit of NB code executed before we jump into the JVM itself
(where the crash happens) is here:
https://github.com/apache/netbeans/blob/34eb8db09606a1208c388fe8ca4214833142af4d/profiler/lib.profiler/src/org/netbeans/lib/profiler/server/ProfilerInterface.java#L399
implemented here:
[https://github.com/apache/netbeans/blob/4d1b7e176a383c0bf01b116b7bf9c9514e46eb33/profiler/lib.profiler/native/src-jdk15/Stacks.c#L220]
We track the jmethodIDs of all methods on the Java call stack and my guess is
either: we've exceeded some limit OR it's something concurrency related. This
is based on the crash only happening in a complex application and after some
run-time has elapsed.
> Using netbeans to profile a Play1 app crashes the app after a while
> ---
>
> Key: NETBEANS-3900
> URL: https://issues.apache.org/jira/browse/NETBEANS-3900
> Project: NetBeans
> Issue Type: Bug
> Components: profiler - Base
>Affects Versions: 11.0, 11.2
> Environment: JDK: OpenJDK 11 or HotSpot Java 8.
> OS: 64-bit Ubuntu or OpenSUSE
>Reporter: David Costanzo
>Priority: Major
> Attachments: hs_err_pid24234.log, hs_err_pid24980.log
>
>
> When I use NetBeans 11.2 to profile a stand alone web application that is
> based on the Play 1 framework, the profiling works for a little while, then
> the JVM that's being profiled crashes.
> I cannot reproduce a crash when using a java command-line tool, only my web
> apps crash.
> I am able to profile using visualvm.
> If I use Java 8 for both the target app's JVM and netbean's JVM, I can still
> reproduce the crash. (Mixing a Java 8 app with a Java 11 netbeans makes it
> so that the profiler cannot attach).
> If I drop down to NetBeans 9, I can still reproduce the crash. (NetBeans 8.2
> cannot attach a profiler).
> Unfortunately, I have been unsuccessful at creating a small, isolated repro.
> All of our applications rely heavily our corporate file system, our corporate
> databases, and ancillary services that are only available on our LAN. When I
> try to remove these dependencies, I also lose the repro.
> Also unfortunate is that I don't understand how a Java profiler is
> implemented, so I don't know how to investigate this. I also don't know how
> to build a profiler with symbols, which I assume would help.
> A possibly relevant bit for one log is (included for searchability):
> {noformat}
> --- T H R E A D ---
> Current thread (0x7fae40021000): JavaThread "*** Profiler Agent
> Communication Thread" daemon [_thread_in_vm, id=5892,
> stack(0x7fad2b68b000,0x7fad2b78c000)]
> Stack: [0x7fad2b68b000,0x7fad2b78c000], sp=0x7fad2b78a560, free
> space=1021k
> Native frames: (J=compiled Java code, A=aot compiled Java code,
> j=interpreted, Vv=VM code, C=native code)
> V [libjvm.so+0xb8a836] Method::checked_resolve_jmethod_id(_jmethodID*)+0x26
> V [libjvm.so+0x9ac918] jvmti_GetMethodDeclaringClass+0x1d8
> Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
> j
> org.netbeans.lib.profiler.server.system.Stacks.getMethodNamesForJMethodIds(I[I[I)[B+0
> j
> org.netbeans.lib.profiler.server.ProfilerInterface.getMethodNamesForJMethodIds([I)Lorg/netbeans/lib/profiler/wireprotocol/MethodNamesResponse;+20
> j
> org.netbeans.lib.profiler.server.ProfilerServer.handleClientCommand(Lorg/netbeans/lib/profiler/wireprotocol/Command;)V+691
> j org.netbeans.lib.profiler.server.ProfilerServer.listenToClient()V+48
> j org.netbeans.lib.profiler.server.ProfilerServer.run()V+22
> v ~StubRoutines::call_stub
> siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr:
> 0x00020010
> Register to memory mapping:
> RAX=0x0002 is an unknown value
> RBX=0x7fae0020 points into unknown readable memory: 00 00 00 00 02 00
> 00 00
> RCX=0x7fad2b8954c0: in
> /local/netbeans_11_2/profiler/lib/deployed/jdk16/linux-amd64/libprofilerinterface.so
> at 0x7fad2b78c000
> RDX=0x7faed95ee300: in
> /scharp/xapps/fw/share/jdk-11.0.5_10-hotspot/lib/server/libjvm.so at
> 0x7faed8f72000
> RSP=0x7fad2b78a560 is pointing into the stack for thread:
>
