Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[hyades-dev] M10 checkin defects for committer vote



These are the defect fixes we have in hand and intend commit drop late
Wednesday for Thursdays driver.

Defect list.  Specifics listed below in the same order
bugzilla_62317
bugzilla_63902
bugzilla_62577
bugzilla_60642
bugzilla_63843
bugzilla_57462
bugzilla_60633


Bugzilla defect 62317: https://bugs.eclipse.org/bugs/show_bug.cgi?id=62317

Rational: The generic log adapter may have configuration files deployed as
many different sub-configurations of the remote data collection packaging.
There needs to be a mechanism by which we can override the relative
directory where these configuration files are located based upon the
sub-configuration which has provided the log file support.

Test Plan:  This fix has been tested on all of the supported platforms.  It
has been tested with two different sub-configurations.  A full regression
will be ran on the Thursday build.

Risk Assessment:  There is an additional field required as part of the log
file import extension point to specify the sub-configuration that contains
the log files.  Without this fix we cannot locate configuration files
provided by extenders of Hyades.


Bugzilla defect 63902: https://bugs.eclipse.org/bugs/show_bug.cgi?id=63902

Rational: Dump files generated as part of the optimized heap dump
capabilities in the profiling agent do not provide the workbench the proper
name of the dump files when generated on iSeries.  This is because the file
names on the operating system are EBCIDIC and need to be converted to ASCII
before being sent to the workbench.  The code change is isolated to only
iSeries machines.

Test Plan:  This fix has been tested on iSeries.  It will be regression
tested on Thursdays driver.

Risk Assessment: Without this fix we will not be able to retrieve optimized
heap dumps on iSeries.  The risk of regression is effectively non-existant
as this is only a iSeries fix and the fix is limited  to a simple system
call to do the conversion.


Bugzilla defect 62577: https://bugs.eclipse.org/bugs/show_bug.cgi?id=62577

Rational:  The profiling agent may run in 'full' mode, measuring all memory
and execution behaviour, when it was desired for it to measure nothing.  It
is desirable to completely disable the measurement of the Java application
when extenders have provided data collection capabilities, and wish to be
able to only collect that extended behaviour and none of the Hyades
provided measurement capabilities.

Test Plan:  This has been unit tested and will be regression tested against
all platforms using the Thursday driver.

Risk Assessment:  The opportunity for regression are minimal here.


Bugzilla defect 60642: https://bugs.eclipse.org/bugs/show_bug.cgi?id=60642

Rational:  When profiling in standalone file no error conditions are
reported to the user.  In all other modes error messages are routed through
to the data collection central log.  Severe errors should be reported to
the user to assist in the diagnosis of problems in standalone mode.  This
will be done through stderr.

Test Plan:  This has been unit tested and will be regression tested against
all platforms using the Thursday driver.

Risk Assessment:  The opportunity for regression are minimal.  There is the
possibility the user will now be presented with stderr test in the console
which is not generated as part of the application under test.  This will
only occur in severe error conditions and is analogous to many console
programs.


Bugzilla defect 63843: https://bugs.eclipse.org/bugs/show_bug.cgi?id=63843

Rational:  Managing duplicate Guids across multiple processes can result in
a tight infinite loop when one process exits prematurely whilst negotiating
its seed.  There are a couple of error conditions that can occur
negotiating the seed to ensure uniqueness of guids across processes.  We
need to ensure that the state is well defined when we exit our seed
resolution and we also need to ensure that we can recover from other
processes that have corrupted the seed negotiation mechanism due to
untimely exit.  This fix provides some additional error handling to enure
that the state is well defined at the end of the negotiation.  It also
provided a tight spin lock that can force a cleanup of the negotiation
mechanism as part of error recovery.

Test Plan:  This has been unit tested and will be regression tested against
all platforms using the Thursday driver.

Risk Assessment:  The algorithm is unusable as is.  Without the fix it is
possible to loop infinitely when other processes have corrupted the
negotiation.   The unfortunate side-effect is that the tight spin can hurt
seeding performance but this should not be the normal behaviour.

Bugzilla defect 57462: https://bugs.eclipse.org/bugs/show_bug.cgi?id=57462

Rational:  Different environments that are creating Common Base Events will
have security requirements for managing who can manipulate the static
information or properties that are used to generate Common Base Event
information.  Examples are: J2EE environments need to control content is
restricted to current web applications only,  users can override system
properties, etc.   We will remove all system property configuration
capabilities to circumvent malicious code from overriding system
properties.  As for controlling access to the event factories, we need to
back out some of the security code we have introduced here as it is to
cumbersome to manage in its current state.  We will rely upon runtime
environments to impose their own security model.

Test Plan:  This has been unit tested and will be regression tested against
all platforms using the Thursday driver.

Risk Assessment:   There is a behaviour change in the specialization of the
event factory we have provided as we are removing the system property
capabilities.  The code change is straight forward and the opportunity for
regression is minimal.

Bugzilla defect 60663: https://bugs.eclipse.org/bugs/show_bug.cgi?id=60663

Rational:  There are issues with certain JVM's having defects in their
JVMPI implementations that cause the JVM to catastrophically fail when we
exercise the broken code.  It is desirable to be able to determine exactly
what JVM we are running against so we can circumvent the problems before
they result in catastrophic failure.

Test Plan:  This has been unit tested against all platforms and will be
regression tested against all platforms using the Thursday driver.

Risk Assessment:   This change requires an addition of a JNI call into the
JVM_INIT_DONE event of the profiler to query the JVM for its
version/provider details.  You need to be careful when calling JNI from
with JVMPI events as they are not guaranteed to be thread safe in all
conditions (ie. making calls in the wrong events can cause you grief).  At
the time JVM_INIT_DONE is called JNI calls should be completely safe and we
have confirmed with at least one JVM provider that this will be fine.





Richard K. Duggan
Problem Determination Enablement
IBM Toronto Laboratory
External: 905-413-2396
Internal: 969-2396



Back to the top