[testing] M4 candidate (r603534) testing status.

14 Message(s) by 9 Author(s) originally posted in harmony developer java

From: Stepan Mishura

Date: Friday, December 14, 2007

Hi,

Please see testing

<testing> The process of exercising a product to identify
	differences between expected and actual behaviour.  Typically
	testing is bottom-up: {unit testing} and {integration testing}
	by developers, {system testing} by testers, and {user
	acceptance testing} by users.

	{Test coverage} attempts to assess how complete a test has
	been.

	2. The second stage in a {generate and test} search
	{algorithm}.

	[{Jargon File}]

	(2003-09-24)

status[1] for r603534 below.
Note to my comments:
- I marked tests as regression

1. <mathematics> A mathematical method where an {empirical
	function} is derived from a set of experimental data.

	2. {regression testing}.

	(1995-03-14)

if they passed on M3 [2]
- I question tests as intermittent if they passed on the previous
snapshot (r603433) [3]
- There are some tests that failed on M3 too. (move them to the exclude lis=
ts?)
- Not all failure

The inability of a system or system component to perform a
	required function within specified limits.  A failure may be
	produced when a {fault} is encountered.

	(1996-05-13)

s have JIRA issue assigned so please help me to find
related JIRA number (if there is any).

All comments and clarifications are greatly appreciated!

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D
We've the next suites failed on the snapshot.

* Eclipse Unit Tests 3.3
- Linux

<operating system> ("Linus Unix") /li'nuks/ (but see below)
	An implementation of the {Unix} {kernel} originally written
	from scratch with no proprietary code.

	The kernel runs on {Intel} and {Alpha} hardware in the general
	release, with {SPARC}, {PowerPC}, {MIPS}, {ARM}, {Amiga},
	{Atari}, and {SGI} in active development.  The SPARC, PowerPC,
	ARM, {PowerMAC} - {OSF}, and 68k ports all support {shells},
	{X} and {networking}.  The Intel and SPARC versions have
	reliable {symmetric multiprocessing}.

	Work on the kernel is coordinated by Linus Torvalds, who holds
	the copyright on a large part of it.  The rest of the
	copyright is held by a large number of other contributors (or
	their employers).  Regardless of the copyright ownerships, the
	kernel as a whole is available under the {GNU} {General Public
	License}.  The GNU project supports Linux as its kernel until
	the research {Hurd} kernel is completed.

	This kernel would be no use without {application programs}.
	The GNU project has provided large numbers of quality tools,
	and together with other {public domain} software it is a rich
	Unix environment.  A compilation of the Linux kernel and these
	tools is known as a Linux distribution.  Compatibility modules
	and/or {emulators} exist for dozens of other computing
	environments.

	The kernel version numbers are significant: the odd numbered
	series (e.g. 1.3.xx) is the development (or beta) kernel which
	evolves very quickly.  Stable (or release) kernels have even
	major version numbers (e.g. 1.2.xx).

	There is a lot of commercial support for and use of Linux,
	both by hardware companies such as {Digital}, {IBM}, and
	{Apple} and numerous smaller network and integration
	specialists.  There are many commercially supported
	distributions which are generally entirely under the GPL.  At
	least one distribution vendor guarantees {Posix} compliance.
	Linux is particularly popular for {Internet Service
	Providers}, and there are ports to both parallel
	supercomputers and {embedded} {microcontrollers}.  {Debian} is
	one popular {open source} distribution.

	The pronunciation of "Linux" has been a matter of much debate.
	Many, including Torvalds, insist on the short I pronunciation
	/li'nuks/ because "Linus" has an /ee/ sound in Swedish
	(Linus's family is part of Finland's 6% ethnic-Swedish
	minority) and Linus considers English short /i/ to be closer
	to /ee/ than English long /i:/ dipthong.  This is consistent
	with the short I in words like "linen".  This doesn't stop
	others demanding a long I /li:'nuks/ following the english
	pronunciation of "Linus" and "minus".  Others say /li'niks/
	following {Minix}, which Torvalds was working on before Linux.

	{More on pronunciation
	(http://www.foldoc.org/pub/linux-pronunciation)}.

	{LinuxHQ (http://www.linuxhq.com/)}.  {slashdot
	(http://slashdot.org/)}.  {freshmeat (http://freshmeat.net/)}.
	{Woven Goods (http://www.fokus.gmd.de/linux/)}.  {Linux
	Gazette (http://www.ssc.com/lg)}.

	{funet Linux Archive (ftp://ftp.funet.fi/pub/Linux)}, {US
	mirror (ftp://sunsite.unc.edu/pub/Linux/)}, {UK Mirror
	(ftp://sunsite.doc.ic.ac.uk/packages/Linux/)}.

	(2000-06-09)

_x86

<processor> (x86) One of the family of {Intel}
	{microprocessors} including the {Intel 80186}, {Intel 80286},
	{Intel 80386}, {Intel 486}, in a more general sense also
	{Intel 8086}, {Pentium}, {Pentium Pro}, and {Pentium II}.

	The abbreviation "x86" also includes compatible processors,
	e.g. from {Cyrix} or {AMD}.

	(2004-02-27)

: 4 failures
- Windows

<operating system> See {Microsoft Windows}, {Windows NT}.

	(1997-11-23)

_x86: pass rate 96.92%
- Linux_x86_64: pass rate 95.29%

Would be nice to get failures evaluation

<programming> 1. Converting an expression into a value using
	some {reduction strategy}.

	2. The process of examining a system or system component to
	determine the extent to which specified properties are
	present.

	(1996-05-13)

.
We definitely improved stability of the Eclipse Unit Test suite since
M3 (Thanks to Vladimir Beliaev).
But the are still some issues such as intermittent suite crash

1. A sudden, usually drastic failure.  Most often said of the
	{system}, especially of magnetic disk drives (the term
	originally described what happened when the air gap of a hard
	disk collapses).  "Three {lusers} lost their files in last
	night's disk crash."  A disk crash that involves the
	read/write heads dropping onto the surface of the disks and
	scraping off the oxide may also be referred to as a "head
	crash", whereas the term "system crash" usually, though not
	always, implies that the operating system or other software
	was at fault.

	2. To fail suddenly.  "Has the system just crashed?"
	"Something crashed the OS!" See {down}.  Also used
	transitively to indicate the cause of the crash (usually a
	person or a program, or both).  "Those idiots playing
	{SPACEWAR} crashed the system."

	[{Jargon File}]

	(1994-12-01)

es (that
make me very upset).

* EGAx48:
- Linux_x86 & Linux_x86_64 : failed. (HARMONY-5250 / regression?)
- Windows_x86:
Still no status =96 the scenario causes CC host

1. <networking> A computer connected to a {network}.

	The term {node} includes devices such as routers and printers
	which would not normally be called "hosts".

	2. <communications> A computer to which one connects using a
	{terminal emulator}.

	(1995-02-16)

down

1. Not operating.  "The up escalator is down" is considered a
	humorous thing to say, and "The elevator is down" always
	means "The elevator isn't working" and never refers to what
	floor the elevator is on.  With respect to computers, this
	term has passed into the mainstream; the extension to other
	kinds of machine is still hackish.

	2. "go down" To stop functioning; usually said of the
	{system}.  The message from the {console} that every hacker
	hates to hear from the operator is "System going down in 5
	minutes".

	3. "take down", "bring down" To deactivate purposely, usually
	for repair work or {PM}.  "I'm taking the system down to work
	on that bug in the tape drive."  Occasionally one hears the
	word "down" by itself used as a verb in this sense.

	See {crash}; opposite: {up}.

	[{Jargon File}]

	(1994-12-07)

after run

<operating system, programming> The process of carrying out
	the {instructions} in a computer program by a computer.

	See also {dry run}.

	(1996-05-13)

ning
several hours.
Currently I can not figure out if this is the host's issue or
problem introduced by Harmony.* EHWA(GUI)
- Linux_x86 & Linux_x86_64 : failed.
The scenario is quite unstable. Most probably I will drop the
scenario in M5 from snapshot test and use only EHWA-API.* Functional:
F_KeyFactoryTest_01: regression on all platforms (HARMONY-4857)

- Linux_x86:
JComponent: intermittent?
- Linux_x86_64:
btest6353: fails on M3 too
- Windows_x86_64:
DataOutputStream, writeObjectReadObject0004, IfElse1, btest5717,
btest7214 : intermittent?
btest6353: fails on M3 too

* GUT:
ContainerTest, JAASSecurityTest - fail on all platforms
HARMONY-4895 says that this bug

<programming> An unwanted and unintended property of a program
	or piece of hardware, especially one that causes it to
	malfunction.  Antonym of {feature}.  E.g. "There's a bug in
	the editor: it writes things out backward."  The
	identification and removal of bugs in a program is called
	"{debugging}".

	Admiral {Grace Hopper} (an early computing pioneer better
	known for inventing {COBOL}) liked to tell a story in which a
	technician solved a {glitch} in the {Harvard Mark II machine}
	by pulling an actual insect out from between the contacts of
	one of its relays, and she subsequently promulgated {bug} in
	its hackish sense as a joke about the incident (though, as she
	was careful to admit, she was not there when it happened).
	For many years the logbook associated with the incident and
	the actual bug in question (a moth) sat in a display case at
	the Naval Surface Warfare Center (NSWC).  The entire story,
	with a picture of the logbook and the moth taped into it, is
	recorded in the "Annals of the History of Computing", Vol. 3,
	No. 3 (July 1981), pp. 285--286.

	The text of the log entry (from September 9, 1947), reads
	"1545 Relay #70 Panel F (moth) in relay.  First actual case of
	bug being found".  This wording establishes that the term was
	already in use at the time in its current specific sense - and
	Hopper herself reports that the term "bug" was regularly
	applied to problems in radar electronics during WWII.

	Indeed, the use of "bug" to mean an industrial defect was
	already established in Thomas Edison's time, and a more
	specific and rather modern use can be found in an electrical
	handbook from 1896 ("Hawkin's New Catechism of Electricity",
	Theo. Audel & Co.)  which says: "The term "bug" is used to a
	limited extent to designate any fault or trouble in the
	connections or working of electric apparatus."  It further
	notes that the term is "said to have originated in
	{quadruplex} telegraphy and have been transferred to all
	electric apparatus."

	The latter observation may explain a common folk etymology of
	the term; that it came from telephone company usage, in which
	"bugs in a telephone cable" were blamed for noisy lines.
	Though this derivation seems to be mistaken, it may well be a
	distorted memory of a joke first current among *telegraph*
	operators more than a century ago!

	Actually, use of "bug" in the general sense of a disruptive
	event goes back to Shakespeare!  In the first edition of
	Samuel Johnson's dictionary one meaning of "bug" is "A
	frightful object; a walking spectre"; this is traced to
	"bugbear", a Welsh term for a variety of mythological monster
	which (to complete the circle) has recently been reintroduced
	into the popular lexicon through fantasy {role-playing games}.

	In any case, in jargon the word almost never refers to
	insects.  Here is a plausible conversation that never actually
	happened:

	"There is a bug in this ant farm!"

	"What do you mean?  I don't see any ants in it."

	"That's the bug."

	[There has been a widespread myth that the original bug was
	moved to the Smithsonian, and an earlier version of this entry
	so asserted.  A correspondent who thought to check discovered
	that the bug was not there.  While investigating this in late
	1990, your editor discovered that the NSWC still had the bug,
	but had unsuccessfully tried to get the Smithsonian to accept
	it - and that the present curator of their History of
	American Technology Museum didn't know this and agreed that it
	would make a worthwhile exhibit.  It was moved to the
	Smithsonian in mid-1991, but due to space and money
	constraints has not yet been exhibited.  Thus, the process of
	investigating the original-computer-bug bug fixed it in an
	entirely unexpected way, by making the myth true!  - ESR]

	[{Jargon File}]

	(1999-06-29)

in Geronimo and not a regression.

- Linux_x86:
HARMONY-5302 - says that this a bug in tests (I do not understand
then why they passed on M3)
security\jaas\ConfigurationEntryTest
security\jaas\LoginKerberousNonGeronimoTest
security\jaas\LoginKerberousTest
security\jaas\LoginSQLTest
security\network\protocol\SubjectCarryingProtocolTest
security\remoting\jmx\RemoteLoginTest

- Linux_x86_64: 53 failures (11 on M3)
- Windows_x86_64: 22 failures (28 on M3)* JDKTools
- Windows_x86_64: 3 failures by TimeoutException.
Regression? I previously incorrectly reported that they are
intermittent. They stably fail on M4 builds.

* Reliability

Failed on x86 platforms but they also failed on M3
api.net.HttpConnectionTest (I wonder why HARMONY-5266 did not fixed it)
api.net.SingleConnectTest

- Linux_x86:

Regresions:
api.kernel.object.ObjectFinalizeTest
api.kernel.throwable.StackTraceExcptsTest
api.text.DecimalFormat_Locales
api.zip.ZipEntryIterateThreadingTest
api.zip.ZlibTest
vm.finalization.FinalizeThrowRestoreTest
vm.stack.StackUnwindTest

They also failed on M3:
api.nio.channels.file

<file system> An element of data storage in a {file system}.

	The history of computing is rich in varied kinds of files and
	{file systems}, whether ornate (e.g., {Macintosh file system}
	for a well-known case) or deficient (e.g., many simple
	pre-1980s file systems don't allow {directories}).

	However, the prototypical file has these characteristics:

	* It is a single sequence of bytes (but consider {Macintosh}
	{resource forks}).

	* It has a finite length, unlike, e.g. a {Unix} {device}.

	* It is stored in a {non-volatile storage} medium (but see
	{ramdrive}).

	* It exists (nominally) in a {directory}.

	* It has a name that it can be referred to by in file
	operations, possibly in combination with its {path}.

	Additionally, a file system may associate other information
	with a file, such as {permission} bits or other {file
	attributes}; timestamps for file creation, last revision, and
	last access; revision numbers (a` la VMS), and other kinds of
	{magic}.

	Compare: {document}.

	(1997-04-08)

channel.FileChannelMapTest
api.nio.channels.filechannel.MappedByteBufferForceTest
api.serialization.SerializableClassesTest

- Windows_x86

Regresions:
api.kernel.string.InternThreadingTest - regression
api.kernel.thread.Calculation.CalcTest
api.kernel.thread.RecursiveThreadTest
api.kernel.thread.StackTraceTest
api.kernel.thread.Synchronization
api.kernel.thread.ThreadArrayTest
api.kernel.threadgroup.EnumerateTest
api.net.DatagramTest
api.serialization.SerializableClassesTest
vm.stack.StackUnwindTest

- Linux_x86_64:

Regressions:
vm.classloading.ClassCastTest

* Stress

- Linux_x86:
StackUnwindingManyObjectsTests: 5 fails on M3 too (HARMONY-5158 /
test issue?)
Fragmentation, FragmentationFinalizer, FragmentationReference:
HARMONY-5159 (was not run during M3 so not regression)

- Windows_x86:
StackUnwindingManyObjectsTests: 5 fails on M3 too (HARMONY-5158 /
test issue?)
FragmentationReference: HARMONY-5159 (was not run during M3 so not
regression)

- Linux_x86_64:
jni.arguments,jni.arrays - fails on M3 too so not regression / HARMONY-=
????
MEMORY001, MEMORY003 - HARMONY-5047 (fails on M3 too so not regression)

- Windows_x86_64:
NotSynchThreads.ManyClasses - crash (HARMONY-5003), regression
Fragmentation, FragmentationFinalizer, FragmentationReference:
HARMONY-5159 (was not run during M3 so not regression)
gc.mem.MemoryTest3 - regression / HARMONY-????
jni.stack - fails on M3 too so not regression / HARMONY-????
EVENT014- crash (HARMONY-????)/ regression
MEMORY001, MEMORY003 - HARMONY-5047 (fails on M3 too so not regression)
StressThreads12Test - crash (HARMONY-????)/ regression

* VTS VM
- Windows_x86:
dstore_20701 - intermittent?

[1] http://people.apache.org/~mloenko/snapshot_testing/script/r603534/index=
.html
[2] http://people.apache.org/~mloenko/snapshot_testing/script/r580985/index=
.html
[3] http://people.apache.org/~mloenko/snapshot_testing/script/r603433/index=
.html

Thanks,
Stepan Mishura
Intel Enterprise Solutions Software Division

From: Andrey Pavlenko

Date: Friday, December 14, 2007

------=_Part_128_11890456.1197623747369

Content-Disposition: inline

UGxlYXNlIHNlZSBteSBldmFsdWF0aW9uIG9mIHRoZSBmdW5jdGlvbmFsIHRlc3Qgc3VpdGUgZmFp
bHVyZXMgYmVsb3cuCgpMaW51eF94ODYKamF2YS5zZWN1cml0eS5GX0tleUZhY3RvcnlUZXN0XzAx
ICAgICAgICAgICAgIyBIQVJNT05ZLTQ4NTcgLSByZWdyZXNzaW9uCmludHJvZHVjZWQgaW4gTTMu
IEJ1ZyBpbiB0aGlyZC1wYXJ0eSBjb21wb25lbnQsIHdvbid0IGJlIGZpeGVkIGluIE00LgpqYXZh
eC5zd2luZy5KQ29tcG9uZW50ICAgICAgICAgICAgIyBJbnRlcm1pdHRlbnQuIFRoZSB0ZXN0IGlz
IHVuc3RhYmxlCmJlY2F1c2UgaXQncyBzZW5zaXRpdmUgdG8gZW52aXJvbm1lbnQgLSBtb3VzZSBt
b3Rpb24sIHdpbmRvd3MgZm9jdXNpbmcsIGV0Yy4KCgpXaW5kb3dzX3g4NgpqYXZhLnNlY3VyaXR5
LkZfS2V5RmFjdG9yeVRlc3RfMDEgICAgICAgICAgICAjIEhBUk1PTlktNDg1NyAtIHJlZ3Jlc3Np
b24KaW50cm9kdWNlZCBpbiBNMy4gQnVnIGluIHRoaXJkLXBhcnR5IGNvbXBvbmVudCwgd29uJ3Qg
YmUgZml4ZWQgaW4gTTQuCgpMaW51eF94ODZfNjQKamF2YS5zZWN1cml0eS5GX0tleUZhY3RvcnlU
ZXN0XzAxICAgICAgICAgICAgIyBIQVJNT05ZLTQ4NTcgLSByZWdyZXNzaW9uCmludHJvZHVjZWQg
aW4gTTMuIEJ1ZyBpbiB0aGlyZC1wYXJ0eSBjb21wb25lbnQsIHdvbid0IGJlIGZpeGVkIGluIE00
LgpyZWcudm0uYnRlc3Q2MzUzICAgICAgICAgICAgIyBIYXMgYWx3YXlzIGJlZW4gZmFpbGluZyBv
biB4NjQuIExvb2tzIGxpa2UKdGVzdCBpc3N1ZS4KCk9uIDEyLzE0LzA3LCBTdGVwYW4gTWlzaHVy
YSA8c3RlcGFuLm1pc2h1cmFAZ21haWwuY29tPiB3cm90ZToKPgo+IEhpLAo+Cj4gUGxlYXNlIHNl
ZSB0ZXN0aW5nIHN0YXR1c1sxXSBmb3IgcjYwMzUzNCBiZWxvdy4KPiBOb3RlIHRvIG15IGNvbW1l
bnRzOgo+IC0gSSBtYXJrZWQgdGVzdHMgYXMgcmVncmVzc2lvbiBpZiB0aGV5IHBhc3NlZCBvbiBN
MyBbMl0KPiAtIEkgcXVlc3Rpb24gdGVzdHMgYXMgaW50ZXJtaXR0ZW50IGlmIHRoZXkgcGFzc2Vk
IG9uIHRoZSBwcmV2aW91cwo+IHNuYXBzaG90IChyNjAzNDMzKSBbM10KPiAtIFRoZXJlIGFyZSBz
b21lIHRlc3RzIHRoYXQgZmFpbGVkIG9uIE0zIHRvby4gKG1vdmUgdGhlbSB0byB0aGUgZXhjbHVk
ZQo+IGxpc3RzPykKPiAtIE5vdCBhbGwgZmFpbHVyZXMgaGF2ZSBKSVJBIGlzc3VlIGFzc2lnbmVk
IHNvIHBsZWFzZSBoZWxwIG1lIHRvIGZpbmQKPiByZWxhdGVkIEpJUkEgbnVtYmVyIChpZiB0aGVy
ZSBpcyBhbnkpLgo+Cj4gQWxsIGNvbW1lbnRzIGFuZCBjbGFyaWZpY2F0aW9ucyBhcmUgZ3JlYXRs
eSBhcHByZWNpYXRlZCEKPgo+ID09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09Cj4gV2UgaGF2ZSB0aGUgbmV4dCBzdWl0ZXMgZmFpbGVkIG9uIHRoZSBz
bmFwc2hvdC4KPgo+ICogRWNsaXBzZSBVbml0IFRlc3RzIDMuMwo+ICAgIC0gTGludXhfeDg2OiA0
IGZhaWx1cmVzCj4gICAgLSBXaW5kb3dzX3g4NjogcGFzcyByYXRlIDk2LjkyJQo+ICAgIC0gTGlu
dXhfeDg2XzY0OiBwYXNzIHJhdGUgOTUuMjklCj4KPiBXb3VsZCBiZSBuaWNlIHRvIGdldCBmYWls
dXJlcyBldmFsdWF0aW9uLgo+IFdlIGRlZmluaXRlbHkgaW1wcm92ZWQgc3RhYmlsaXR5IG9mIHRo
ZSBFY2xpcHNlIFVuaXQgVGVzdCBzdWl0ZSBzaW5jZQo+IE0zIChUaGFua3MgdG8gVmxhZGltaXIg
QmVsaWFldikuCj4gQnV0IHRoZSBhcmUgc3RpbGwgc29tZSBpc3N1ZXMgc3VjaCBhcyBpbnRlcm1p
dHRlbnQgc3VpdGUgY3Jhc2hlcyAodGhhdAo+IG1ha2UgbWUgdmVyeSB1cHNldCkuCj4KPiAqIEVH
QXg0ODoKPiAgICAtIExpbnV4X3g4NiAmIExpbnV4X3g4Nl82NCA6IGZhaWxlZC4gKEhBUk1PTlkt
NTI1MCAvIHJlZ3Jlc3Npb24/KQo+ICAgIC0gV2luZG93c194ODY6Cj4gICAgICAgU3RpbGwgbm8g
c3RhdHVzIOKAkyB0aGUgc2NlbmFyaW8gY2F1c2VzIENDIGhvc3QgZG93biBhZnRlciBydW5uaW5n
Cj4gc2V2ZXJhbCBob3Vycy4KPiAgICAgICBDdXJyZW50bHkgSSBjYW4gbm90IGZpZ3VyZSBvdXQg
aWYgdGhpcyBpcyB0aGUgaG9zdCdzIGlzc3VlIG9yCj4gcHJvYmxlbSBpbnRyb2R1Y2VkIGJ5IEhh
cm1vbnkuCj4KPgo+ICogRUhXQShHVUkpCj4gICAgLSBMaW51eF94ODYgJiBMaW51eF94ODZfNjQg
OiBmYWlsZWQuCj4gICAgVGhlIHNjZW5hcmlvIGlzIHF1aXRlIHVuc3RhYmxlLiBNb3N0IHByb2Jh
Ymx5IEknbGwgZHJvcCB0aGUKPiBzY2VuYXJpbyBpbiBNNSBmcm9tIHNuYXBzaG90IHRlc3QgYW5k
IHVzZSBvbmx5IEVIV0EtQVBJLgo+Cj4KPiAqIEZ1bmN0aW9uYWw6Cj4gICAgICAgRl9LZXlGYWN0
b3J5VGVzdF8wMTogcmVncmVzc2lvbiBvbiBhbGwgcGxhdGZvcm1zIChIQVJNT05ZLTQ4NTcpCj4K
PiAgIC0gTGludXhfeDg2Ogo+ICAgICAgIEpDb21wb25lbnQ6IGludGVybWl0dGVudD8KPiAgIC0g
TGludXhfeDg2XzY0Ogo+ICAgICAgIGJ0ZXN0NjM1MzogZmFpbHMgb24gTTMgdG9vCj4gICAtIFdp
bmRvd3NfeDg2XzY0Ogo+ICAgICAgIERhdGFPdXRwdXRTdHJlYW0sIHdyaXRlT2JqZWN0UmVhZE9i
amVjdDAwMDQsIElmRWxzZTEsIGJ0ZXN0NTcxNywKPiBidGVzdDcyMTQgOiBpbnRlcm1pdHRlbnQ/
Cj4gICAgICAgYnRlc3Q2MzUzOiBmYWlscyBvbiBNMyB0b28KPgo+ICogR1VUOgo+ICAgICBDb250
YWluZXJUZXN0LCBKQUFTU2VjdXJpdHlUZXN0IC0gZmFpbCBvbiBhbGwgcGxhdGZvcm1zCj4gICAg
ICAgSEFSTU9OWS00ODk1IHNheXMgdGhhdCB0aGlzIGJ1ZyBpbiBHZXJvbmltbyBhbmQgbm90IGEg
cmVncmVzc2lvbi4KPgo+ICAgLSBMaW51eF94ODY6Cj4gICAgIEhBUk1PTlktNTMwMiAtIHNheXMg
dGhhdCB0aGlzIGEgYnVnIGluIHRlc3RzIChJIGRvbid0IHVuZGVyc3RhbmQKPiB0aGVuIHdoeSB0
aGV5IHBhc3NlZCBvbiBNMykKPiAgICAgc2VjdXJpdHlcamFhc1xDb25maWd1cmF0aW9uRW50cnlU
ZXN0Cj4gICAgIHNlY3VyaXR5XGphYXNcTG9naW5LZXJiZXJvdXNOb25HZXJvbmltb1Rlc3QKPiAg
ICAgc2VjdXJpdHlcamFhc1xMb2dpbktlcmJlcm91c1Rlc3QKPiAgICAgc2VjdXJpdHlcamFhc1xM
b2dpblNRTFRlc3QKPiAgICAgc2VjdXJpdHlcbmV0d29ya1xwcm90b2NvbFxTdWJqZWN0Q2Fycnlp
bmdQcm90b2NvbFRlc3QKPiAgICAgc2VjdXJpdHlccmVtb3Rpbmdcam14XFJlbW90ZUxvZ2luVGVz
dAo+Cj4gICAtIExpbnV4X3g4Nl82NDogICA1MyBmYWlsdXJlcyAoMTEgb24gTTMpCj4gICAtIFdp
bmRvd3NfeDg2XzY0OiAyMiBmYWlsdXJlcyAoMjggb24gTTMpCj4KPgo+ICogSkRLVG9vbHMKPiAg
IC0gV2luZG93c194ODZfNjQ6IDMgZmFpbHVyZXMgYnkgVGltZW91dEV4Y2VwdGlvbi4KPiAgIFJl
Z3Jlc3Npb24/IEkgcHJldmlvdXNseSBpbmNvcnJlY3RseSByZXBvcnRlZCB0aGF0IHRoZXkgYXJl
Cj4gaW50ZXJtaXR0ZW50LiBUaGV5IHN0YWJseSBmYWlsIG9uIE00IGJ1aWxkcy4KPgo+ICogUmVs
aWFiaWxpdHkKPgo+ICAgICBGYWlsZWQgb24geDg2IHBsYXRmb3JtcyBidXQgdGhleSBhbHNvIGZh
aWxlZCBvbiBNMwo+ICAgICBhcGkubmV0Lkh0dHBDb25uZWN0aW9uVGVzdCAoSSB3b25kZXIgd2h5
IEhBUk1PTlktNTI2NiBkaWRuJ3QgZml4ZWQgaXQpCj4gICAgIGFwaS5uZXQuU2luZ2xlQ29ubmVj
dFRlc3QKPgo+ICAgLSBMaW51eF94ODY6Cj4KPiAgICAgUmVncmVzaW9uczoKPiAgICAgYXBpLmtl
cm5lbC5vYmplY3QuT2JqZWN0RmluYWxpemVUZXN0Cj4gICAgIGFwaS5rZXJuZWwudGhyb3dhYmxl
LlN0YWNrVHJhY2VFeGNwdHNUZXN0Cj4gICAgIGFwaS50ZXh0LkRlY2ltYWxGb3JtYXRfTG9jYWxl
cwo+ICAgICBhcGkuemlwLlppcEVudHJ5SXRlcmF0ZVRocmVhZGluZ1Rlc3QKPiAgICAgYXBpLnpp
cC5abGliVGVzdAo+ICAgICB2bS5maW5hbGl6YXRpb24uRmluYWxpemVUaHJvd1Jlc3RvcmVUZXN0
Cj4gICAgIHZtLnN0YWNrLlN0YWNrVW53aW5kVGVzdAo+Cj4gICAgIFRoZXkgYWxzbyBmYWlsZWQg
b24gTTM6Cj4gICAgIGFwaS5uaW8uY2hhbm5lbHMuZmlsZWNoYW5uZWwuRmlsZUNoYW5uZWxNYXBU
ZXN0Cj4gICAgIGFwaS5uaW8uY2hhbm5lbHMuZmlsZWNoYW5uZWwuTWFwcGVkQnl0ZUJ1ZmZlckZv
cmNlVGVzdAo+ICAgICBhcGkuc2VyaWFsaXphdGlvbi5TZXJpYWxpemFibGVDbGFzc2VzVGVzdAo+
Cj4gICAtIFdpbmRvd3NfeDg2Cj4KPiAgICAgUmVncmVzaW9uczoKPiAgICAgYXBpLmtlcm5lbC5z
dHJpbmcuSW50ZXJuVGhyZWFkaW5nVGVzdCAtIHJlZ3Jlc3Npb24KPiAgICAgYXBpLmtlcm5lbC50
aHJlYWQuQ2FsY3VsYXRpb24uQ2FsY1Rlc3QKPiAgICAgYXBpLmtlcm5lbC50aHJlYWQuUmVjdXJz
aXZlVGhyZWFkVGVzdAo+ICAgICBhcGkua2VybmVsLnRocmVhZC5TdGFja1RyYWNlVGVzdAo+ICAg
ICBhcGkua2VybmVsLnRocmVhZC5TeW5jaHJvbml6YXRpb24KPiAgICAgYXBpLmtlcm5lbC50aHJl
YWQuVGhyZWFkQXJyYXlUZXN0Cj4gICAgIGFwaS5rZXJuZWwudGhyZWFkZ3JvdXAuRW51bWVyYXRl
VGVzdAo+ICAgICBhcGkubmV0LkRhdGFncmFtVGVzdAo+ICAgICBhcGkuc2VyaWFsaXphdGlvbi5T
ZXJpYWxpemFibGVDbGFzc2VzVGVzdAo+ICAgICB2bS5zdGFjay5TdGFja1Vud2luZFRlc3QKPgo+
ICAgLSBMaW51eF94ODZfNjQ6Cj4KPiAgICAgUmVncmVzc2lvbnM6Cj4gICAgIHZtLmNsYXNzbG9h
ZGluZy5DbGFzc0Nhc3RUZXN0Cj4KPiAqIFN0cmVzcwo+Cj4gICAtIExpbnV4X3g4NjoKPiAgICAg
U3RhY2tVbndpbmRpbmdNYW55T2JqZWN0c1Rlc3RzOiA1IGZhaWxzIG9uIE0zIHRvbyAoSEFSTU9O
WS01MTU4IC8KPiB0ZXN0IGlzc3VlPykKPiAgICAgRnJhZ21lbnRhdGlvbiwgRnJhZ21lbnRhdGlv
bkZpbmFsaXplciwgRnJhZ21lbnRhdGlvblJlZmVyZW5jZToKPiBIQVJNT05ZLTUxNTkgKHdhc24n
dCBydW4gZHVyaW5nIE0zIHNvIG5vdCByZWdyZXNzaW9uKQo+Cj4gICAtIFdpbmRvd3NfeDg2Ogo+
ICAgICAgU3RhY2tVbndpbmRpbmdNYW55T2JqZWN0c1Rlc3RzOiA1IGZhaWxzIG9uIE0zIHRvbyAo
SEFSTU9OWS01MTU4IC8KPiB0ZXN0IGlzc3VlPykKPiAgICAgIEZyYWdtZW50YXRpb25SZWZlcmVu
Y2U6IEhBUk1PTlktNTE1OSAod2Fzbid0IHJ1biBkdXJpbmcgTTMgc28gbm90Cj4gcmVncmVzc2lv
bikKPgo+ICAgLSBMaW51eF94ODZfNjQ6Cj4gICAgIGpuaS5hcmd1bWVudHMsam5pLmFycmF5cyAt
IGZhaWxzIG9uIE0zIHRvbyBzbyBub3QgcmVncmVzc2lvbiAvCj4gSEFSTU9OWS0/Pz8/Cj4gICAg
IE1FTU9SWT

<java, graphics> (SWT) The {Eclipse Foundation}'s {framework}
	for developing {graphical user interfaces} in {Java}.  SWT is
	written in explicitly standard Java but uses the {Java Native
	Interface} to talk to a {platform}-native GUI library.  SWT is
	the third major attempt to give Java a decent GUI framework,
	following {AWT} and {Swing}.  Of the three, SWT is the most
	consistent with the native GUIs but its programming model is
	hard to port to non-Windows platforms.

	{Wikipedia (http://en.wikipedia.org/wiki/SWT)}.

	(2004-12-21)

AwMSwgTUVNT1JZMDAzIC0gSEFSTU9OWS01MDQ3IChmYWlscyBvbiBNMyB0b28gc28g
bm90Cj4gcmVncmVzc2lvbikKPgo+ICAgLSBXaW5kb3dzX3g4Nl82NDoKPiAgICAgTm90U3luY2hU
aHJlYWRzLk1hbnlDbGFzc2VzIC0gY3Jhc2ggKEhBUk1PTlktNTAwMyksIHJlZ3Jlc3Npb24KPiAg
ICAgRnJhZ21lbnRhdGlvbiwgRnJhZ21lbnRhdGlvbkZpbmFsaXplciwgRnJhZ21lbnRhdGlvblJl
ZmVyZW5jZToKPiBIQVJNT05ZLTUxNTkgKHdhc24ndCBydW4gZHVyaW5nIE0zIHNvIG5vdCByZWdy
ZXNzaW9uKQo+ICAgICBnYy5tZW0uTWVtb3J5VGVzdDMgLSByZWdyZXNzaW9uIC8gSEFSTU9OWS0/
Pz8/Cj4gICAgIGpuaS5zdGFjayAtIGZhaWxzIG9uIE0zIHRvbyBzbyBub3QgcmVncmVzc2lvbiAv
IEhBUk1PTlktPz8/Pwo+ICAgICBFVkVOVDAxNC0gY3Jhc2ggKEhBUk1PTlktPz8/PykvIHJlZ3Jl
c3Npb24KPiAgICAgTUVNT1JZMDAxLCBNRU1PUlkwMDMgLSBIQVJNT05ZLTUwNDcgKGZhaWxzIG9u
IE0zIHRvbyBzbyBub3QKPiByZWdyZXNzaW9uKQo+ICAgICBTdHJlc3NUaHJlYWRzMTJUZXN0IC0g
Y3Jhc2ggKEhBUk1PTlktPz8/PykvIHJlZ3Jlc3Npb24KPgo+ICogVlRTIFZNCj4gICAtIFdpbmRv
d3NfeDg2Ogo+ICAgICAgIGRzdG9yZV8yMDcwMSAtIGludGVybWl0dGVudD8KPgo+IFsxXQo+IGh0
dHA6Ly9wZW9wbGUuYXBhY2hlLm9yZy9+bWxvZW5rby9zbmFwc2hvdF90ZXN0aW5nL3NjcmlwdC9y
NjAzNTM0L2luZGV4Lmh0bWwKPiBbMl0KPiBodHRwOi8vcGVvcGxlLmFwYWNoZS5vcmcvfm1sb2Vu
a28vc25hcHNob3RfdGVzdGluZy9zY3JpcHQvcjU4MDk4NS9pbmRleC5odG1sCj4gWzNdCj4gaHR0
cDovL3Blb3BsZS5hcGFjaGUub3JnL35tbG9lbmtvL3NuYXBzaG90X3Rlc3Rpbmcvc2NyaXB0L3I2
MDM0MzMvaW5kZXguaHRtbAo+Cj4gVGhhbmtzLAo+IFN0ZXBhbiBNaXNodXJhCj4gSW50ZWwgRW50
ZXJwcmlzZSBTb2x1dGlvbnMgU29mdHdhcmUgRGl2aXNpb24KPgo=
------=_Part_128_11890456.1197623747369--

From: Xiao-Feng Li

Date: Friday, December 14, 2007

I saw this:

Reliability:
Linux_X86 regression:
vm.finalization.FinalizeThrowRestoreTest

I am not sure if anybody has early evaluation about it. If not, I
will create a JIRA for it.

Thanks,
xiaofeng

wrote in message:

Hi,
Please see testing status[1] for r603534 below.
Note to my comments:
- I marked tests as regression if they passed on M3 [2]
- I question tests as intermittent if they passed on the previous
snapshot (r603433) [3]
- There are some tests that failed on M3 too. (move them to the exclude l=
ists?)
- Not all failures have JIRA issue assigned so please help me to find
related JIRA number (if there is any).
All comments and clarifications are greatly appreciated!
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D

We have the next suites failed on the snapshot.
* Eclipse Unit Tests 3.3
- Linux_x86: 4 failures
- Windows_x86: pass rate 96.92%
- Linux_x86_64: pass rate 95.29%
Would be nice to get failures evaluation.
We definitely improved stability of the Eclipse Unit Test suite since
M3 (Thanks to Vladimir Beliaev).
But the are still some issues such as intermittent suite crashes (that
make me very upset).
* EGAx48:
- Linux_x86 & Linux_x86_64 : failed. (HARMONY-5250 / regression?)
- Windows_x86:
Still no status =96 the scenario causes CC host down after running
several hours.
Currently I can not figure out if this is the host's issue or
problem introduced by Harmony.
* EHWA(GUI)
- Linux_x86 & Linux_x86_64 : failed.
The scenario is quite unstable. Most probably I will drop the
scenario in M5 from snapshot test and use only EHWA-API.
* Functional:
F_KeyFactoryTest_01: regression on all platforms (HARMONY-4857)
- Linux_x86:
JComponent: intermittent?
- Linux_x86_64:
btest6353: fails on M3 too
- Windows_x86_64:
DataOutputStream, writeObjectReadObject0004, IfElse1, btest5717,
btest7214 : intermittent?
btest6353: fails on M3 too
* GUT:
ContainerTest, JAASSecurityTest - fail on all platforms
HARMONY-4895 says that this bug in Geronimo and not a regression.
- Linux_x86:
HARMONY-5302 - says that this a bug in tests (I do not understand
then why they passed on M3)
security\jaas\ConfigurationEntryTest
security\jaas\LoginKerberousNonGeronimoTest
security\jaas\LoginKerberousTest
security\jaas\LoginSQLTest
security\network\protocol\SubjectCarryingProtocolTest
security\remoting\jmx\RemoteLoginTest
- Linux_x86_64: 53 failures (11 on M3)
- Windows_x86_64: 22 failures (28 on M3)
* JDKTools
- Windows_x86_64: 3 failures by TimeoutException.
Regression? I previously incorrectly reported that they are
intermittent. They stably fail on M4 builds.
* Reliability
Failed on x86 platforms but they also failed on M3
api.net.HttpConnectionTest (I wonder why HARMONY-5266 did not fixed it=
)
api.net.SingleConnectTest
- Linux_x86:
Regresions:
api.kernel.object.ObjectFinalizeTest
api.kernel.throwable.StackTraceExcptsTest
api.text.DecimalFormat_Locales
api.zip.ZipEntryIterateThreadingTest
api.zip.ZlibTest
vm.finalization.FinalizeThrowRestoreTest
vm.stack.StackUnwindTest
They also failed on M3:
api.nio.channels.filechannel.FileChannelMapTest
api.nio.channels.filechannel.MappedByteBufferForceTest
api.serialization.SerializableClassesTest
- Windows_x86
Regresions:
api.kernel.string.InternThreadingTest - regression
api.kernel.thread.Calculation.CalcTest
api.kernel.thread.RecursiveThreadTest
api.kernel.thread.StackTraceTest
api.kernel.thread.Synchronization
api.kernel.thread.ThreadArrayTest
api.kernel.threadgroup.EnumerateTest
api.net.DatagramTest
api.serialization.SerializableClassesTest
vm.stack.StackUnwindTest
- Linux_x86_64:
Regressions:
vm.classloading.ClassCastTest
* Stress
- Linux_x86:
StackUnwindingManyObjectsTests: 5 fails on M3 too (HARMONY-5158 /
test issue?)
Fragmentation, FragmentationFinalizer, FragmentationReference:
HARMONY-5159 (was not run during M3 so not regression)
- Windows_x86:
StackUnwindingManyObjectsTests: 5 fails on M3 too (HARMONY-5158 /
test issue?)
FragmentationReference: HARMONY-5159 (was not run during M3 so not
regression)
- Linux_x86_64:
jni.arguments,jni.arrays - fails on M3 too so not regression / HARMON=
Y-????
MEMORY001, MEMORY003 - HARMONY-5047 (fails on M3 too so not regressio=
n)
- Windows_x86_64:
NotSynchThreads.ManyClasses - crash (HARMONY-5003), regression
Fragmentation, FragmentationFinalizer, FragmentationReference:
HARMONY-5159 (was not run during M3 so not regression)
gc.mem.MemoryTest3 - regression / HARMONY-????
jni.stack - fails on M3 too so not regression / HARMONY-????
EVENT014- crash (HARMONY-????)/ regression
MEMORY001, MEMORY003 - HARMONY-5047 (fails on M3 too so not regressio=
n)
StressThreads12Test - crash (HARMONY-????)/ regression
* VTS VM
- Windows_x86:
dstore_20701 - intermittent?
[1] http://people.apache.org/~mloenko/snapshot_testing/script/r603534/ind=
ex.html
[2] http://people.apache.org/~mloenko/snapshot_testing/script/r580985/ind=
ex.html
[3] http://people.apache.org/~mloenko/snapshot_testing/script/r603433/ind=
ex.html
Thanks,
Stepan Mishura
Intel Enterprise Solutions Software Division

--=20
http://xiao-feng.blogspot.com

From: Evgueni Brevnov

Date: Friday, December 14, 2007

wrote in message:

I saw this:
Reliability:
Linux_X86 regression:
vm.finalization.FinalizeThrowRestoreTest
I am not sure if anybody has early evaluation about it. If not, I
will create a JIRA for it.
Thanks,
xiaofeng
wrote in message:
> Hi,
>
> Please see testing status[1] for r603534 below.
> Note to my comments:
> - I marked tests as regression if they passed on M3 [2]
> - I question tests as intermittent if they passed on the previous
> snapshot (r603433) [3]
> - There are some tests that failed on M3 too. (move them to the exclude=
list
<data> A data structure holding many values, possibly of
	different types, which is usually accessed sequentially,
	working from the head to the end of the tail - an "ordered
	list".  This contrasts with a (one-dimensional) {array}, any
	element of which can be accessed equally quickly.

	Lists are often stored using a cell and pointer arrangement
	where each value is stored in a cell along with an associated
	pointer to the next cell.  A special pointer, e.g. zero, marks
	the end of the list.  This is known as a (singly) "linked
	list".  A doubly linked list has pointers from each cell to
	both next and previous cells.

	An unordered list is a {set}.

	(1998-11-12)
s?)
> - Not all failures have JIRA issue assigned so please help me to find
> related JIRA number (if there is any).
>
> All comments and clarifications are greatly appreciated!
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D

> We've the next suites failed on the snapshot.
>
> * Eclipse Unit Tests 3.3
> - Linux_x86: 4 failures
> - Windows_x86: pass rate 96.92%
> - Linux_x86_64: pass rate 95.29%
>
>'d be nice to get failures evaluation.
> We definitely improved stability of the Eclipse Unit Test suite since
> M3 (Thanks to Vladimir Beliaev).
> But the are still some issues such as intermittent suite crashes (that
> make me very upset).
>
> * EGAx48:
> - Linux_x86 & Linux_x86_64 : failed. (HARMONY-5250 / regression?)
> - Windows_x86:
> Still no status =96 the scenario causes CC host down after runnin=
g
> several hours.
> Currently I can not figure out if this is the host's issue or
> problem introduced by Harmony.
>
>
> * EHWA(GUI)
> - Linux_x86 & Linux_x86_64 : failed.
> The scenario is quite unstable. Most probably I will drop the
> scenario in M5 from snapshot test and use only EHWA-API.
>
>
> * Functional:
> F_KeyFactoryTest_01: regression on all platforms (HARMONY-4857)
>
> - Linux_x86:
> JComponent: intermittent?
> - Linux_x86_64:
> btest6353: fails on M3 too
> - Windows_x86_64:
> DataOutputStream, writeObjectReadObject0004, IfElse1, btest5717,
> btest7214 : intermittent?
> btest6353: fails on M3 too
>
> * GUT:
> ContainerTest, JAASSecurityTest - fail on all platforms
> HARMONY-4895 says that this bug in Geronimo and not a regression.
>
> - Linux_x86:
> HARMONY-5302 - says that this a bug in tests (I do not understand
> then why they passed on M3)
> security\jaas\ConfigurationEntryTest
> security\jaas\LoginKerberousNonGeronimoTest
> security\jaas\LoginKerberousTest
> security\jaas\LoginSQLTest
> security\network\protocol\SubjectCarryingProtocolTest
> security\remoting\jmx\RemoteLoginTest
>
> - Linux_x86_64: 53 failures (11 on M3)
> - Windows_x86_64: 22 failures (28 on M3)
>
>
> * JDKTools
> - Windows_x86_64: 3 failures by TimeoutException.
> Regression? I previously incorrectly reported that they are
> intermittent. They stably fail on M4 builds.
>
> * Reliability
>
> Failed on x86 platforms but they also failed on M3
> api.net.HttpConnectionTest (I wonder why HARMONY-5266 did not fixed =
it)
> api.net.SingleConnectTest
>
> - Linux_x86:
>
> Regresions:
> api.kernel.object.ObjectFinalizeTest
> api.kernel.throwable.StackTraceExcptsTest
> api.text.DecimalFormat_Locales
> api.zip.ZipEntryIterateThreadingTest
> api.zip.ZlibTest
> vm.finalization.FinalizeThrowRestoreTest
> vm.stack.StackUnwindTest
>
> They also failed on M3:
> api.nio.channels.filechannel.FileChannelMapTest
> api.nio.channels.filechannel.MappedByteBufferForceTest
> api.serialization.SerializableClassesTest
>
> - Windows_x86
>
> Regresions:
> api.kernel.string.InternThreadingTest - regression
> api.kernel.thread.Calculation.CalcTest
> api.kernel.thread.RecursiveThreadTest
> api.kernel.thread.StackTraceTest
> api.kernel.thread.Synchronization
> api.kernel.thread.ThreadArrayTest
> api.kernel.threadgroup.EnumerateTest
> api.net.DatagramTest
> api.serialization.SerializableClassesTest
> vm.stack.StackUnwindTest
>
> - Linux_x86_64:
>
> Regressions:
> vm.classloading.ClassCastTest
>
> * Stress
>
> - Linux_x86:
> StackUnwindingManyObjectsTests: 5 fails on M3 too (HARMONY-5158 /
> test issue?)
> Fragmentation, FragmentationFinalizer, FragmentationReference:
> HARMONY-5159 (was not run during M3 so not regression)
>
> - Windows_x86:
> StackUnwindingManyObjectsTests: 5 fails on M3 too (HARMONY-5158 /
> test issue?)
> FragmentationReference: HARMONY-5159 (was not run during M3 so not
> regression)
>
> - Linux_x86_64:
> jni.arguments,jni.arrays - fails on M3 too so not regression / HARM=
ONY-????
> MEMORY001, MEMORY003 - HARMONY-5047 (fails on M3 too so not regress=
ion)
>
> - Windows_x86_64:
> NotSynchThreads.ManyClasses - crash (HARMONY-5003), regression
> Fragmentation, FragmentationFinalizer, FragmentationReference:
> HARMONY-5159 (was not run during M3 so not regression)

Hi,

Fragmentation & FragmentationFinalizer tests have been enabled in Q4
since revision 601041. They made six successfull runs (by CC) since
that. Unfortunately last two runs failed with the same stack trace. So
we've a regression since revision 603102 (or probably this is
intermittent failure).

If you look closer at HARMONY-5159 you'd real

1. Not simulated.  Often used as a specific antonym to
	{virtual} in any of its jargon senses.

	2. <mathematics> {real number}.

	[{Jargon File}]

	(1997-03-12)

ize that this JIRA
states another problem which has no relation with current issue.

Do we treat it as critical problem for M4?

Thanks
Evgueni

> gc.mem.MemoryTest3 - regression / HARMONY-????
> jni.stack - fails on M3 too so not regression / HARMONY-????
> EVENT014- crash (HARMONY-????)/ regression
> MEMORY001, MEMORY003 - HARMONY-5047 (fails on M3 too so not regress=
ion)
> StressThreads12Test - crash (HARMONY-????)/ regression
>
> * VTS VM
> - Windows_x86:
> dstore_20701 - intermittent?
>
> [1] http://people.apache.org/~mloenko/snapshot_testing/script/r603534/i=
ndex.html
> [2] http://people.apache.org/~mloenko/snapshot_testing/script/r580985/i=
ndex.html
> [3] http://people.apache.org/~mloenko/snapshot_testing/script/r603433/i=
ndex.html
>
> Thanks,
> Stepan Mishura
> Intel Enterprise Solutions Software Division
>
--
http://xiao-feng.blogspot.com

From: Xiao-Feng Li

Date: Friday, December 14, 2007

wrote in message:
wrote in message:
> I saw this:
>
> Reliability:
> Linux_X86 regression:
> vm.finalization.FinalizeThrowRestoreTest
>
> I am not sure if anybody has early evaluation about it. If not, I
> will create a JIRA for it.
>
> Thanks,
> xiaofeng
>
> On Dec 14, 2007 4:09 PM, Stepan Mishura <stepan.mishura@xxxxxxxxxxx> wrot=
e:
> > Hi,
> >
> > Please see testing status[1] for r603534 below.
> > Note to my comments:
> > - I marked tests as regression if they passed on M3 [2]
> > - I question tests as intermittent if they passed on the previous
> > snapshot (r603433) [3]
> > - There are some tests that failed on M3 too. (move them to the exclu=
de lists?)
> > - Not all failures have JIRA issue assigned so please help me to find
> > related JIRA number (if there is any).
> >
> > All comments and clarifications are greatly appreciated!
> >
> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D

> > We've the next suites failed on the snapshot.
> >
> > * Eclipse Unit Tests 3.3
> > - Linux_x86: 4 failures
> > - Windows_x86: pass rate 96.92%
> > - Linux_x86_64: pass rate 95.29%
> >
> >'d be nice to get failures evaluation.
> > We definitely improved stability of the Eclipse Unit Test suite since
> > M3 (Thanks to Vladimir Beliaev).
> > But the are still some issues such as intermittent suite crashes (tha=
t
> > make me very upset).
> >
> > * EGAx48:
> > - Linux_x86 & Linux_x86_64 : failed. (HARMONY-5250 / regression?)
> > - Windows_x86:
> > Still no status =96 the scenario causes CC host down after runn=
ing
> > several hours.
> > Currently I can not figure out if this is the host's issue or
> > problem introduced by Harmony.
> >
> >
> > * EHWA(GUI)
> > - Linux_x86 & Linux_x86_64 : failed.
> > The scenario is quite unstable. Most probably I will drop the
> > scenario in M5 from snapshot test and use only EHWA-API.
> >
> >
> > * Functional:
> > F_KeyFactoryTest_01: regression on all platforms (HARMONY-4857)
> >
> > - Linux_x86:
> > JComponent: intermittent?
> > - Linux_x86_64:
> > btest6353: fails on M3 too
> > - Windows_x86_64:
> > DataOutputStream, writeObjectReadObject0004, IfElse1, btest5717=
,
> > btest7214 : intermittent?
> > btest6353: fails on M3 too
> >
> > * GUT:
> > ContainerTest, JAASSecurityTest - fail on all platforms
> > HARMONY-4895 says that this bug in Geronimo and not a regressio=
n.
> >
> > - Linux_x86:
> > HARMONY-5302 - says that this a bug in tests (I do not understand
> > then why they passed on M3)
> > security\jaas\ConfigurationEntryTest
> > security\jaas\LoginKerberousNonGeronimoTest
> > security\jaas\LoginKerberousTest
> > security\jaas\LoginSQLTest
> > security\network\protocol\SubjectCarryingProtocolTest
> > security\remoting\jmx\RemoteLoginTest
> >
> > - Linux_x86_64: 53 failures (11 on M3)
> > - Windows_x86_64: 22 failures (28 on M3)
> >
> >
> > * JDKTools
> > - Windows_x86_64: 3 failures by TimeoutException.
> > Regression? I previously incorrectly reported that they are
> > intermittent. They stably fail on M4 builds.
> >
> > * Reliability
> >
> > Failed on x86 platforms but they also failed on M3
> > api.net.HttpConnectionTest (I wonder why HARMONY-5266 did not fixe=
d it)
> > api.net.SingleConnectTest
> >
> > - Linux_x86:
> >
> > Regresions:
> > api.kernel.object.ObjectFinalizeTest
> > api.kernel.throwable.StackTraceExcptsTest
> > api.text.DecimalFormat_Locales
> > api.zip.ZipEntryIterateThreadingTest
> > api.zip.ZlibTest
> > vm.finalization.FinalizeThrowRestoreTest
> > vm.stack.StackUnwindTest
> >
> > They also failed on M3:
> > api.nio.channels.filechannel.FileChannelMapTest
> > api.nio.channels.filechannel.MappedByteBufferForceTest
> > api.serialization.SerializableClassesTest
> >
> > - Windows_x86
> >
> > Regresions:
> > api.kernel.string.InternThreadingTest - regression
> > api.kernel.thread.Calculation.CalcTest
> > api.kernel.thread.RecursiveThreadTest
> > api.kernel.thread.StackTraceTest
> > api.kernel.thread.Synchronization
> > api.kernel.thread.ThreadArrayTest
> > api.kernel.threadgroup.EnumerateTest
> > api.net.DatagramTest
> > api.serialization.SerializableClassesTest
> > vm.stack.StackUnwindTest
> >
> > - Linux_x86_64:
> >
> > Regressions:
> > vm.classloading.ClassCastTest
> >
> > * Stress
> >
> > - Linux_x86:
> > StackUnwindingManyObjectsTests: 5 fails on M3 too (HARMONY-5158 /
> > test issue?)
> > Fragmentation, FragmentationFinalizer, FragmentationReference:
> > HARMONY-5159 (was not run during M3 so not regression)
> >
> > - Windows_x86:
> > StackUnwindingManyObjectsTests: 5 fails on M3 too (HARMONY-5158 =
/
> > test issue?)
> > FragmentationReference: HARMONY-5159 (was not run during M3 so no=
t
> > regression)
> >
> > - Linux_x86_64:
> > jni.arguments,jni.arrays - fails on M3 too so not regression / HA=
RMONY-????
> > MEMORY001, MEMORY003 - HARMONY-5047 (fails on M3 too so not regre=
ssion)
> >
> > - Windows_x86_64:
> > NotSynchThreads.ManyClasses - crash (HARMONY-5003), regression
> > Fragmentation, FragmentationFinalizer, FragmentationReference:
> > HARMONY-5159 (was not run during M3 so not regression)
Hi,
Fragmentation & FragmentationFinalizer tests have been enabled in Q4
since revision 601041. They made six successfull runs (by CC) since
that. Unfortunately last two runs failed with the same stack trace. So
we've a regression since revision 603102 (or probably this is
intermittent failure).
If you look closer at HARMONY-5159 you'd realize that this JIRA
states another problem which has no relation with current issue.
Do we treat it as critical problem for M4?

Evgueni, Do you ask if H5159 is critical or the other issue is
critical? Probably we should ask JIT people to answer if H5159 is
critical. Stepan said it's not a regression. If you ask about the
other issue (performance in Linux86), I guess we can only evaluate it
after the OOME problem is solved, because to me it's hard to expect
the behavior if the memory is out (without handling) while finalizers
are under processing.

Thanks,
xiaofeng

Thanks
Evgueni
> > gc.mem.MemoryTest3 - regression / HARMONY-????
> > jni.stack - fails on M3 too so not regression / HARMONY-????
> > EVENT014- crash (HARMONY-????)/ regression
> > MEMORY001, MEMORY003 - HARMONY-5047 (fails on M3 too so not regre=
ssion)
> > StressThreads12Test - crash (HARMONY-????)/ regression
> >
> > * VTS VM
> > - Windows_x86:
> > dstore_20701 - intermittent?
> >
> > [1] http://people.apache.org/~mloenko/snapshot_testing/script/r603534=
/index.html
> > [2] http://people.apache.org/~mloenko/snapshot_testing/script/r580985=
/index.html
> > [3] http://people.apache.org/~mloenko/snapshot_testing/script/r603433=
/index.html
> >
> > Thanks,
> > Stepan Mishura
> > Intel Enterprise Solutions Software Division
> >
>
>
>
> --
> http://xiao-feng.blogspot.com
>
--=20

http://xiao-feng.blogspot.com

From: Tim Ellison

Date: Friday, December 14, 2007

wrote in message:

Hi,
Please see testing status[1] for r603534 below.
Note to my comments:
- I marked tests as regression if they passed on M3 [2]
- I question tests as intermittent if they passed on the previous
snapshot (r603433) [3]
- There are some tests that failed on M3 too. (move them to the exclude lists?)
- Not all failures have JIRA issue assigned so please help me to find
related JIRA number (if there is any).
All comments and clarifications are greatly appreciated!
=====================================================
We've the next suites failed on the snapshot.
* Eclipse Unit Tests 3.3
- Linux_x86: 4 failures
- Windows_x86: pass rate 96.92%
- Linux_x86_64: pass rate 95.29%
Would be nice to get failures evaluation.
We definitely improved stability of the Eclipse Unit Test suite since
M3 (Thanks to Vladimir Beliaev).
But the are still some issues such as intermittent suite crashes (that
make me very upset).

And yet these numbers

(Scientific computation) Output from a computation that may
	not be significant but at least indicates that the program is
	running.  Numbers may be used to placate management, grant
	sponsors, etc.  "Making numbers" means running a program
	because output - any output, not necessarily meaningful output
	- is needed as a demonstration of progress.

	See {pretty pictures}, {math-out}, {social science number}.

	[{Jargon File}]

	(1995-01-13)

are high pass rates, so it implies

<logic> (=> or a thin right arrow) A binary {Boolean} function
	and {logical connective}.  A => B is true unless A is true and
	B is false.  The {truth table} is

		A B | A => B
		----+-------
		F F |   T
		F T |   T
		T F |   F
		T T |   T

	It is surprising at first that A => B is always true if A is
	false, but if X => Y then we would expect that (X & Z) => Y
	for any Z.

	(1995-09-30)

that the
milestone is quite stable. Clearly if we were testing a release

<programming> (Or "released version", "baseline") A version of
	a piece of software which has been made public (as opposed to
	a version that is in development, or otherwise unreleased).

	A release is either a {major release}, a {revision}, or a
	{bugfix}.

	Pre-release versions may be called {alpha test}, or {beta
	test} versions.

	See {change management}.

	(1996-08-04)

candidate we'd want to improve these even further.

* EGAx48:
- Linux_x86 & Linux_x86_64 : failed. (HARMONY-5250 / regression?)
- Windows_x86:
Still no status – the scenario causes CC host down after running
several hours.
Currently I can not figure out if this is the host's issue or
problem introduced by Harmony.

We should look into these to see if they are regressions.
I will help.

* EHWA(GUI)
- Linux_x86 & Linux_x86_64 : failed.
The scenario is quite unstable. Most probably I will drop the
scenario in M5 from snapshot test and use only EHWA-API.

Ok.

* Functional:
F_KeyFactoryTest_01: regression on all platforms (HARMONY-4857)
- Linux_x86:
JComponent: intermittent?

As Andrey says, these shouldn't stop us declaring M4.

- Linux_x86_64:
btest6353: fails on M3 too
- Windows_x86_64:
DataOutputStream, writeObjectReadObject0004, IfElse1, btest5717,
btest7214 : intermittent?
btest6353: fails on M3 too

Intermittent and non-regression failures on the 64-bit

<architecture> A term describing a computer architecture based
	around an {ALU}, {registers} and {data bus} which are 64
	{bit}s wide.

	64-bit processors were quite common in 1996, e.g. {Digital}
	{Alpha}, versions of {Sun} {SPARC}, {MIPS}, {IBM} {AS/4000}.
	the {PowerPC} and {Intel} were expected to move to 64 bits at
	their next generation - {PPC 620} and {Intel P7}.

	A 64-bit {address bus} allows the processor to address 18
	million {gigabytes} as opposed to the mere 4 gigabytes allowed
	with 32 bits.  There were in 1996 already {hard disks} which
	can hold over 4GB.  Floating point calculations can also be
	more accurate.

	A 64-bit {OS} is needed as well to take advantage of the CPU.
	In 1996 there were only a few 64-bit operating systems,
	including {OS/400}, {Digital} {Unix}, {Solaris} (partialy).  A
	32-bit OS can run on a 64-bit CPU.

	(2004-05-12)

platforms I'd
suggest we need to log in JIRA and target

<hardware> A {SCSI} device that executes a command from a
	{SCSI initiator} to perform some task.  Typically the target
	is a SCSI peripheral device but the {host adapter} can also be
	a target.

	(1999-02-10)

for the next milestone.

* GUT:
ContainerTest, JAASSecurityTest - fail on all platforms
HARMONY-4895 says that this bug in Geronimo and not a regression.

Ok.

- Linux_x86:
HARMONY-5302 - says that this a bug in tests (I do not understand
then why they passed on M3)
security\jaas\ConfigurationEntryTest
security\jaas\LoginKerberousNonGeronimoTest
security\jaas\LoginKerberousTest
security\jaas\LoginSQLTest
security\network\protocol\SubjectCarryingProtocolTest
security\remoting\jmx\RemoteLoginTest
- Linux_x86_64: 53 failures (11 on M3)
- Windows_x86_64: 22 failures (28 on M3)

These need further investigation IMO.

* JDKTools
- Windows_x86_64: 3 failures by TimeoutException.
Regression? I previously incorrectly reported that they are
intermittent. They stably fail on M4 builds.

Assuming these pass on 32-bit platforms?
Is there a JIRA describing this one already?

* Reliability
Failed on x86 platforms but they also failed on M3
api.net.HttpConnectionTest (I wonder why HARMONY-5266 did not fixed it)
api.net.SingleConnectTest
- Linux_x86:
Regresions:
api.kernel.object.ObjectFinalizeTest
api.kernel.throwable.StackTraceExcptsTest
api.text.DecimalFormat_Locales
api.zip.ZipEntryIterateThreadingTest
api.zip.ZlibTest
vm.finalization.FinalizeThrowRestoreTest
vm.stack.StackUnwindTest

Regressions :-(

They also failed on M3:
api.nio.channels.filechannel.FileChannelMapTest
api.nio.channels.filechannel.MappedByteBufferForceTest
api.serialization.SerializableClassesTest
- Windows_x86
Regresions:
api.kernel.string.InternThreadingTest - regression
api.kernel.thread.Calculation.CalcTest
api.kernel.thread.RecursiveThreadTest
api.kernel.thread.StackTraceTest
api.kernel.thread.Synchronization
api.kernel.thread.ThreadArrayTest
api.kernel.threadgroup.EnumerateTest
api.net.DatagramTest
api.serialization.SerializableClassesTest
vm.stack.StackUnwindTest

Regressions :-(

- Linux_x86_64:
Regressions:
vm.classloading.ClassCastTest
* Stress
- Linux_x86:
StackUnwindingManyObjectsTests: 5 fails on M3 too (HARMONY-5158 /
test issue?)
Fragmentation, FragmentationFinalizer, FragmentationReference:
HARMONY-5159 (was not run during M3 so not regression)
- Windows_x86:
StackUnwindingManyObjectsTests: 5 fails on M3 too (HARMONY-5158 /
test issue?)
FragmentationReference: HARMONY-5159 (was not run during M3 so not
regression)

Ok.

- Linux_x86_64:
jni.arguments,jni.arrays - fails on M3 too so not regression / HARMONY-????
MEMORY001, MEMORY003 - HARMONY-5047 (fails on M3 too so not regression)
- Windows_x86_64:
NotSynchThreads.ManyClasses - crash (HARMONY-5003), regression
Fragmentation, FragmentationFinalizer, FragmentationReference:
HARMONY-5159 (was not run during M3 so not regression)
gc.mem.MemoryTest3 - regression / HARMONY-????
jni.stack - fails on M3 too so not regression / HARMONY-????
EVENT014- crash (HARMONY-????)/ regression
MEMORY001, MEMORY003 - HARMONY-5047 (fails on M3 too so not regression)
StressThreads12Test - crash (HARMONY-????)/ regression

A variety of things to investigate in there it seems.

* VTS VM
- Windows_x86:
dstore_20701 - intermittent?
[1] http://people.apache.org/~mloenko/snapshot_testing/script/r603534/index.html
[2] http://people.apache.org/~mloenko/snapshot_testing/script/r580985/index.html
[3] http://people.apache.org/~mloenko/snapshot_testing/script/r603433/index.html

Another great summary Stepan. Thanks for doing this!

Regards,
Tim

From: Evgueni Brevnov

Date: Friday, December 14, 2007

wrote in message:

On Dec 14, 2007 5:44 PM, Evgueni Brevnov <evgueni.brevnov@xxxxxxxxxxx> wrot=
e:
>
wrote in message:
> > I saw this:
> >
> > Reliability:
> > Linux_X86 regression:
> > vm.finalization.FinalizeThrowRestoreTest
> >
> > I am not sure if anybody has early evaluation about it. If not, I
> > will create a JIRA for it.
> >
> > Thanks,
> > xiaofeng
> >
> > On Dec 14, 2007 4:09 PM, Stepan Mishura <stepan.mishura@xxxxxxxxxxx> wr=
ote:
> > > Hi,
> > >
> > > Please see testing status[1] for r603534 below.
> > > Note to my comments:
> > > - I marked tests as regression if they passed on M3 [2]
> > > - I question tests as intermittent if they passed on the previous
> > > snapshot (r603433) [3]
> > > - There are some tests that failed on M3 too. (move them to the exc=
lude lists?)
> > > - Not all failures have JIRA issue assigned so please help me to fi=
nd
> > > related JIRA number (if there is any).
> > >
> > > All comments and clarifications are greatly appreciated!
> > >
> > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D

> > > We've the next suites failed on the snapshot.
> > >
> > > * Eclipse Unit Tests 3.3
> > > - Linux_x86: 4 failures
> > > - Windows_x86: pass rate 96.92%
> > > - Linux_x86_64: pass rate 95.29%
> > >
> > >'d be nice to get failures evaluation.
> > > We definitely improved stability of the Eclipse Unit Test suite sin=
ce
> > > M3 (Thanks to Vladimir Beliaev).
> > > But the are still some issues such as intermittent suite crashes (t=
hat
> > > make me very upset).
> > >
> > > * EGAx48:
> > > - Linux_x86 & Linux_x86_64 : failed. (HARMONY-5250 / regression?=
)
> > > - Windows_x86:
> > > Still no status =96 the scenario causes CC host down after ru=
nning
> > > several hours.
> > > Currently I can not figure out if this is the host's issue or
> > > problem introduced by Harmony.
> > >
> > >
> > > * EHWA(GUI)
> > > - Linux_x86 & Linux_x86_64 : failed.
> > > The scenario is quite unstable. Most probably I will drop the
> > > scenario in M5 from snapshot test and use only EHWA-API.
> > >
> > >
> > > * Functional:
> > > F_KeyFactoryTest_01: regression on all platforms (HARMONY-485=
7)
> > >
> > > - Linux_x86:
> > > JComponent: intermittent?
> > > - Linux_x86_64:
> > > btest6353: fails on M3 too
> > > - Windows_x86_64:
> > > DataOutputStream, writeObjectReadObject0004, IfElse1, btest57=
17,
> > > btest7214 : intermittent?
> > > btest6353: fails on M3 too
> > >
> > > * GUT:
> > > ContainerTest, JAASSecurityTest - fail on all platforms
> > > HARMONY-4895 says that this bug in Geronimo and not a regress=
ion.
> > >
> > > - Linux_x86:
> > > HARMONY-5302 - says that this a bug in tests (I do not understan=
d
> > > then why they passed on M3)
> > > security\jaas\ConfigurationEntryTest
> > > security\jaas\LoginKerberousNonGeronimoTest
> > > security\jaas\LoginKerberousTest
> > > security\jaas\LoginSQLTest
> > > security\network\protocol\SubjectCarryingProtocolTest
> > > security\remoting\jmx\RemoteLoginTest
> > >
> > > - Linux_x86_64: 53 failures (11 on M3)
> > > - Windows_x86_64: 22 failures (28 on M3)
> > >
> > >
> > > * JDKTools
> > > - Windows_x86_64: 3 failures by TimeoutException.
> > > Regression? I previously incorrectly reported that they are
> > > intermittent. They stably fail on M4 builds.
> > >
> > > * Reliability
> > >
> > > Failed on x86 platforms but they also failed on M3
> > > api.net.HttpConnectionTest (I wonder why HARMONY-5266 did not fi=
xed it)
> > > api.net.SingleConnectTest
> > >
> > > - Linux_x86:
> > >
> > > Regresions:
> > > api.kernel.object.ObjectFinalizeTest
> > > api.kernel.throwable.StackTraceExcptsTest
> > > api.text.DecimalFormat_Locales
> > > api.zip.ZipEntryIterateThreadingTest
> > > api.zip.ZlibTest
> > > vm.finalization.FinalizeThrowRestoreTest
> > > vm.stack.StackUnwindTest
> > >
> > > They also failed on M3:
> > > api.nio.channels.filechannel.FileChannelMapTest
> > > api.nio.channels.filechannel.MappedByteBufferForceTest
> > > api.serialization.SerializableClassesTest
> > >
> > > - Windows_x86
> > >
> > > Regresions:
> > > api.kernel.string.InternThreadingTest - regression
> > > api.kernel.thread.Calculation.CalcTest
> > > api.kernel.thread.RecursiveThreadTest
> > > api.kernel.thread.StackTraceTest
> > > api.kernel.thread.Synchronization
> > > api.kernel.thread.ThreadArrayTest
> > > api.kernel.threadgroup.EnumerateTest
> > > api.net.DatagramTest
> > > api.serialization.SerializableClassesTest
> > > vm.stack.StackUnwindTest
> > >
> > > - Linux_x86_64:
> > >
> > > Regressions:
> > > vm.classloading.ClassCastTest
> > >
> > > * Stress
> > >
> > > - Linux_x86:
> > > StackUnwindingManyObjectsTests: 5 fails on M3 too (HARMONY-5158=
/
> > > test issue?)
> > > Fragmentation, FragmentationFinalizer, FragmentationReference:
> > > HARMONY-5159 (was not run during M3 so not regression)
> > >
> > > - Windows_x86:
> > > StackUnwindingManyObjectsTests: 5 fails on M3 too (HARMONY-515=
8 /
> > > test issue?)
> > > FragmentationReference: HARMONY-5159 (was not run during M3 so =
not
> > > regression)
> > >
> > > - Linux_x86_64:
> > > jni.arguments,jni.arrays - fails on M3 too so not regression / =
HARMONY-????
> > > MEMORY001, MEMORY003 - HARMONY-5047 (fails on M3 too so not reg=
ression)
> > >
> > > - Windows_x86_64:
> > > NotSynchThreads.ManyClasses - crash (HARMONY-5003), regression
> > > Fragmentation, FragmentationFinalizer, FragmentationReference:
> > > HARMONY-5159 (was not run during M3 so not regression)
>
> Hi,
>
> Fragmentation & FragmentationFinalizer tests have been enabled in Q4
> since revision 601041. They made six successfull runs (by CC) since
> that. Unfortunately last two runs failed with the same stack trace. So
> we've a regression since revision 603102 (or probably this is
> intermittent failure).
>
> If you look closer at HARMONY-5159 you'd realize that this JIRA
> states another problem which has no relation with current issue.
>
> Do we treat it as critical problem for M4?
Evgueni, Do you ask if H5159 is critical or the other issue is
critical? Probably we should ask JIT people to answer if H5159 is
critical.

No, I do not ask about H5159. This issue does not seems to be connected
to current failures in any way.

Stepan said it's not a regression.

Yes, this isn't a regression since M3. But this is a regression since
revision 603102. These two tests have stably passed for a week until
revision 603433.
These tests crashes with stack trace which I did not see before:

Windows reported exception

An error condition that changes the normal {flow of control}
	in a program.  An exception may be generated ("raised") by
	{hardware} or {software}.  Hardware exceptions include
	{reset}, {interrupt} or a signal from a {memory management
	unit}.  Exceptions may be generated by the {arithmetic logic
	unit} or {floating-point unit} for numerical errors such as
	divide by zero, {overflow} or {underflow} or {instruction
	decoding} errors such as privileged, reserved, {trap} or
	undefined instructions.  Software exceptions are even more
	varied and the term could be applied to any kind of error
	checking which alters the normal behaviour of the program.

	(1994-10-31)

: 0xc0000005
Registers:
RAX: 0x000000001fd28000, RBX: 0x000000001fb30000
RCX: 0x0000000000000000, RDX: 0x00000000c000012d
RSI: 0x00000000034c9710, RDI: 0x0000000001ee2280
RSP: 0x000000000012ca00, RBP: 0x0000000024a30430
R8 : 0x0000000000000000, R9 : 0x0000000078ec0000
R10: 0x00000000000001f8, R11: 0x0000000000000246
R12: 0x00000000034c9710, R13: 0x0000000024a28000
R14: 0x000000000000409a, R15: 0x0000000044560000
RIP: 0x0000000001eb87c1
Windows reported exception: 0xc0000005
Registers:
RAX: 0x0000000024a20430, RBX: 0x000000004596e750
RCX: 0x000000004596e750, RDX: 0x0000000024a30430
RSI: 0x000000000012bb00, RDI: 0x0000000000000000
RSP: 0x000000000012b920, RBP: 0x0000000000000000
R8 : 0x00007fffffff0000, R9 : 0x000000000012b9b0
R10: 0x0000000000000000, R11: 0x0000000000000293
R12: 0x0000000000000001, R13: 0x0000000045812820
R14: 0x0000000000000000, R15: 0x00000000ffffffff
RIP: 0x000000000078d531
Stack trace:
0: verify_object_header (??:-1)
1: ?? (??:-1)
2: org/apache/harmony/test/stress/gc/share/GcTest.freeMemory()J
(GcTest.JAVA:438)
3: org/apache/harmony/test/stress/gc/share/GcTest.setUpAfterWatchers()V
(GcTest.JAVA:86)
4: org/punit/method/runner/AbstractMethodRunner.setUpAfterWatchers([LJAVA=
/lang/Object;)V
(??:-1)
5: org/punit/method/runner/AbstractMethodRunner.run(LJAVA/lang/Object;Lja=
va/lang/reflect/Method;[LJAVA/lang/Object;)V
(??:-1)
6: org/punit/runner/AbstractRunner.runTestMethod(LJAVA/lang/Object;LJAVA/=
lang/reflect/Method;)V
(??:-1)
7: org/punit/runner/AbstractRunner.access$100(Lorg/punit/runner/AbstractR=
unner;LJAVA/lang/Object;LJAVA/lang/reflect/Method;)V
(??:-1)
8: org/punit/runner/AbstractRunner$4.traverse(LJAVA/lang/Object;)V (??:-1=
)
9: org/punit/util/TraverserUtil.traverse(LJAVA/util/Iterator;Lorg/punit/u=
til/Traverser;)V
(??:-1)
10: org/punit/runner/AbstractRunner.runTestClassImpl(LJAVA/lang/Class;)V
(??:-1)
11: org/punit/runner/AbstractRunner.runTestClass(LJAVA/lang/Class;)V (??:-=
1)
12: org/punit/runner/AbstractRunner.runTestClasses([LJAVA/lang/Object;)V
(??:-1)
13: org/punit/runner/AbstractRunner.run(LJAVA/lang/Class;)I (??:-1)
14: org/apache/harmony/test/share/stress/AbstractTest.runTestClass()V
(AbstractTest.JAVA:61)
15: org/apache/harmony/test/stress/gc/share/GcTest.main([LJAVA/lang/String=
;)V
(GcTest.JAVA:73)

Thanks
Evgueni

If you ask about the

other issue (performance in Linux86), I guess we can only evaluate it
after the OOME problem is solved, because to me it's hard to expect
the behavior if the memory is out (without handling) while finalizers
are under processing.
Thanks,
xiaofeng
> Thanks
> Evgueni
>
>
> > > gc.mem.MemoryTest3 - regression / HARMONY-????
> > > jni.stack - fails on M3 too so not regression / HARMONY-????
> > > EVENT014- crash (HARMONY-????)/ regression
> > > MEMORY001, MEMORY003 - HARMONY-5047 (fails on M3 too so not reg=
ression)
> > > StressThreads12Test - crash (HARMONY-????)/ regression
> > >
> > > * VTS VM
> > > - Windows_x86:
> > > dstore_20701 - intermittent?
> > >
> > > [1] http://people.apache.org/~mloenko/snapshot_testing/script/r6035=
34/index.html
> > > [2] http://people.apache.org/~mloenko/snapshot_testing/script/r5809=
85/index.html
> > > [3] http://people.apache.org/~mloenko/snapshot_testing/script/r6034=
33/index.html
> > >
> > > Thanks,
> > > Stepan Mishura
> > > Intel Enterprise Solutions Software Division
> > >
> >
> >
> >
> > --
> > http://xiao-feng.blogspot.com
> >
>
--
http://xiao-feng.blogspot.com

From: Pavel Pervov

Date: Friday, December 14, 2007

------=_Part_146_33206171.1197629416388

Content-Disposition: inline

Stepan,

Tests in VTSVM intermittently fail on Windows x86 returning 0 instead of
expected 105. This isn't dependant on test and on functionality

<programming> Waffle for "{features}" or "function".  The
	capabilities or behaviours of a program, part of a program, or
	system, seen as the sum of its {features}.  Roughly, "the
	things it can do".  Generally used in a comparative sense,
	e.g. "The latest update adds some useful functionality".

	(1997-07-14)

it is
testing. It may be worth a JIRA, but it isn't a regression.

<SNIP>

Thanks,
--
Pavel Pervov,
Intel Enterprise Solutions Software Division

------=_Part_146_33206171.1197629416388--

From: Vladimir Beliaev

Date: Friday, December 14, 2007

------=_Part_134_5709841.1197629425931

Content-Disposition: inline

Hello, Stepan, Tim,

* Eclipse Unit Tests 3.3
- Linux_x86: 4 failures
- Windows_x86: pass rate 96.92%
- Linux_x86_64: pass rate 95.29%

Actually according to [1] the status is:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
- Windows_x86: pass rate 99.77% (but not 96.92%). There are 3 expected
failures which are in EFL already & which caused the winx86 status is RED.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
- Linux_x86: 96.72%
1257 issues in
org.eclipse.jdt.core.tests.compiler.regression.TestAll- they are
intermittent, must be ignored.
1 issue in org.eclipse.jdt.text.tests.JdtTextTestSuite - I'm checking
it now, it looks like intermittent failure
6 issues in org.eclipse.jdt.ui.tests.AutomatedSuite - HARMONY-5307,
looks like invalid tests - I'm checking this now.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
- Linux_x86_64: pass rate 95.29%

Fixing the crashes must allow us to get 98% pass rate, the stand alon=
g
failures/errors are EFL candidates. So:

Crashed org.eclipse.core.tests.resources.AutomatedTests - real crash,
HARMONY-5303, the JIRA is being evaluated now.

Crashed org.eclipse.jdt.debug.tests.AutomatedSuite - real crash,
HARMONY-5305, the JIRA is being evaluated now.

Crashed org.eclipse.team.tests.ccvs.core.AllTests - new for me, I'm
checking this locally.

Thanks
Vladimir

[1]
http://people.apache.org/~mloenko/snapshot_testing/script/r603534/index.htm=
l2007/12/14, Stepan Mishura <stepan.mishura@xxxxxxxxxxx>:

Hi,
Please see testing status[1] for r603534 below.
Note to my comments:
- I marked tests as regression if they passed on M3 [2]
- I question tests as intermittent if they passed on the previous
snapshot (r603433) [3]
- There are some tests that failed on M3 too. (move them to the exclude
lists?)
- Not all failures have JIRA issue assigned so please help me to find
related JIRA number (if there is any).
All comments and clarifications are greatly appreciated!
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D

We have the next suites failed on the snapshot.
* Eclipse Unit Tests 3.3
- Linux_x86: 4 failures
- Windows_x86: pass rate 96.92%
- Linux_x86_64: pass rate 95.29%
Would be nice to get failures evaluation.
We definitely improved stability of the Eclipse Unit Test suite since
M3 (Thanks to Vladimir Beliaev).
But the are still some issues such as intermittent suite crashes (that
make me very upset).
* EGAx48:
- Linux_x86 & Linux_x86_64 : failed. (HARMONY-5250 / regression?)
- Windows_x86:
Still no status =96 the scenario causes CC host down after running
several hours.
Currently I can not figure out if this is the host's issue or
problem introduced by Harmony.
* EHWA(GUI)
- Linux_x86 & Linux_x86_64 : failed.
The scenario is quite unstable. Most probably I will drop the
scenario in M5 from snapshot test and use only EHWA-API.
* Functional:
F_KeyFactoryTest_01: regression on all platforms (HARMONY-4857)
- Linux_x86:
JComponent: intermittent?
- Linux_x86_64:
btest6353: fails on M3 too
- Windows_x86_64:
DataOutputStream, writeObjectReadObject0004, IfElse1, btest5717,
btest7214 : intermittent?
btest6353: fails on M3 too
* GUT:
ContainerTest, JAASSecurityTest - fail on all platforms
HARMONY-4895 says that this bug in Geronimo and not a regression.
- Linux_x86:
HARMONY-5302 - says that this a bug in tests (I do not understand
then why they passed on M3)
security\jaas\ConfigurationEntryTest
security\jaas\LoginKerberousNonGeronimoTest
security\jaas\LoginKerberousTest
security\jaas\LoginSQLTest
security\network\protocol\SubjectCarryingProtocolTest
security\remoting\jmx\RemoteLoginTest
- Linux_x86_64: 53 failures (11 on M3)
- Windows_x86_64: 22 failures (28 on M3)
* JDKTools
- Windows_x86_64: 3 failures by TimeoutException.
Regression? I previously incorrectly reported that they are
intermittent. They stably fail on M4 builds.
* Reliability
Failed on x86 platforms but they also failed on M3
api.net.HttpConnectionTest (I wonder why HARMONY-5266 did not fixed it)
api.net.SingleConnectTest
- Linux_x86:
Regresions:
api.kernel.object.ObjectFinalizeTest
api.kernel.throwable.StackTraceExcptsTest
api.text.DecimalFormat_Locales
api.zip.ZipEntryIterateThreadingTest
api.zip.ZlibTest
vm.finalization.FinalizeThrowRestoreTest
vm.stack.StackUnwindTest
They also failed on M3:
api.nio.channels.filechannel.FileChannelMapTest
api.nio.channels.filechannel.MappedByteBufferForceTest
api.serialization.SerializableClassesTest
- Windows_x86
Regresions:
api.kernel.string.InternThreadingTest - regression
api.kernel.thread.Calculation.CalcTest
api.kernel.thread.RecursiveThreadTest
api.kernel.thread.StackTraceTest
api.kernel.thread.Synchronization
api.kernel.thread.ThreadArrayTest
api.kernel.threadgroup.EnumerateTest
api.net.DatagramTest
api.serialization.SerializableClassesTest
vm.stack.StackUnwindTest
- Linux_x86_64:
Regressions:
vm.classloading.ClassCastTest
* Stress
- Linux_x86:
StackUnwindingManyObjectsTests: 5 fails on M3 too (HARMONY-5158 /
test issue?)
Fragmentation, FragmentationFinalizer, FragmentationReference:
HARMONY-5159 (was not run during M3 so not regression)
- Windows_x86:
StackUnwindingManyObjectsTests: 5 fails on M3 too (HARMONY-5158 /
test issue?)
FragmentationReference: HARMONY-5159 (was not run during M3 so not
regression)
- Linux_x86_64:
jni.arguments,jni.arrays - fails on M3 too so not regression /
HARMONY-????
MEMORY001, MEMORY003 - HARMONY-5047 (fails on M3 too so not regression=
)
- Windows_x86_64:
NotSynchThreads.ManyClasses - crash (HARMONY-5003), regression
Fragmentation, FragmentationFinalizer, FragmentationReference:
HARMONY-5159 (was not run during M3 so not regression)
gc.mem.MemoryTest3 - regression / HARMONY-????
jni.stack - fails on M3 too so not regression / HARMONY-????
EVENT014- crash (HARMONY-????)/ regression
MEMORY001, MEMORY003 - HARMONY-5047 (fails on M3 too so not regression=
)
StressThreads12Test - crash (HARMONY-????)/ regression
* VTS VM
- Windows_x86:
dstore_20701 - intermittent?
[1]
http://people.apache.org/~mloenko/snapshot_testing/script/r603534/index.h=
tml
[2]
http://people.apache.org/~mloenko/snapshot_testing/script/r580985/index.h=
tml
[3]
http://people.apache.org/~mloenko/snapshot_testing/script/r603433/index.h=
tml
Thanks,
Stepan Mishura
Intel Enterprise Solutions Software Division

------=_Part_134_5709841.1197629425931--

From: Vladimir Beliaev

Date: Friday, December 14, 2007

------=_Part_589_32192290.1197639638185

Content-Disposition: inline

Updated status:

- Linux_x86: 96.72%
1257 issues in

org.eclipse.jdt.core.tests.compiler.regression.TestAll - they are
intermittent, must be ignored.

I didn't reproduced them locally.

1 issue in org.eclipse.jdt.text.tests.JdtTextTestSuite - I'm checking it

now, it looks like intermittent failure

Also not reproducible.

- Linux_x86_64: pass rate 95.29%
Fixing the crashes must allow us to get 98% pass rate, the stand alon=
g

failures/errors are EFL candidates. So:

...
Crashed org.eclipse.team.tests.ccvs.core.AllTests - new for me, I'm
checking this locally.

Not reproduced locally.

So remained issues for resolution

1. <hardware> the maximum number of {pixels} that can be
	displayed on a {monitor}, expressed as (number of horizontal
	pixels) x (number of vertical pixels), i.e., 1024x768.  The
	ratio of horizontal to vertical resolution is usually 4:3, the
	same as that of conventional television sets.

	2. <logic> A mechanical method for proving statements of
	{first order logic}, introduced by J. A. Robinson in 1965.
	Resolution is applied to two {clauses} in a {sentence}.  It
	eliminates, by {unification}, a {literal} that occurs
	"positive" in one and "negative" in the other to produce a new
	clause, the {resolvent}.

	For example, given the sentence:

		(man(X) => mortal(X))  AND  man(socrates).

	The literal "man(X)" is "negative".  The literal
	"man(socrates)" could be considered to be on the right hand
	side of the degenerate implication

		True => man(socrates)

	and is therefore "positive".  The two literals can be unified
	by the binding X = socrates.

	The {truth table} for the implication function is

		A | B | A => B
		--+---+-------
		F | F |   T
		F | T |   T
		T | F |   F
		T | T |   T

	(The implication only fails if its premise is true but its
	conclusion is false).  From this we can see that

		A => B   ==   (NOT A) OR B

	Which is why the left hand side of the implication is said to
	be negative and the right positive.  The sentence above could
	thus be written

		((NOT man(socrates)) OR mortal(socrates))
		AND
		man(socrates)

	Distributing the AND over the OR gives

		((NOT man(socrates)) AND man(socrates))
		OR
		mortal(socrates) AND man(socrates)

	And since (NOT A) AND A == False, and False OR A == A we can
	simplify to just

		mortal(socrates) AND man(socrates)

	So we have proved the new literal, mortal(socrates).

	Resolution with {backtracking} is the basic control mechanism
	of {Prolog}.

	See also {modus ponens}, {SLD Resolution}.

	3. <networking> {address resolution}.

	(1996-02-09)

are:

HARMONY-5306 [buildtest][EUT] swt suite intermittently crashes by timeout
(Linux x86 regressions)
-----
HARMONY-5303 [drlvm][EUT] regression in coreresources on Linux x86_64 (Linu=
x
x86_64 98%)
HARMONY-5305 [drlvm][EUT] regression in jdtdebug in Linux x86_64 (Linux
x86_64 98%)
HARMONY-5309 [EUT] 274 NPE in checkAndTagAsMalformed on Linux x86_64 (Linux
x86_64 98%)

Thanks
Vladimir

2007/12/14, Vladimir Beliaev <vladimir.k.beliaev@xxxxxxxxxxx>:

Hello, Stepan, Tim,
> * Eclipse Unit Tests 3.3
> - Linux_x86: 4 failures
> - Windows_x86: pass rate 96.92%
> - Linux_x86_64: pass rate 95.29%
Actually according to [1] the status is:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
- Windows_x86: pass rate 99.77% (but not 96.92%). There are 3 expecte=
d
failures which are in EFL already & which caused the winx86 status is RED=
.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
- Linux_x86: 96.72%
1257 issues in
org.eclipse.jdt.core.tests.compiler.regression.TestAll - they are
intermittent, must be ignored.
1 issue in org.eclipse.jdt.text.tests.JdtTextTestSuite - I'm
checking it now, it looks like intermittent failure
6 issues in org.eclipse.jdt.ui.tests.AutomatedSuite - HARMONY-5307,
looks like invalid tests - I'm checking this now.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
- Linux_x86_64: pass rate 95.29%
Fixing the crashes must allow us to get 98% pass rate, the stand
along failures/errors are EFL candidates. So:
Crashed org.eclipse.core.tests.resources.AutomatedTests - real
crash, HARMONY-5303, the JIRA is being evaluated now.
Crashed org.eclipse.jdt.debug.tests.AutomatedSuite - real crash,
HARMONY-5305, the JIRA is being evaluated now.
Crashed org.eclipse.team.tests.ccvs.core.AllTests - new for me, I'm
checking this locally.
Thanks
Vladimir
[1]
http://people.apache.org/~mloenko/snapshot_testing/script/r603534/index.h=
tml
2007/12/14, Stepan Mishura <stepan.mishura@xxxxxxxxxxx>:
>
> Hi,
>
> Please see testing status[1] for r603534 below.
> Note to my comments:
> - I marked tests as regression if they passed on M3 [2]
> - I question tests as intermittent if they passed on the previous
> snapshot (r603433) [3]
> - There are some tests that failed on M3 too. (move them to the exclude
> lists?)
> - Not all failures have JIRA issue assigned so please help me to find
> related JIRA number (if there is any).
>
> All comments and clarifications are greatly appreciated!
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D

> We've the next suites failed on the snapshot.
>
> * Eclipse Unit Tests 3.3
> - Linux_x86: 4 failures
> - Windows_x86: pass rate 96.92%
> - Linux_x86_64: pass rate 95.29%
>
>'d be nice to get failures evaluation.
> We definitely improved stability of the Eclipse Unit Test suite since
> M3 (Thanks to Vladimir Beliaev).
> But the are still some issues such as intermittent suite crashes (that
> make me very upset).
>
> * EGAx48:
> - Linux_x86 & Linux_x86_64 : failed. (HARMONY-5250 / regression?)
> - Windows_x86:
> Still no status =96 the scenario causes CC host down after running
> several hours.
> Currently I can not figure out if this is the host's issue or
> problem introduced by Harmony.
>
>
> * EHWA(GUI)
> - Linux_x86 & Linux_x86_64 : failed.
> The scenario is quite unstable. Most probably I will drop the
> scenario in M5 from snapshot test and use only EHWA-API.
>
>
> * Functional:
> F_KeyFactoryTest_01: regression on all platforms (HARMONY-4857)
>
> - Linux_x86:
> JComponent: intermittent?
> - Linux_x86_64:
> btest6353: fails on M3 too
> - Windows_x86_64:
> DataOutputStream, writeObjectReadObject0004, IfElse1, btest5717,
> btest7214 : intermittent?
> btest6353: fails on M3 too
>
> * GUT:
> ContainerTest, JAASSecurityTest - fail on all platforms
> HARMONY-4895 says that this bug in Geronimo and not a regression.
>
> - Linux_x86:
> HARMONY-5302 - says that this a bug in tests (I do not understand
> then why they passed on M3)
> security\jaas\ConfigurationEntryTest
> security\jaas\LoginKerberousNonGeronimoTest
> security\jaas\LoginKerberousTest
> security\jaas\LoginSQLTest
> security\network\protocol\SubjectCarryingProtocolTest
> security\remoting\jmx\RemoteLoginTest
>
> - Linux_x86_64: 53 failures (11 on M3)
> - Windows_x86_64: 22 failures (28 on M3)
>
>
> * JDKTools
> - Windows_x86_64: 3 failures by TimeoutException.
> Regression? I previously incorrectly reported that they are
> intermittent. They stably fail on M4 builds.
>
> * Reliability
>
> Failed on x86 platforms but they also failed on M3
> api.net.HttpConnectionTest (I wonder why HARMONY-5266 did not fixed
> it)
> api.net.SingleConnectTest
>
> - Linux_x86:
>
> Regresions:
> api.kernel.object.ObjectFinalizeTest
> api.kernel.throwable.StackTraceExcptsTest
> api.text.DecimalFormat_Locales
> api.zip.ZipEntryIterateThreadingTest
> api.zip.ZlibTest
> vm.finalization.FinalizeThrowRestoreTest
> vm.stack.StackUnwindTest
>
> They also failed on M3:
> api.nio.channels.filechannel.FileChannelMapTest
> api.nio.channels.filechannel.MappedByteBufferForceTest
> api.serialization.SerializableClassesTest
>
> - Windows_x86
>
> Regresions:
> api.kernel.string.InternThreadingTest - regression
> api.kernel.thread.Calculation.CalcTest
> api.kernel.thread.RecursiveThreadTest
> api.kernel.thread.StackTraceTest
> api.kernel.thread.Synchronization
> api.kernel.thread.ThreadArrayTest
> api.kernel.threadgroup.EnumerateTest
> api.net.DatagramTest
> api.serialization.SerializableClassesTest
> vm.stack.StackUnwindTest
>
> - Linux_x86_64:
>
> Regressions:
> vm.classloading.ClassCastTest
>
> * Stress
>
> - Linux_x86:
> StackUnwindingManyObjectsTests: 5 fails on M3 too (HARMONY-5158 /
> test issue?)
> Fragmentation, FragmentationFinalizer, FragmentationReference:
> HARMONY-5159 (was not run during M3 so not regression)
>
> - Windows_x86:
> StackUnwindingManyObjectsTests: 5 fails on M3 too (HARMONY-5158 /
> test issue?)
> FragmentationReference: HARMONY-5159 (was not run during M3 so not
> regression)
>
> - Linux_x86_64:
> jni.arguments,jni.arrays - fails on M3 too so not regression /
> HARMONY-????
> MEMORY001, MEMORY003 - HARMONY-5047 (fails on M3 too so not
> regression)
>
> - Windows_x86_64:
> NotSynchThreads.ManyClasses - crash (HARMONY-5003), regression
> Fragmentation, FragmentationFinalizer, FragmentationReference:
> HARMONY-5159 (was not run during M3 so not regression)
> gc.mem.MemoryTest3 - regression / HARMONY-????
> jni.stack - fails on M3 too so not regression / HARMONY-????
> EVENT014- crash (HARMONY-????)/ regression
> MEMORY001, MEMORY003 - HARMONY-5047 (fails on M3 too so not
> regression)
> StressThreads12Test - crash (HARMONY-????)/ regression
>
> * VTS VM
> - Windows_x86:
> dstore_20701 - intermittent?
>
> [1]
> http://people.apache.org/~mloenko/snapshot_testing/script/r603534/index=
.html
> [2]
> http://people.apache.org/~mloenko/snapshot_testing/script/r580985/index=
.html
> [3]
> http://people.apache.org/~mloenko/snapshot_testing/script/r603433/index=
.html
>
> Thanks,
> Stepan Mishura
> Intel Enterprise Solutions Software Division
>

------=_Part_589_32192290.1197639638185--

From: Andrey Yakushev

Date: Monday, December 17, 2007

My comments on the reliability

<system> An attribute of any system that consistently produces
	the same results, preferably meeting or exceeding its
	specifications.  The term may be qualified, e.g {software
	reliability}, {reliable communication}.

	Reliability is one component of {RAS}.

	(2000-08-13)

suite results:

* Reliability

There are several tests with known intermittent failures in this suite
which weren't put to exclude list in order to control

<character> (Or "ctrl", "^") One (or a pair) of {modifier
	keys} found on all modern {keyboards}.  If the control key is
	held down while pressing and releasing certain other keys then
	a "{control character}" is generated, e.g. holding control and
	hitting "A" generates control-A ({ASCII} code 1).  The ASCII
	code for the control character is generally 64 less than that
	for the unmodified character.

	The control key does not generate any character on its own but
	most modern keyboards and {operating systems} allow a program
	to tell whether each of the individual keys on the keyboard
	(including modifier keys) is pressed at any time.

	Control characters mostly have some kind of "non-printing"
	effect on the output such as ringing the bell (Control-G) or
	advancing to the next line (Control-J).  Most have alternative
	names suggesting these functions (Bell, Line Feed, etc.).

	See {ASCII character table}.

	(1997-07-10)

new regression
appearance. Thus several failures are expected.

Failed on x86 platforms but they also failed on M3
api.net.HttpConnectionTest (I wonder why HARMONY-5266 did not fixed it)

That's because BTI workspace was not updated on CC host.

api.net.SingleConnectTest

Known intermittent test issue, the reason was described in HARMONY-5266.

- Linux_x86:
Regresions:
api.kernel.object.ObjectFinalizeTest

exception after 1705 successful iteration

<programming> Repetition of a sequence of instructions.  A
	fundamental part of many {algorithms}.  Iteration is
	characterised by a set of initial conditions, an iterative
	step and a termination condition.

	A well known example of iteration in mathematics is
	Newton-Raphson iteration.  Iteration in programs is expressed
	using {loops}, e.g. in {C}:

		new_x = n/2;
		do
		{
		  x = new_x;
		  new_x = 0.5 * (x + n/x);
		} while (abs(new_x-x) > epsilon);

	Iteration can be expressed in functional languages using
	recursion:

		solve x n = if abs(new_x-x) > epsilon
			    then solve new_x n
			    else new_x
			    where new_x = 0.5 * (x + n/x)

	        solve n/2 n

	(1998-04-04)

s - probably regression - I
could not reproduce it yet in my local runs.

api.kernel.throwable.StackTraceExcptsTest

hang

1. To wait for an event that will never occur.  "The system is
	hanging because it can't read from the crashed drive".  See
	{wedged}, {hung}.

	2. To wait for some event to occur; to hang around until
	something happens.  "The program displays a menu and then
	hangs until you type a character."  Compare {block}.

	3. To attach a peripheral device, especially in the
	construction "hang off": "We're going to hang another tape
	drive off the file server."  Implies a device attached with
	cables, rather than something that is strictly inside the
	machine's chassis.

- could be similar to HARMONY-5288 issue

api.text.DecimalFormat_Locales

hang - could be similar to HARMONY-5288 issue

api.zip.ZipEntryIterateThreadingTest

Enable to open

1. To prepare to read or write a file.  This usually involves
	checking whether the file already exists and that the user has
	the necessary authorisation to read or write it.  The result
	of a successful open is usually some kind of {capability}
	(e.g. a {Unix} {file descriptor}) - a token that the user
	passes back to the system in order to access the file without
	further checks and finally to close the file.

	2. Abbreviation for "open (or left) parenthesis" - used when
	necessary to eliminate oral ambiguity.  To read aloud the LISP
	form (DEFUN FOO (X) (PLUS X 1)) one might say: "Open defun
	foo, open eks close, open, plus eks one, close close."

	3. Non-proprietary.  An open {standard} is one which can be
	used without payment.

	[{Jargon File}]

	(1995-01-31)

file - I saw that on M3 - not a regression.

api.zip.ZlibTest

Known intermittent failure HARMONY-4215, HARMONY-5166 - not a regression

vm.finalization.FinalizeThrowRestoreTest

VM crash after 142 successful iterations - new issue, could be similar
to HARMONY-5304 - regression

vm.stack.StackUnwindTest

Hang after 1025 successful iterations - I saw it previously on M3,
probably HARMONY-4215 - not a regression

They also failed on M3:
api.nio.channels.filechannel.FileChannelMapTest
api.nio.channels.filechannel.MappedByteBufferForceTest
api.serialization.SerializableClassesTest

My local run but on the debug release gives only 3 failures:

api.kernel.thread.VolatileVariableTest.PetersonTest - hang 32223
successful iterations - I saw that intermittently on M3 - not
regression - probably this is HARMONY-4215
api.nio.channels.filechannel.MappedByteBufferForceTest - not regression -wa=
s on
vm.finalization.FinalizeThrowRestoreTest - assertion

<programming> 1. An expression which, if false, indicates an
	{error}.  Assertions are used for {debugging} by catching
	{can't happen} errors.

	2. In {logic programming}, a new {fact} or {rule} added to the
	database by the program at {run time}.  This is an
	{extralogical} or impure feature of logic programming
	languages.

	(1997-06-30)

after 66
successful iterations - could be similar to HARMONY-5304

There are also several known failures in valid excluded tests (they
weren't run on CC)

api.kernel.thread.LifeSimulationTest.Life
vm.classloading.ClassCastTest
vm.classloading.ClassReflectionTest

- Windows_x86
Regresions:
api.kernel.string.InternThreadingTest - regression
api.kernel.thread.Calculation.CalcTest
api.kernel.thread.RecursiveThreadTest
api.kernel.thread.StackTraceTest
api.kernel.thread.Synchronization
api.kernel.thread.ThreadArrayTest
api.kernel.threadgroup.EnumerateTest
api.net.DatagramTest
api.serialization.SerializableClassesTest
vm.stack.StackUnwindTest

My local run results on the release build showed mostly different failures:

api.net.NetClient - not regression - known intermittent failure - HARMONY-4=
215
api.net.SingleConnectTest - test issue - HARMONY-5266
api.net.DatagramTest - hang on iteration #4 - probably HARMONY-4215,
but could be a regression
api.io.IOTest - i/o failure - require investigation - probably regression
api.kernel.thread.ThreadArrayTest.ThreadArrayTest - OutOfMemoryError
after 958 successful iterations
api.kernel.thread.Calculation.CalcTest - OutOfMemoryError after 17317
successful iterations
api.kernel.object.ObjectFinalizeTest - exception after 461 successful
iterations

There are also several failures in excluded tests (they weren't run on CC)

vm.classloading.ClassReflectionTest - not regression - HARMONY-3680
vm.classloading.ClassAttributesTest - not regression - HARMONY-3680
api.kernel.thread.LifeSimulationTest.Life - not regression -
OutOfMemoryError after 21507 successful iterations - HARMONY-5266
api.kernel.hooks.AddRmPropertiesHooksTest - regression - HARMONY-5172

- Linux_x86_64:
Regressions:
vm.classloading.ClassCastTest

This is HARMONY-5304.I suggest fixing it now if possible.

My local run results on the debug build also showed 7 failures only in
excluded tests (they weren't run on CC):

api.kernel.thread.ExcptHandlerTest.ExcptHandlerTest
api.kernel.thread.LifeSimulationTest.Life
api.nio.channels.filechannel.MappedByteBufferForceTest
api.net.DatagramTest
vm.classloading.ClassAttributesTest
vm.classloading.ClassReflectionTest
vm.classloading.DelegationModelTest

Details are available at
http://wiki.apache.org/harmony/Reliability_Tests_on_DRLVM

My resume:

My tests run results:

Platform | failures | regressions | pass rate
Windows x86 | 11 failures | 4 regressions | 87.2%
Linux x86 | 6 failures | 1 regressions | 93%
Linux x86_64 | 7 failures | 1 regression | 92%

This is better results then M3 had. Usually on M3 we had had 11-13
failures: http://people.apache.org/~mloenko/snapshot_testing/script/r580985=
/index.html

So I think the reliability in M4 was improved in general although we
still have an opportunity for improvements :)

Thanks,
wrote in message:

Hi,
Please see testing status[1] for r603534 below.
Note to my comments:
- I marked tests as regression if they passed on M3 [2]
- I question tests as intermittent if they passed on the previous
snapshot (r603433) [3]
- There are some tests that failed on M3 too. (move them to the exclude l=
ists?)
- Not all failures have JIRA issue assigned so please help me to find
related JIRA number (if there is any).
All comments and clarifications are greatly appreciated!
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D

We have the next suites failed on the snapshot.
* Eclipse Unit Tests 3.3
- Linux_x86: 4 failures
- Windows_x86: pass rate 96.92%
- Linux_x86_64: pass rate 95.29%
Would be nice to get failures evaluation.
We definitely improved stability of the Eclipse Unit Test suite since
M3 (Thanks to Vladimir Beliaev).
But the are still some issues such as intermittent suite crashes (that
make me very upset).
* EGAx48:
- Linux_x86 & Linux_x86_64 : failed. (HARMONY-5250 / regression?)
- Windows_x86:
Still no status =96 the scenario causes CC host down after running
several hours.
Currently I can not figure out if this is the host's issue or
problem introduced by Harmony.
* EHWA(GUI)
- Linux_x86 & Linux_x86_64 : failed.
The scenario is quite unstable. Most probably I will drop the
scenario in M5 from snapshot test and use only EHWA-API.
* Functional:
F_KeyFactoryTest_01: regression on all platforms (HARMONY-4857)
- Linux_x86:
JComponent: intermittent?
- Linux_x86_64:
btest6353: fails on M3 too
- Windows_x86_64:
DataOutputStream, writeObjectReadObject0004, IfElse1, btest5717,
btest7214 : intermittent?
btest6353: fails on M3 too
* GUT:
ContainerTest, JAASSecurityTest - fail on all platforms
HARMONY-4895 says that this bug in Geronimo and not a regression.
- Linux_x86:
HARMONY-5302 - says that this a bug in tests (I do not understand
then why they passed on M3)
security\jaas\ConfigurationEntryTest
security\jaas\LoginKerberousNonGeronimoTest
security\jaas\LoginKerberousTest
security\jaas\LoginSQLTest
security\network\protocol\SubjectCarryingProtocolTest
security\remoting\jmx\RemoteLoginTest
- Linux_x86_64: 53 failures (11 on M3)
- Windows_x86_64: 22 failures (28 on M3)
* JDKTools
- Windows_x86_64: 3 failures by TimeoutException.
Regression? I previously incorrectly reported that they are
intermittent. They stably fail on M4 builds.
* Reliability
Failed on x86 platforms but they also failed on M3
api.net.HttpConnectionTest (I wonder why HARMONY-5266 did not fixed it)
api.net.SingleConnectTest
- Linux_x86:
Regresions:
api.kernel.object.ObjectFinalizeTest
api.kernel.throwable.StackTraceExcptsTest
api.text.DecimalFormat_Locales
api.zip.ZipEntryIterateThreadingTest
api.zip.ZlibTest
vm.finalization.FinalizeThrowRestoreTest
vm.stack.StackUnwindTest
They also failed on M3:
api.nio.channels.filechannel.FileChannelMapTest
api.nio.channels.filechannel.MappedByteBufferForceTest
api.serialization.SerializableClassesTest
- Windows_x86
Regresions:
api.kernel.string.InternThreadingTest - regression
api.kernel.thread.Calculation.CalcTest
api.kernel.thread.RecursiveThreadTest
api.kernel.thread.StackTraceTest
api.kernel.thread.Synchronization
api.kernel.thread.ThreadArrayTest
api.kernel.threadgroup.EnumerateTest
api.net.DatagramTest
api.serialization.SerializableClassesTest
vm.stack.StackUnwindTest
- Linux_x86_64:
Regressions:
vm.classloading.ClassCastTest
* Stress
- Linux_x86:
StackUnwindingManyObjectsTests: 5 fails on M3 too (HARMONY-5158 /
test issue?)
Fragmentation, FragmentationFinalizer, FragmentationReference:
HARMONY-5159 (was not run during M3 so not regression)
- Windows_x86:
StackUnwindingManyObjectsTests: 5 fails on M3 too (HARMONY-5158 /
test issue?)
FragmentationReference: HARMONY-5159 (was not run during M3 so not
regression)
- Linux_x86_64:
jni.arguments,jni.arrays - fails on M3 too so not regression / HARMONY=
-????
MEMORY001, MEMORY003 - HARMONY-5047 (fails on M3 too so not regression=
)
- Windows_x86_64:
NotSynchThreads.ManyClasses - crash (HARMONY-5003), regression
Fragmentation, FragmentationFinalizer, FragmentationReference:
HARMONY-5159 (was not run during M3 so not regression)
gc.mem.MemoryTest3 - regression / HARMONY-????
jni.stack - fails on M3 too so not regression / HARMONY-????
EVENT014- crash (HARMONY-????)/ regression
MEMORY001, MEMORY003 - HARMONY-5047 (fails on M3 too so not regression=
)
StressThreads12Test - crash (HARMONY-????)/ regression
* VTS VM
- Windows_x86:
dstore_20701 - intermittent?
[1] http://people.apache.org/~mloenko/snapshot_testing/script/r603534/ind=
ex.html
[2] http://people.apache.org/~mloenko/snapshot_testing/script/r580985/ind=
ex.html
[3] http://people.apache.org/~mloenko/snapshot_testing/script/r603433/ind=
ex.html
Thanks,
Stepan Mishura
Intel Enterprise Solutions Software Division
--=20

Thanks,
Andrey

From: Pavel Rebriy

Date: Monday, December 17, 2007

------=_Part_7910_7857859.1197908265651

Content-Disposition: inline

wrote in message:

My comments on the reliability suite results:
> * Reliability
There are several tests with known intermittent failures in this suite
which weren't put to exclude list in order to control new regression
appearance. Thus several failures are expected.
>
> Failed on x86 platforms but they also failed on M3