From: compudj@krystal.dyndns.org (Mathieu Desnoyers)
Subject: [ltt-dev] LTTV BUG: Recent upgrades broke the JNI interface
Date: Wed, 8 Sep 2010 17:09:28 -0400 [thread overview]
Message-ID: <20100908210928.GA9441@Krystal> (raw)
In-Reply-To: <4C87D9A2.30204@polymtl.ca>
* 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
next prev parent reply other threads:[~2010-09-08 21:09 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-08 15:31 Alexandre Montplaisir
2010-09-08 15:47 ` Mathieu Desnoyers
2010-09-08 18:44 ` Alexandre Montplaisir
2010-09-08 21:09 ` Mathieu Desnoyers [this message]
2010-09-08 21:42 ` Alexandre Montplaisir
2010-09-08 21:47 ` Mathieu Desnoyers
2010-09-10 19:37 ` Matthew Khouzam
2010-09-11 14:58 ` Mathieu Desnoyers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100908210928.GA9441@Krystal \
--to=compudj@krystal.dyndns.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox