[jira] [Comment Edited] (GROOVY-8324) Enabling groovy.indy.logging can lead to stack overflows
[
https://issues.apache.org/jira/browse/GROOVY-8324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16176930#comment-16176930
]
Matt Whipple edited comment on GROOVY-8324 at 9/22/17 6:56 PM:
---
Your bet was correct...the logging was cycling on a getter trying to stringify
the {{this}} argument where the toString() invoked that getter. I opened a PR
for what seems like a reasonable way to avoid this by not logging the {{this}}
argument:
https://github.com/apache/groovy/pull/604
Sample output from the git project linked in previous comment:
instance method:
{noformat}
INFO:
invocation of method 'getName'
invocation type: METHOD
sender: class gt.MyOtherObject
targetType: (MyOtherObject)Object
safe navigation: false
thisCall: true
spreadCall: false
with 1 arguments (including 'this')
{noformat}
non-instance method (unchanged):
{noformat}
INFO:
invocation of method 'append'
invocation type: METHOD
sender: class gt.MyOtherObject
targetType: (Object,Object)Object
safe navigation: false
thisCall: false
spreadCall: false
with 2 arguments
argument[0] = gt.MyOtherObject(
argument[1] = test0
{noformat}
was (Author: mwhipple):
Your bet was correct...the logging was cycling on a getter trying to stringify
the {{this}} argument where the toString() invoked that getter. I opened a PR
for what seems like a reasonable way to avoid this by not logging the {{this}}
argument:
https://github.com/apache/groovy/pull/604
Sample output from the git project above:
instance method:
{noformat}
INFO:
invocation of method 'getName'
invocation type: METHOD
sender: class gt.MyOtherObject
targetType: (MyOtherObject)Object
safe navigation: false
thisCall: true
spreadCall: false
with 1 arguments (including 'this')
{noformat}
non-instance method (unchanged):
{noformat}
INFO:
invocation of method 'append'
invocation type: METHOD
sender: class gt.MyOtherObject
targetType: (Object,Object)Object
safe navigation: false
thisCall: false
spreadCall: false
with 2 arguments
argument[0] = gt.MyOtherObject(
argument[1] = test0
{noformat}
> Enabling groovy.indy.logging can lead to stack overflows
>
>
> Key: GROOVY-8324
> URL: https://issues.apache.org/jira/browse/GROOVY-8324
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.4.12
>Reporter: Matt Whipple
>Priority: Minor
> Labels: invokedynamic
>
> Still digging through this a bit more, but while trying to diagnose
> performance issues I enabled indy logging which led to:
> {noformat}
> ! Caused by: java.lang.StackOverflowError: null
> ! at java.lang.Class.getEnclosingMethodInfo(Class.java:1072)
> ! at java.lang.Class.getEnclosingClass(Class.java:1272)
> ! at java.lang.Class.getSimpleBinaryName(Class.java:1443)
> ! at java.lang.Class.getSimpleName(Class.java:1309)
> ! at java.lang.invoke.MethodType.toString(MethodType.java:797)
> ! at java.lang.String.valueOf(String.java:2982)<---
> Loops back to here
> ! at java.lang.StringBuilder.append(StringBuilder.java:131)
> ! at
> org.codehaus.groovy.vmplugin.v7.Selector$MethodSelector.(Selector.java:488)
> ! at org.codehaus.groovy.vmplugin.v7.Selector.getSelector(Selector.java:98)
> ! at
> org.codehaus.groovy.vmplugin.v7.IndyInterface.selectMethod(IndyInterface.java:227)
> ! at MyDomainClass.toString(MyDomainClass.groovy)
> {noformat}
> The domain class itself stringifies without issue, changing the class to use
> {{@CompileStatic}} seems to have resolved this issue. It might be nice if
> that specific log message could be toggled independently of the others to try
> to avoid the possibility of blowing up while attempting to troubleshooting.
> {noformat}
> java version "1.8.0_45"
> Java(TM) SE Runtime Environment (build 1.8.0_45-b14)
> Java HotSpot(TM) 64-Bit Server VM (build 25.45-b02, mixed mode)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (GROOVY-8324) Enabling groovy.indy.logging can lead to stack overflows
[
https://issues.apache.org/jira/browse/GROOVY-8324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16173788#comment-16173788
]
Jochen Theodorou edited comment on GROOVY-8324 at 9/20/17 8:39 PM:
---
first time you mention @ToString. This is a strong indicator for the printing
of the arguments in the logging. "this" is the first argument, thus if
this.toString is done by invokedynamic, it will lead to an stack overflow.
Which
org.codehaus.groovy.vmplugin.v7.IndyInterface.selectMethod(IndyInterface.java:227)
needs a fix for the arguments. If you want to really get to the bottom if this
I suggest you remove parts from the logging message in this line and see which
is causing it. My bet is now on the arguments
was (Author: blackdrag):
first time you mention @ToString. This is a strong indicator for the printing
of the arguments in the logging. "this" is the first argument, thus if
this.toString is done by invokedynamic, it will lead to an stack overflow.
Which meand
org.codehaus.groovy.vmplugin.v7.Selector$MethodSelector.(Selector.java:499)
needs a fix for the arguments. If you want to really get to the bottom if this
I suggest you remove parts from the logging message in this line and see which
is causing it. My bet is now on the arguments
> Enabling groovy.indy.logging can lead to stack overflows
>
>
> Key: GROOVY-8324
> URL: https://issues.apache.org/jira/browse/GROOVY-8324
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.4.12
>Reporter: Matt Whipple
>Priority: Minor
> Labels: invokedynamic
>
> Still digging through this a bit more, but while trying to diagnose
> performance issues I enabled indy logging which led to:
> {noformat}
> ! Caused by: java.lang.StackOverflowError: null
> ! at java.lang.Class.getEnclosingMethodInfo(Class.java:1072)
> ! at java.lang.Class.getEnclosingClass(Class.java:1272)
> ! at java.lang.Class.getSimpleBinaryName(Class.java:1443)
> ! at java.lang.Class.getSimpleName(Class.java:1309)
> ! at java.lang.invoke.MethodType.toString(MethodType.java:797)
> ! at java.lang.String.valueOf(String.java:2982)<---
> Loops back to here
> ! at java.lang.StringBuilder.append(StringBuilder.java:131)
> ! at
> org.codehaus.groovy.vmplugin.v7.Selector$MethodSelector.(Selector.java:488)
> ! at org.codehaus.groovy.vmplugin.v7.Selector.getSelector(Selector.java:98)
> ! at
> org.codehaus.groovy.vmplugin.v7.IndyInterface.selectMethod(IndyInterface.java:227)
> ! at MyDomainClass.toString(MyDomainClass.groovy)
> {noformat}
> The domain class itself stringifies without issue, changing the class to use
> {{@CompileStatic}} seems to have resolved this issue. It might be nice if
> that specific log message could be toggled independently of the others to try
> to avoid the possibility of blowing up while attempting to troubleshooting.
> {noformat}
> java version "1.8.0_45"
> Java(TM) SE Runtime Environment (build 1.8.0_45-b14)
> Java HotSpot(TM) 64-Bit Server VM (build 25.45-b02, mixed mode)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (GROOVY-8324) Enabling groovy.indy.logging can lead to stack overflows
[
https://issues.apache.org/jira/browse/GROOVY-8324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16173398#comment-16173398
]
Matt Whipple edited comment on GROOVY-8324 at 9/20/17 4:00 PM:
---
Other domain classes are also resulting in similar issues, all of which are
relying on the {{@ToString}} AST Transformation. Here's another trace for
another class which seems to be getting stuck while stringifying the enumerated
arguments during the same logging block:
{noformat}
! java.lang.StackOverflowError: null
! at
org.codehaus.groovy.vmplugin.v7.IndyInterface$CALL_TYPES.values(IndyInterface.java:55)
! at org.codehaus.groovy.vmplugin.v7.Selector.getSelector(Selector.java:95)
! at
org.codehaus.groovy.vmplugin.v7.IndyInterface.selectMethod(IndyInterface.java:227)
! at foo.PendingChange.toString(PendingChangeDAO.groovy)
! at java.lang.String.valueOf(String.java:2982)
! at java.lang.StringBuilder.append(StringBuilder.java:131)
! at
org.codehaus.groovy.vmplugin.v7.Selector$MethodSelector.(Selector.java:499)
! at org.codehaus.groovy.vmplugin.v7.Selector.getSelector(Selector.java:98)
! at
org.codehaus.groovy.vmplugin.v7.IndyInterface.selectMethod(IndyInterface.java:227)
! at foo.PendingChange.toString(PendingChangeDAO.groovy)
! at java.lang.String.valueOf(String.java:2982)
! at java.lang.StringBuilder.append(StringBuilder.java:131)
! at
org.codehaus.groovy.vmplugin.v7.Selector$MethodSelector.(Selector.java:499)
! at org.codehaus.groovy.vmplugin.v7.Selector.getSelector(Selector.java:98)
! at
org.codehaus.groovy.vmplugin.v7.IndyInterface.selectMethod(IndyInterface.java:227)
! at foo.PendingChange.toString(PendingChangeDAO.groovy)
{noformat}
I'm not done looking at the primary issue yet after all but I'll likely try to
circle back to this shortly and see if I can debug it a bit.
was (Author: mwhipple):
Other domain classes are also resulting in similar issues, all of which are
relying on the {{@ToString}} AST Transformation. Here's another trace for
another class which seems to be getting stuck while stringifying the enumerated
arguments during the same logging block:
{noformat}
! java.lang.StackOverflowError: null
! at
org.codehaus.groovy.vmplugin.v7.IndyInterface$CALL_TYPES.values(IndyInterface.java:55)
! at org.codehaus.groovy.vmplugin.v7.Selector.getSelector(Selector.java:95)
! at
org.codehaus.groovy.vmplugin.v7.IndyInterface.selectMethod(IndyInterface.java:227)
! at foo.PendingChange.toString(PendingChangeDAO.groovy)
! at java.lang.String.valueOf(String.java:2982)
! at java.lang.StringBuilder.append(StringBuilder.java:131)
! at
org.codehaus.groovy.vmplugin.v7.Selector$MethodSelector.(Selector.java:499)
! at org.codehaus.groovy.vmplugin.v7.Selector.getSelector(Selector.java:98)
! at
org.codehaus.groovy.vmplugin.v7.IndyInterface.selectMethod(IndyInterface.java:227)
! at foo.PendingChange.toString(PendingChangeDAO.groovy)
! at java.lang.String.valueOf(String.java:2982)
! at java.lang.StringBuilder.append(StringBuilder.java:131)
! at
org.codehaus.groovy.vmplugin.v7.Selector$MethodSelector.(Selector.java:499)
! at org.codehaus.groovy.vmplugin.v7.Selector.getSelector(Selector.java:98)
! at
org.codehaus.groovy.vmplugin.v7.IndyInterface.selectMethod(IndyInterface.java:227)
! at foo.PendingChange.toString(PendingChangeDAO.groovy)
{noformat}
I'm not done looking at the primary issue yet after all but I'll likely try to
circle back to this in a bit and see if I can debug it a bit.
> Enabling groovy.indy.logging can lead to stack overflows
>
>
> Key: GROOVY-8324
> URL: https://issues.apache.org/jira/browse/GROOVY-8324
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.4.12
>Reporter: Matt Whipple
>Priority: Minor
> Labels: invokedynamic
>
> Still digging through this a bit more, but while trying to diagnose
> performance issues I enabled indy logging which led to:
> {noformat}
> ! Caused by: java.lang.StackOverflowError: null
> ! at java.lang.Class.getEnclosingMethodInfo(Class.java:1072)
> ! at java.lang.Class.getEnclosingClass(Class.java:1272)
> ! at java.lang.Class.getSimpleBinaryName(Class.java:1443)
> ! at java.lang.Class.getSimpleName(Class.java:1309)
> ! at java.lang.invoke.MethodType.toString(MethodType.java:797)
> ! at java.lang.String.valueOf(String.java:2982)<---
> Loops back to here
> ! at java.lang.StringBuilder.append(StringBuilder.java:131)
> ! at
> org.codehaus.groovy.vmplugin.v7.Selector$MethodSelector.(Selector.java:488)
> ! at org.codehaus.groovy.vmplugin.v7.Selector.getSelector(Selector.java:98)
> ! at
> org.codehaus.groovy.vmplugin.v7.IndyInterface.selectMethod(IndyInterface.java:227)
> ! at MyDomainClass.toString(MyDomainClass.groovy)
> {noformat}
> The domain class itself stringifies without issue,
