Hi Marc, good to know the cause! It'd be really great if it could be fixed in JaCoCo.
Thanks a lot for your efforts! Alexey On Wednesday, November 3, 2021 at 5:51:30 PM UTC+1 Marc R. Hoffmann wrote: > Hi Alexey, > > I think I found the problem. This is the table before instrumentation: > > LocalVariableTable: > Start Length Slot Name Signature > 0 1 0 this LExample; > 0 1 1 greeting Ljava/lang/String; > > and this is the table after instrumentation: > > LocalVariableTable: > Start Length Slot Name Signature > 6 5 0 this LExample; > 6 5 1 greeting Ljava/lang/String; > > JaCoCo inserts initialization code at the beginning of every method. > Technically the parameters are still valid from the first position on and > their instruction range should not be moved by JaCoCo (JaCoCo will never > use these slots). Now in Jandex there is a check that method parameter > names must be valid from instruction 0 on: > > > https://github.com/wildfly/jandex/blob/2.4.1.Final/src/main/java/org/jboss/jandex/Indexer.java#L657 > > Honestly I never thought about the LocalVariableTable. I will try to find > out how this is handled in ASM and how this can be fixed in JaCoCo. > > Cheers, > -marc > > > On 3. Nov 2021, at 10:22, Alexey Loubyansky <olub...@redhat.com> wrote: > > That'll be awesome! Thanks, Marc! > > On Tuesday, November 2, 2021 at 10:27:13 PM UTC+1 Alexey Loubyansky wrote: > >> Actually, since the parameters aren't enabled in the compiler, it's >> actually this method >> https://github.com/wildfly/jandex/blob/2.4.1.Final/src/main/java/org/jboss/jandex/Indexer.java#L645 >> and this line >> https://github.com/wildfly/jandex/blob/2.4.1.Final/src/main/java/org/jboss/jandex/Indexer.java#L682 >> >> Before the instrumentation, the `debugParameterNames` gets initialized >> with `greeting` but after the instrumentation it's not. >> >> On Tuesday, November 2, 2021 at 10:01:42 PM UTC+1 Alexey Loubyansky wrote: >> >>> Hi Marc, >>> >>> right, the summary of the issue I referenced isn't specific enough for >>> you. I quickly put together a simple reproducer [1] but I haven't yet >>> actually debugged the Jandex code. It looks like the relevant method is [2] >>> and line [3]. >>> >>> [1] https://github.com/aloubyansky/playground/tree/jacoco-jandex >>> [2] >>> https://github.com/wildfly/jandex/blob/2.4.1.Final/src/main/java/org/jboss/jandex/Indexer.java#L1822 >>> [3] >>> https://github.com/wildfly/jandex/blob/2.4.1.Final/src/main/java/org/jboss/jandex/Indexer.java#L1897 >>> >>> Hope that helps. >>> >>> Thanks, >>> Alexey >>> On Tuesday, November 2, 2021 at 1:47:18 PM UTC+1 Marc R. Hoffmann wrote: >>> >>>> Hi Alexey, >>>> >>>> if I look at the stack trace of the original ticket I assume that this >>>> is not a problem with Jandex, but the code which makes assumptions about >>>> the data collected with Jandex. So I don’t think we can debug this from >>>> our >>>> side. >>>> >>>> Please feel free to to get in touch again, as soon as you can pinpoint >>>> the issue down to JaCoCo. >>>> >>>> Thanks, >>>> -marc >>>> >>>> On 2. Nov 2021, at 11:24, Alexey Loubyansky <olub...@redhat.com> wrote: >>>> >>>> Hi Marc, >>>> >>>> thanks for your response. I can describe what I was observing but I am >>>> not sure I'll be able to provide the necessary details to conclude where >>>> the info gets lost. >>>> >>>> In our case we are scanning the classpath looking for methods with >>>> specific annotations and then we are trying to figure out the method >>>> parameter names (among other things) using the Jandex library [1]. It >>>> appears Jandex does not actually require classes to be compiled with the >>>> `-parameters` argument to figure it out, it may pull the info from the >>>> local var table instead, IIUC. >>>> So, we have a Quarkus JaCoCo extension that allows to integrate JaCoCo >>>> into Quarkus tests. The extension calls the JaCoCo instrumenter API here >>>> [2]. If instead of returning the `enhanced` byte array I return the >>>> original `bytes` array, Jandex can figure out the method parameter names. >>>> I >>>> we return the `enhanced` array, Jandex fails to figure it out. If we >>>> compile the classes with the `-parameters` argument though, it works. >>>> I realize we need to debug this further to provide more info for you >>>> about what exactly Jandex is looking for in this case. But I thought I >>>> would still report the issue just in case it rings a bell. >>>> >>>> [1] https://github.com/wildfly/jandex >>>> [2] >>>> https://github.com/quarkusio/quarkus/blob/main/test-framework/jacoco/deployment/src/main/java/io/quarkus/jacoco/deployment/JacocoProcessor.java#L83 >>>> >>>> Thanks, >>>> Alexey >>>> On Tuesday, November 2, 2021 at 10:56:29 AM UTC+1 Marc R. Hoffmann >>>> wrote: >>>> >>>>> Hi Alexey, >>>>> >>>>> thanks for raising this issue. >>>>> >>>>> I think JaCoCo does the following: >>>>> >>>>> * The original local variable table is preserved >>>>> * JaCoCo adds a *synthetic* method $jacocoInit which has no >>>>> corresponding source, therefore no var table >>>>> * JaCoCo adds a additional local variable (for the probe array) which >>>>> has no corresponding source, therefore no var table >>>>> >>>>> Can you please give a specific instance, where the local variable >>>>> table is missing? >>>>> >>>>> Thanks, >>>>> -marc >>>>> >>>>> >>>>> >>>>> On 2. Nov 2021, at 08:48, Alexey Loubyansky <olub...@redhat.com> >>>>> wrote: >>>>> >>>>> Hello, >>>>> >>>>> it looks like the local variable table is missing after >>>>> instrumentation in some cases. >>>>> This was manifested in a Quarkus issue [1] Although there is a >>>>> workaround adding a compiler arg, there still seems to be an issue with >>>>> the >>>>> instrumentation. Will it be worth creating an issue? >>>>> >>>>> [1] https://github.com/quarkusio/quarkus/issues/21066 >>>>> >>>>> Thanks, >>>>> Alexey >>>>> >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "JaCoCo and EclEmma Users" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to jacoco+un...@googlegroups.com. >>>>> To view this discussion on the web visit >>>>> https://groups.google.com/d/msgid/jacoco/129a49d3-d611-419c-a601-ef979cf0119en%40googlegroups.com >>>>> >>>>> <https://groups.google.com/d/msgid/jacoco/129a49d3-d611-419c-a601-ef979cf0119en%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>>> >>>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "JaCoCo and EclEmma Users" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to jacoco+un...@googlegroups.com. >>>> >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/jacoco/fd9c24a1-58c9-4c86-a5c5-f774eee3fe98n%40googlegroups.com >>>> >>>> <https://groups.google.com/d/msgid/jacoco/fd9c24a1-58c9-4c86-a5c5-f774eee3fe98n%40googlegroups.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>>> >>>> > -- > You received this message because you are subscribed to the Google Groups > "JaCoCo and EclEmma Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to jacoco+un...@googlegroups.com. > > To view this discussion on the web visit > https://groups.google.com/d/msgid/jacoco/d3cd38d4-f5aa-4328-8f8c-da44ccd585b1n%40googlegroups.com > > <https://groups.google.com/d/msgid/jacoco/d3cd38d4-f5aa-4328-8f8c-da44ccd585b1n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > > -- You received this message because you are subscribed to the Google Groups "JaCoCo and EclEmma Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to jacoco+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jacoco/a871d2e5-c5ba-464e-875b-0a832166971bn%40googlegroups.com.
