[ltt-dev] LTTV BUG: Recent upgrades broke the JNI interface

[ltt-dev] LTTV BUG: Recent upgrades broke the JNI interface

[Alexandre Montplaisir]

(It seems LTTV can't let go of me...)

I was trying to reinstall TMF, which includes the compilation of LTTV 
with  "./configure --with-jni-interface". However, make was now getting 
build errors:

jni_interface.c: In function 
?Java_org_eclipse_linuxtools_lttng_jni_JniMarkerField_ltt_1getOffset?:
jni_interface.c:1005: error: ?struct marker_field? has no member named 
?offset?
jni_interface.c: In function 
?Java_org_eclipse_linuxtools_lttng_jni_JniMarkerField_ltt_1getSize?:
jni_interface.c:1012: error: ?struct marker_field? has no member named 
?size?
jni_interface.c: In function 
?Java_org_eclipse_linuxtools_lttng_jni_JniMarkerField_ltt_1printMarkerField?:
jni_interface.c:1049: error: ?struct marker_field? has no member named 
?offset?
jni_interface.c:1050: error: ?struct marker_field? has no member named 
?size?
jni_interface.c: In function 
?Java_org_eclipse_linuxtools_lttng_jni_JniParser_ltt_1getParsedData?:
jni_interface.c:1134: error: ?struct marker_field? has no member named 
?offset?



Me and Michael were getting the same problem. Sun-java,  openjdk  gcj so 
were all giving the same errors. We ended up doing a git bisect, which 
gave the following commit as being responsible:

1184dc37d4cee465b9888fcec352c4ebe86d4246 is the first bad commit
commit 1184dc37d4cee465b9888fcec352c4ebe86d4246
Author: Mathieu Desnoyers <mathieu.desnoyers at polymtl.ca>
Date:   Fri Aug 20 12:02:42 2010 -0400

     ltt traceread: fix offsets calculation, should be per tracefile

     Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers at efficios.com>

:040000 040000 b655cf92cab4b1a11f4000e27663426da1e1d1dd 
4e660bf0e8d8ad2ff0262e1c3223490d3f400178 M    ltt


I'll look into it this afternoon, but I suppose the changes in that 
commit were made for a reason, so I'm not too confident touching it.

Thanks,
Alexandre


ps. On a side note, it seems building liblttvtraceread with OpenJDK 
still works with TMF, so there might be hope for a liblttvtraceread-jni 
package after all...

[ltt-dev] LTTV BUG: Recent upgrades broke the JNI interface

[Mathieu Desnoyers]

* Alexandre Montplaisir (alexandre.montplaisir at polymtl.ca) wrote:
> (It seems LTTV can't let go of me...)
>
> I was trying to reinstall TMF, which includes the compilation of LTTV  
> with  "./configure --with-jni-interface". However, make was now getting  
> build errors:
>
> jni_interface.c: In function  
> ?Java_org_eclipse_linuxtools_lttng_jni_JniMarkerField_ltt_1getOffset?:
> jni_interface.c:1005: error: ?struct marker_field? has no member named  
> ?offset?
> jni_interface.c: In function  
> ?Java_org_eclipse_linuxtools_lttng_jni_JniMarkerField_ltt_1getSize?:
> jni_interface.c:1012: error: ?struct marker_field? has no member named  
> ?size?
> jni_interface.c: In function  
> ?Java_org_eclipse_linuxtools_lttng_jni_JniMarkerField_ltt_1printMarkerField?:
> jni_interface.c:1049: error: ?struct marker_field? has no member named  
> ?offset?
> jni_interface.c:1050: error: ?struct marker_field? has no member named  
> ?size?
> jni_interface.c: In function  
> ?Java_org_eclipse_linuxtools_lttng_jni_JniParser_ltt_1getParsedData?:
> jni_interface.c:1134: error: ?struct marker_field? has no member named  
> ?offset?
>
>
>
> Me and Michael were getting the same problem. Sun-java,  openjdk  gcj so  
> were all giving the same errors. We ended up doing a git bisect, which  
> gave the following commit as being responsible:
>
> 1184dc37d4cee465b9888fcec352c4ebe86d4246 is the first bad commit
> commit 1184dc37d4cee465b9888fcec352c4ebe86d4246
> Author: Mathieu Desnoyers <mathieu.desnoyers at polymtl.ca>
> Date:   Fri Aug 20 12:02:42 2010 -0400
>
>     ltt traceread: fix offsets calculation, should be per tracefile
>
>     Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers at efficios.com>
>
> :040000 040000 b655cf92cab4b1a11f4000e27663426da1e1d1dd  
> 4e660bf0e8d8ad2ff0262e1c3223490d3f400178 M    ltt
>
>
> I'll look into it this afternoon, but I suppose the changes in that  
> commit were made for a reason, so I'm not too confident touching it.

Yeah, the library should be the only one knowing about the struct marker
offset/size fields, this is why I renamed them. The problem is that the
validity of this information is only while a given event is read. As
soon as the application reads events with same ID in other tracefiles
belonging to the same trace, it can overwrite the marker fields
offsets/sizes. This was causing a bug in LTTV.

The application (lttv/tmf) should use the proper interface to access the
current event fields/offsets: ltt_event_field().

Thanks,

Mathieu

>
> Thanks,
> Alexandre
>
>
> ps. On a side note, it seems building liblttvtraceread with OpenJDK  
> still works with TMF, so there might be hope for a liblttvtraceread-jni  
> package after all...
>
> _______________________________________________
> ltt-dev mailing list
> ltt-dev at lists.casi.polymtl.ca
> http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev

-- 
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com

[ltt-dev] LTTV BUG: Recent upgrades broke the JNI interface

[Alexandre Montplaisir]

On 10-09-08 11:47 AM, Mathieu Desnoyers wrote:
> * Alexandre Montplaisir (alexandre.montplaisir at polymtl.ca) wrote:
>> (It seems LTTV can't let go of me...)
>>
>> I was trying to reinstall TMF, which includes the compilation of LTTV
>> with  "./configure --with-jni-interface". However, make was now getting
>> build errors:
>>
>> jni_interface.c: In function
>> ?Java_org_eclipse_linuxtools_lttng_jni_JniMarkerField_ltt_1getOffset?:
>> jni_interface.c:1005: error: ?struct marker_field? has no member named
>> ?offset?
>> jni_interface.c: In function
>> ?Java_org_eclipse_linuxtools_lttng_jni_JniMarkerField_ltt_1getSize?:
>> jni_interface.c:1012: error: ?struct marker_field? has no member named
>> ?size?
>> jni_interface.c: In function
>> ?Java_org_eclipse_linuxtools_lttng_jni_JniMarkerField_ltt_1printMarkerField?:
>> jni_interface.c:1049: error: ?struct marker_field? has no member named
>> ?offset?
>> jni_interface.c:1050: error: ?struct marker_field? has no member named
>> ?size?
>> jni_interface.c: In function
>> ?Java_org_eclipse_linuxtools_lttng_jni_JniParser_ltt_1getParsedData?:
>> jni_interface.c:1134: error: ?struct marker_field? has no member named
>> ?offset?
>>
>>
>>
>> Me and Michael were getting the same problem. Sun-java,  openjdk  gcj so
>> were all giving the same errors. We ended up doing a git bisect, which
>> gave the following commit as being responsible:
>>
>> 1184dc37d4cee465b9888fcec352c4ebe86d4246 is the first bad commit
>> commit 1184dc37d4cee465b9888fcec352c4ebe86d4246
>> Author: Mathieu Desnoyers<mathieu.desnoyers at polymtl.ca>
>> Date:   Fri Aug 20 12:02:42 2010 -0400
>>
>>      ltt traceread: fix offsets calculation, should be per tracefile
>>
>>      Signed-off-by: Mathieu Desnoyers<mathieu.desnoyers at efficios.com>
>>
>> :040000 040000 b655cf92cab4b1a11f4000e27663426da1e1d1dd
>> 4e660bf0e8d8ad2ff0262e1c3223490d3f400178 M    ltt
>>
>>
>> I'll look into it this afternoon, but I suppose the changes in that
>> commit were made for a reason, so I'm not too confident touching it.
> Yeah, the library should be the only one knowing about the struct marker
> offset/size fields, this is why I renamed them. The problem is that the
> validity of this information is only while a given event is read. As
> soon as the application reads events with same ID in other tracefiles
> belonging to the same trace, it can overwrite the marker fields
> offsets/sizes. This was causing a bug in LTTV.
>
> The application (lttv/tmf) should use the proper interface to access the
> current event fields/offsets: ltt_event_field().

Hmm ok. After some digging in the JNI code (ouch), I found out the above 
2 errors come from simple Get methods that aren't even used anywhere in 
TMF. However, another error comes up because the "->offset" field is 
also used elsewhere in their parser code.

You don't want a patch that makes the JNI functions access 
"marker_field->_offset", do you? I can carry it out-of-tree to restore 
the previous functionality (and compilability (is that a word?)) for 
TMF, until they change their parser methods, since they'll probably get 
hit by the same bug as LTTV.

Cheers,
Alexandre

> Thanks,
>
> Mathieu
>
>> Thanks,
>> Alexandre
>>
>>
>> ps. On a side note, it seems building liblttvtraceread with OpenJDK
>> still works with TMF, so there might be hope for a liblttvtraceread-jni
>> package after all...
>>
>> _______________________________________________
>> ltt-dev mailing list
>> ltt-dev at lists.casi.polymtl.ca
>> http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev

[ltt-dev] LTTV BUG: Recent upgrades broke the JNI interface

[Mathieu Desnoyers]

* Alexandre Montplaisir (alexandre.montplaisir at polymtl.ca) wrote:
>
>
> On 10-09-08 11:47 AM, Mathieu Desnoyers wrote:
>> * Alexandre Montplaisir (alexandre.montplaisir at polymtl.ca) wrote:
>>> (It seems LTTV can't let go of me...)
>>>
>>> I was trying to reinstall TMF, which includes the compilation of LTTV
>>> with  "./configure --with-jni-interface". However, make was now getting
>>> build errors:
>>>
>>> jni_interface.c: In function
>>> ?Java_org_eclipse_linuxtools_lttng_jni_JniMarkerField_ltt_1getOffset?:
>>> jni_interface.c:1005: error: ?struct marker_field? has no member named
>>> ?offset?
>>> jni_interface.c: In function
>>> ?Java_org_eclipse_linuxtools_lttng_jni_JniMarkerField_ltt_1getSize?:
>>> jni_interface.c:1012: error: ?struct marker_field? has no member named
>>> ?size?
>>> jni_interface.c: In function
>>> ?Java_org_eclipse_linuxtools_lttng_jni_JniMarkerField_ltt_1printMarkerField?:
>>> jni_interface.c:1049: error: ?struct marker_field? has no member named
>>> ?offset?
>>> jni_interface.c:1050: error: ?struct marker_field? has no member named
>>> ?size?
>>> jni_interface.c: In function
>>> ?Java_org_eclipse_linuxtools_lttng_jni_JniParser_ltt_1getParsedData?:
>>> jni_interface.c:1134: error: ?struct marker_field? has no member named
>>> ?offset?
>>>
>>>
>>>
>>> Me and Michael were getting the same problem. Sun-java,  openjdk  gcj so
>>> were all giving the same errors. We ended up doing a git bisect, which
>>> gave the following commit as being responsible:
>>>
>>> 1184dc37d4cee465b9888fcec352c4ebe86d4246 is the first bad commit
>>> commit 1184dc37d4cee465b9888fcec352c4ebe86d4246
>>> Author: Mathieu Desnoyers<mathieu.desnoyers at polymtl.ca>
>>> Date:   Fri Aug 20 12:02:42 2010 -0400
>>>
>>>      ltt traceread: fix offsets calculation, should be per tracefile
>>>
>>>      Signed-off-by: Mathieu Desnoyers<mathieu.desnoyers at efficios.com>
>>>
>>> :040000 040000 b655cf92cab4b1a11f4000e27663426da1e1d1dd
>>> 4e660bf0e8d8ad2ff0262e1c3223490d3f400178 M    ltt
>>>
>>>
>>> I'll look into it this afternoon, but I suppose the changes in that
>>> commit were made for a reason, so I'm not too confident touching it.
>> Yeah, the library should be the only one knowing about the struct marker
>> offset/size fields, this is why I renamed them. The problem is that the
>> validity of this information is only while a given event is read. As
>> soon as the application reads events with same ID in other tracefiles
>> belonging to the same trace, it can overwrite the marker fields
>> offsets/sizes. This was causing a bug in LTTV.
>>
>> The application (lttv/tmf) should use the proper interface to access the
>> current event fields/offsets: ltt_event_field().
>
> Hmm ok. After some digging in the JNI code (ouch), I found out the above  
> 2 errors come from simple Get methods that aren't even used anywhere in  
> TMF. However, another error comes up because the "->offset" field is  
> also used elsewhere in their parser code.

I renamed the field to ensure that we don't get this bug from any 
interface. I'm glad I did! :-)

>
> You don't want a patch that makes the JNI functions access  
> "marker_field->_offset", do you? I can carry it out-of-tree to restore  
> the previous functionality (and compilability (is that a word?)) for  
> TMF, until they change their parser methods, since they'll probably get  
> hit by the same bug as LTTV.

Please don't do buggy workarounds at the library level to leave TMF
causy with its current bugs please. They must fix their app to upgrade
to the newer library version, period. I'm afraid we cannot release the
TMF package until they do.

Thanks,

Mathieu

>
> Cheers,
> Alexandre
>
>> Thanks,
>>
>> Mathieu
>>
>>> Thanks,
>>> Alexandre
>>>
>>>
>>> ps. On a side note, it seems building liblttvtraceread with OpenJDK
>>> still works with TMF, so there might be hope for a liblttvtraceread-jni
>>> package after all...
>>>
>>> _______________________________________________
>>> ltt-dev mailing list
>>> ltt-dev at lists.casi.polymtl.ca
>>> http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
>

-- 
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com

[ltt-dev] LTTV BUG: Recent upgrades broke the JNI interface

[Alexandre Montplaisir]

>> You don't want a patch that makes the JNI functions access
>> "marker_field->_offset", do you? I can carry it out-of-tree to restore
>> the previous functionality (and compilability (is that a word?)) for
>> TMF, until they change their parser methods, since they'll probably get
>> hit by the same bug as LTTV.
> Please don't do buggy workarounds at the library level to leave TMF
> causy with its current bugs please. They must fix their app to upgrade
> to the newer library version, period. I'm afraid we cannot release the
> TMF package until they do.
>
> Thanks,
>
> Mathieu

"Your package is now uploading..."
Ctrl-C, Ctrl-C...

But still, don't you think a mostly working app with a "KNOWN BUGS:" 
disclaimer is better than a completely non-working one? I guess they can 
use an older version, which isn't much better.

Matthew: How long do you think it'd take to get fixed? It will require 
adjustments both in the jni_interface.c and the JniParser.java code in 
TMF, if I remember right.

Cheers,
Alexandre

>> Cheers,
>> Alexandre
>>
>>> Thanks,
>>>
>>> Mathieu
>>>

[ltt-dev] LTTV BUG: Recent upgrades broke the JNI interface

[Mathieu Desnoyers]

* Alexandre Montplaisir (alexandre.montplaisir at polymtl.ca) wrote:
>
>>> You don't want a patch that makes the JNI functions access
>>> "marker_field->_offset", do you? I can carry it out-of-tree to restore
>>> the previous functionality (and compilability (is that a word?)) for
>>> TMF, until they change their parser methods, since they'll probably get
>>> hit by the same bug as LTTV.
>> Please don't do buggy workarounds at the library level to leave TMF
>> causy with its current bugs please. They must fix their app to upgrade
>> to the newer library version, period. I'm afraid we cannot release the
>> TMF package until they do.
>>
>> Thanks,
>>
>> Mathieu
>
> "Your package is now uploading..."
> Ctrl-C, Ctrl-C...
>
> But still, don't you think a mostly working app with a "KNOWN BUGS:"  
> disclaimer is better than a completely non-working one? I guess they can  
> use an older version, which isn't much better.

Leave TMF with the old version until they adapt then.

And common.. this is going to take a jiffy to fix. Why has this not been
done yet ? The new library has been out for a few weeks already.

Thanks,

Mathieu

>
> Matthew: How long do you think it'd take to get fixed? It will require  
> adjustments both in the jni_interface.c and the JniParser.java code in  
> TMF, if I remember right.
>
> Cheers,
> Alexandre
>
>>> Cheers,
>>> Alexandre
>>>
>>>> Thanks,
>>>>
>>>> Mathieu
>>>>
>

-- 
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com

[ltt-dev] LTTV BUG: Recent upgrades broke the JNI interface

[Matthew Khouzam]

On 10-09-08 05:47 PM, Mathieu Desnoyers wrote:
> * Alexandre Montplaisir (alexandre.montplaisir at polymtl.ca) wrote:
>    
>>      
>>>> You don't want a patch that makes the JNI functions access
>>>> "marker_field->_offset", do you? I can carry it out-of-tree to restore
>>>> the previous functionality (and compilability (is that a word?)) for
>>>> TMF, until they change their parser methods, since they'll probably get
>>>> hit by the same bug as LTTV.
>>>>          
>>> Please don't do buggy workarounds at the library level to leave TMF
>>> causy with its current bugs please. They must fix their app to upgrade
>>> to the newer library version, period. I'm afraid we cannot release the
>>> TMF package until they do.
>>>
>>> Thanks,
>>>
>>> Mathieu
>>>        
>> "Your package is now uploading..."
>> Ctrl-C, Ctrl-C...
>>
>> But still, don't you think a mostly working app with a "KNOWN BUGS:"
>> disclaimer is better than a completely non-working one? I guess they can
>> use an older version, which isn't much better.
>>      
> Leave TMF with the old version until they adapt then.
>
> And common.. this is going to take a jiffy to fix. Why has this not been
> done yet ? The new library has been out for a few weeks already.
>    

The main reason is that no-one tested the latest and greatest version of 
libtraceread for the moment. We are currently working on narowing the 
gap with lttv on all versions of the library. That being said, a patch 
on TMF's side will be available soonish.

Matthew

> Thanks,
>
> Mathieu
>
>    
>> Matthew: How long do you think it'd take to get fixed? It will require
>> adjustments both in the jni_interface.c and the JniParser.java code in
>> TMF, if I remember right.
>>
>> Cheers,
>> Alexandre
>>
>>      
>>>> Cheers,
>>>> Alexandre
>>>>
>>>>          
>>>>> Thanks,
>>>>>
>>>>> Mathieu
>>>>>
>>>>>            
>>      
>    

[ltt-dev] LTTV BUG: Recent upgrades broke the JNI interface

[Mathieu Desnoyers]

* Matthew Khouzam (matthew.khouzam at ericsson.com) wrote:
>
>
> On 10-09-08 05:47 PM, Mathieu Desnoyers wrote:
>> * Alexandre Montplaisir (alexandre.montplaisir at polymtl.ca) wrote:
>>    
>>>      
>>>>> You don't want a patch that makes the JNI functions access
>>>>> "marker_field->_offset", do you? I can carry it out-of-tree to restore
>>>>> the previous functionality (and compilability (is that a word?)) for
>>>>> TMF, until they change their parser methods, since they'll probably get
>>>>> hit by the same bug as LTTV.
>>>>>          
>>>> Please don't do buggy workarounds at the library level to leave TMF
>>>> causy with its current bugs please. They must fix their app to upgrade
>>>> to the newer library version, period. I'm afraid we cannot release the
>>>> TMF package until they do.
>>>>
>>>> Thanks,
>>>>
>>>> Mathieu
>>>>        
>>> "Your package is now uploading..."
>>> Ctrl-C, Ctrl-C...
>>>
>>> But still, don't you think a mostly working app with a "KNOWN BUGS:"
>>> disclaimer is better than a completely non-working one? I guess they can
>>> use an older version, which isn't much better.
>>>      
>> Leave TMF with the old version until they adapt then.
>>
>> And common.. this is going to take a jiffy to fix. Why has this not been
>> done yet ? The new library has been out for a few weeks already.
>>    
>
> The main reason is that no-one tested the latest and greatest version of  
> libtraceread for the moment. We are currently working on narowing the  
> gap with lttv on all versions of the library. That being said, a patch  
> on TMF's side will be available soonish.

That's great, thanks !

Mathieu

>
> Matthew
>
>> Thanks,
>>
>> Mathieu
>>
>>    
>>> Matthew: How long do you think it'd take to get fixed? It will require
>>> adjustments both in the jni_interface.c and the JniParser.java code in
>>> TMF, if I remember right.
>>>
>>> Cheers,
>>> Alexandre
>>>
>>>      
>>>>> Cheers,
>>>>> Alexandre
>>>>>
>>>>>          
>>>>>> Thanks,
>>>>>>
>>>>>> Mathieu
>>>>>>
>>>>>>            
>>>      
>>    
>
> _______________________________________________
> ltt-dev mailing list
> ltt-dev at lists.casi.polymtl.ca
> http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
>

-- 
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com