Run testing at OpenJ9 with debug symbols #8874

pshipton · 2020-03-16T14:48:42Z

When crashes occur running tests at the OpenJ9 project, some platforms include native stack traces in the crash output. However since there are no debug symbols included with the JVM, the native stack traces usually aren't helpful. We should have the debug symbols included by default for tests running at the OpenJ9 project in order to make the crash output more useful, help triage go faster.

Most of the work has been completed to create a debug image containing the debug symbols. This is helpful for AdoptOpenJDK builds where the debug symbols are undesirable in the JVM builds in order to keep the size of the JVMs smaller. Developers and service can use the debug image to aid in diagnosing problems.

It's TBD what the best approach should be for OpenJ9 builds/tests. We can either include the debug symbols into the JVM builds at OpenJ9 by default, or download and expand the debug image before running tests at the project. I've created this Issue to discuss it.

pshipton · 2020-03-16T14:48:51Z

@DanHeidinga @keithc-ca

pshipton · 2020-03-16T14:50:06Z

It would also be useful if the testing at AdoptOpenJDK had the debug symbols included by default.

DanHeidinga · 2020-03-16T15:15:20Z

We can either include the debug symbols into the JVM builds at OpenJ9 by default, or download and expand the debug image before running tests at the project.

@smlambert @llxia Is one of these options easier to do in the context of Test playlists?

Some thoughts:

To have the tests include them, the workflow would probably be something like:

download jdk
download matching debug image
extract jdk
extract debug image over jdk to put debug libs in the right place

Would this require passing in additional options to TKG to indicate where the to get the debug image?

Including the debug symbols in the OpenJ9 builds by default seems simpler but means we'd need a different approach between OpenJ9 and Adopt.

If we want to allow developers to specify the debug image to apply in ie: grinders, then we may need all the work for separate package option anyways.

smlambert · 2020-03-16T16:01:41Z

We already often have to go pick the native test images that are built, can the debug image be included in that gzip file? In that way, there are less additional steps required to the workflow.

Mind you, currently, I do not believe the functional native test images are being built at Adopt, only openjdk native test images (so for 'nice to have' at Adopt, there would be more to changes required.

pshipton · 2020-03-16T16:11:05Z

Certainly the debug image can be combined with the test image, although if it's specific to OpenJ9 I don't think having it separate is much different.

smlambert · 2020-03-16T16:21:41Z

Having it separate is not much different, it means an additional URL for the gzip file being passed in the CUSTOMIZED_URL_SDK parameter to the test pipeline.

Not a big deal to automation, but ever try telling a developer that something new is expected in a param field. I suspect it would throw some people off, suspect it would further confuse people trying to run Grinders, etc. Would like not to introduce more ways to discourage dev team from running tests and more reasons to require extra documentation that may never get referenced.

pshipton · 2020-03-16T16:55:22Z

Good points, I'm not against combining the debug image with the test image. Personally I usually forget to include the test image when running a grinder. Putting everything (test and debug) in the JVM package at OpenJ9 would be easiest.

pshipton · 2020-03-16T20:02:41Z

Discussing with Dan and Lan, we're leaning towards combining the debug image into the test image rather than modifying the JVM package. This keeps the separation for OpenJ9 builds the same as at the Adopt builds, since the debug image won't be included with the JVM at Adopt. Aligning with Adopt reduces the number of special cases and things that people need to remember.

@keithc-ca can you please make this change to put the debug-image folder into the test image archive. Unfortunately this means the debug image can't be directly overlayed on top of the JVM, and will need to be copied by the user. We could keep the existing debug image archive as well, as long as we don't run out of artifactory space.

After the test image archive is updated, Lan will modify the code to copy or move the debug libraries into the right place.
https://github.com/AdoptOpenJDK/openjdk-tests/blob/6d4670a158607cb0e0fd30e76b5c6a0f03a7a74d/get.sh#L273

keithc-ca · 2020-03-17T17:45:02Z

If the content currently included in debug-image.tar.gz is added to test-images.tar.gz keeping the same relative paths, the result can still be unpacked directly over a jdk as is the case today. The result will include a test-images directory (which you don't currently get), but that shouldn't cause any harm.

keithc-ca · 2020-03-17T17:48:38Z

I feel I need to point out that using such a unified test-images.tar.gz would mean that we're not actually testing the same bits that a regular user would get. Does that not cause anyone concern?

smlambert · 2020-03-17T17:58:05Z

I assumed the approach would be same as suggested in #8874 (comment)

pshipton · 2020-03-17T17:59:35Z

we're not actually testing the same bits that a regular user would get.

Except on AIX, I don't expect the debug symbol files are used at runtime unless there is a crash. Even on AIX the risk of a problem resulting from removing debug symbols seem low.

pshipton · 2020-03-17T18:00:42Z

added to test-images.tar.gz keeping the same relative paths

We can try that, it seems a bit trickier to manage. https://github.com/AdoptOpenJDK/openjdk-tests/blob/6d4670a158607cb0e0fd30e76b5c6a0f03a7a74d/get.sh#L273 is not going to put the files in the right place but will have to copy/move them.

keithc-ca · 2020-03-17T21:08:59Z

To make #8874 (comment) more concrete, the resulting test-image archive would contain paths such as these:

bin/*.debuginfo
lib/*.debuginfo
lib/compressedrefs/*.debuginfo
lib/j9vm/*.debuginfo
lib/jli/*.debuginfo
lib/server/*.debuginfo
test-images/jdk/demos/*
test-images/jdk/jtreg/*
test-images/openj9/*
test-images/Readme.txt

A consequence of this is that there will then be two or three top-level directories (lib will not be present for Windows) which will need different handling at https://github.com/AdoptOpenJDK/openjdk-tests/blob/6d4670a158607cb0e0fd30e76b5c6a0f03a7a74d/get.sh#L272

@smlambert Can you explain the intent of that part of get.sh? Or make changes in anticipation of the new content?

pshipton · 2020-03-17T21:18:41Z

@llxia fyi the previous comment as well.

llxia · 2020-03-18T01:17:30Z

Is it possible to put debug image into one folder, so it is easier to mv? test-image archive would contain:

debug-images/bin/*.debuginfo
debug-images/lib/*.debuginfo
...
test-images/jdk/demos/*
test-images/jdk/jtreg/*
test-images/openj9/*
test-images/Readme.txt

get.sh is for downloading and unzipping files (i.e., JDK, JRE, test-image (hotspot test image), native-test-libs (openj9 test image), etc). Once the change for adding debug-images is done, I can update the get.sh logic to move it directly over a jdk.

pshipton · 2020-03-18T01:27:41Z

Is it possible to put debug image into one folder

It is possible, but while this makes it easier for the code, it makes it harder for development or service to apply the debug image to a JVM. It shouldn't be too arduous to handle two directories in the code.

Once the change for adding debug-images is done, I can update the get.sh logic to move it directly over a jdk

Looking at the get.sh logic, it seems if we add a second directory into the test image, then get.sh will no longer work as it looks for a dir array of length 1. It may need to be modified first.

smlambert · 2020-03-18T01:29:46Z

This was in response to #8874 (comment) (before I saw Lan and Pete's comments)

Once the space separated param list passed to CUSTOMIZED_SDK_URL are unzipped, https://github.com/AdoptOpenJDK/openjdk-tests/blob/master/get.sh#L272-L289 moves the unzipped contents into various top-level directories.

CUSTOMIZED_SDK_URL can be one (or two) of many things depending on the name of the file:

directories containing test-image in the name, get moved as is to openjdk-test-image dir
test-images/jdk/demos/*
test-images/jdk/jtreg/*
test-images/openj9/*
test-images/Readme.txt
if jre image that was built along with the sdk, move to j2re-image dir
the sdk to test, then move to j2sdk-image dir
when the sdk doesn't unpack in any of the expected naming conventions (like certain sdks built on vmfarm), move it anyway

But as @llxia mentioned, the plan was that we would handle updating get.sh

llxia · 2020-03-18T12:38:51Z

Looking at the get.sh logic, it seems if we add a second directory into the test image, then get.sh will no longer work as it looks for a dir array of length 1. It may need to be modified first.

oh, misread the message, as above mentioned that The result will include a test-images directory (which you don't currently get), so I thought we will add a new test-images and debug images under current top-level dir test-images. In this case, get.sh can be updated later to handle debug image as it will not break anything. Only NATIVE_TEST_LIBS needs to updated to point the correct location.

test-images/test-images
test-images/lib
test-images/bin

Anyway, if we want to change test-images.tar.gz from
one top-level dir (current case after unzipping)

test-images

to multiple top-level dirs (after unzipping)

test-images
lib
bin

, then the check becomes a little complicated in get.sh.

after unzipping,
if dir length == 1
   if dir name is is test-images
        mv test-images to ../openjdk-test-image  
   other checks to mv dir to designated place based on dir name (i.e., jre, jdk,etc)
if dir length > 1 && one of dir name is test-images
   mv test-images to ../openjdk-test-image
   mv lib to overlay on top of jdk
   mv bin to overlay on top of jdk
else
   mv ../tmp ../j2sdk-image  // this is for handling vmfarm SDK (does not unpack in any of the expected naming conventions)

We need to handle test-images in two different cases (1 top-level dir vs 2/3 top-level dirs) and assuming vmfarm SDK does not contain test-images dir. And yes, get.sh has to be modified first in this case.

keithc-ca · 2020-03-18T13:27:37Z

The result will include a test-images directory (which you don't currently get),

The current test-image does have a top-level directory called test-images. Looking at the archive from [1] we see:

$ tar tzvf test-images.tar.gz | head
drwxrwxr-x  0 jenkins jenkins     0 18 Mar 05:46 test-images/
-rw-rw-r--  0 jenkins jenkins    15 18 Mar 05:10 test-images/Readme.txt
drwxrwxr-x  0 jenkins jenkins     0 18 Mar 05:46 test-images/openj9/
-rwxrwxr-x  0 jenkins jenkins 14248 18 Mar 05:46 test-images/openj9/libgptest.so
-rwxrwxr-x  0 jenkins jenkins  8192 18 Mar 05:46 test-images/openj9/libtestjvmtiB.so
-rwxrwxr-x  0 jenkins jenkins 107008 18 Mar 05:46 test-images/openj9/bcvunit
-rwxrwxr-x  0 jenkins jenkins   8024 18 Mar 05:46 test-images/openj9/libj9unresolved.so
-rwxrwxr-x  0 jenkins jenkins  27936 18 Mar 05:46 test-images/openj9/libjlmagent29.so
-rwxrwxr-x  0 jenkins jenkins   8192 18 Mar 05:46 test-images/openj9/libtestjvmtiA.so
-rwxrwxr-x  0 jenkins jenkins 118392 18 Mar 05:46 test-images/openj9/gc_rwlocktest

I can put the debug-image contribution wherever we decide; my suggestion of having top-level bin and, perhaps, lib directories would make it more convenient to use the archive to add debug symbols to a jdk.

We agree, the get.sh script (and any other consumers of a modified test-image) needs to be prepared before the change we're contemplating is made.

So what pattern do we want?

[1] https://ci.eclipse.org/openj9/job/Build_JDK11_x86-64_linux_OMR/517/

smlambert · 2020-03-18T13:48:48Z

@keithc-ca - are you referencing the OMR build link because there is a separate debug-image.tar.gz file? If you want to directly pass that, then by all means do (I only suggested merging it with test images for convenience of developers using Grinders, but I am sure developers can adapt).

How that would look (from an OpenJ9 build perspective... we of course have to support other build systems too)?
3 space separated artifacts
CUSTOMIZED_SDK_URL=URL_to_sdk.tar.gz URL_to_test-images.tar.gz URL_to_debug-image.tar.gz

at the moment in get.sh, all get unzipped and moved based on checking what the name says, we can change that logic however we want.

What other consumers of debug-image.tar.gz are there? Please describe some common use cases / scenarios.

keithc-ca · 2020-03-18T14:03:45Z

Describing it as an 'OMR' link is misleading - the link is to an 'OMR Acceptance' build of jdk11. Most (all?) jdk builds at ci.eclipse.org/openj9 have a link to a test-image archive; I only offered that as a representative sample illustrating the path names in such an archive (they should all be the same).

The primary use-cases for a debug-image are up in the description of this issue. BTW, those builds should also all have links to a debug-image archive.

For a brief time, the debug-image URL was included in CUSTOMIZED_SDK_URL, but that didn't work well. If I recall correctly, get.sh didn't handle that third archive well. We could keep the debug-image separate and include its URL in the list if get.sh were able to do the right thing. @smlambert pointed out that that makes life more difficult for users in that they may need to remember to specify an extra URL which is one of the reasons we're discussing the possibility of additional artifacts in the test-image.

llxia · 2020-03-18T16:43:45Z

To me, there are two problems:
problem 1. make life easy for the user to require less URL
problem 2. handle debug image in get.sh (overlay on top of sdk)

Regardless of what is the solution for problem 1, problem 2 cannot be avoided.

On top of my head, I think the best way to solve Problem 1 is to be able to download all jar files at the folder level. Instead of asking the link for each jar, users provide link at the folder level. In this way, users do not need to provide test-images, debug image or anything else in the future.

I am able to do it using wget

bash-3.2$ wget -r --no-parent -nH --cut-dirs=4 --reject "index.html*" https://140-211-168-230-openstack.osuosl.org/artifactory/ci-eclipse-openj9/Build_JDK11_x86-64_linux_Nightly/306/
bash-3.2$ ls
OpenJ9-JDK11-x86-64_linux-20200303-030650.tar.gz	test-images.tar.gz
debug-image.tar.gz

However, I am not able to do it using curl options only. We can do it using script, but it gets ugly.

Since only SDK filename changes (test-images.tar.gz and debug-image.tar.gz name does not change), can we ask users to provide one link to SDK? Then we try to download test-images.tar.gz and debug-image.tar.gz in get.sh.

In summary,

CUSTOMIZED_SDK_URL=URL_to_sdk.tar.gz
get.sh - try to download test-images.tar.gz and debug-image.tar.gz using the link provided. If it fails to download test-images and debug-image, print a warning and continue. Or we can have a flag make sure the script fail if there is download failure.
get.sh - handle debug image in get.sh (overlay on top of sdk) (problem 2 above)

In this way, we do not need to put the debug-image folder into the test image, as all three jars are available atm. Only one link is needed from users.

What do you think about this solution? Please let me know if I missed any scenarios.

pshipton · 2020-03-18T17:31:57Z

I like this idea, it fixes the problem that occurs for me, as I usually forget to specify the URL to the test image. Finding all the artifacts automatically and putting them in the correct places seems ideal. It keeps the debug and test images separate, which seems clearer for users.

The user still has to specify the files manually if they created a build manually and uploaded it, but I expect this is rarely done and would always require manually specifying a test image.

Note the test image at Adopt is named differently, and the name varies per build.
i.e. OpenJDK11U-testimage_ppc64_aix_openj9_2020-03-16-12-19.tar.gz

keithc-ca · 2020-03-18T17:39:42Z

Note the test image at Adopt is named differently, and the name varies per build.
i.e. OpenJDK11U-testimage_ppc64_aix_openj9_2020-03-16-12-19.tar.gz

And, following that pattern, the debug image from adopt will have -debugimage in its name; see: adoptium/temurin-build#1597.

smlambert · 2020-03-18T17:44:24Z

Yes, the fact that the builds/naming across the projects is not the same (is unfortunate and unnecessary since many of the people working at both projects could just talk/align, super annoying, but of course we will accommodate as per usual).

Agree, I think this is a 'good plan', will have to ensure that we continue to support pick up of openjdk test image artifacts and jre artifacts. If there are cases where someone wanted to pass two separate URLs from separate servers to CUSTOMIZED_SDK_URL, I am not aware of them.

keithc-ca · 2020-03-18T17:51:10Z

I too like that idea, but it assumes the server is willing to list the files in a directory; not all are configured that way, but as long as the ones we care about cooperate, we'll be good.

llxia · 2020-03-18T19:35:23Z

The jdk, jre, test image and debug image at Adopt are archived in Jenkins and we use Jenkins API to get them (i.e., we use UPSTREAM_JOB_NAME and UPSTREAM_JOB_NUMBER). We do not use url to download them in nightly builds. IMO, Adopt does not need the ability to auto-download test image and debug image. If Adopt uses Artifactory(or other server) to store artifacts, then auto-download test image and debug image is useful.
Note: As long as we detect debug image, we will overlay it on top of sdk. Adopt will get this for free.

My plan is to make sure openj9 works first. If there is a need to have auto-download in Adopt, we can update the script to support it.

smlambert · 2020-03-18T21:13:55Z

Yep, sounds good. Adopt will shortly use Artifactory (or some other off-master storage with plan to move to it after this release is finished, related: adoptium/aqa-tests#1659), but we can strongly influence how that looks so its not onerous from a QA perspective.

llxia · 2020-03-20T16:04:32Z

While working on this PR, I noticed that *.dSYM files are already in lib in regular mac SDK from OpenJ9. Is this expected? fyi @keithc-ca
bin does not contain any *.dSYM files (as expected)

Download mac SDK:

Lans-MacBook-Pro:test2 lanxia$ curl -OLJSks  https://140-211-168-230-openstack.osuosl.org/artifactory/ci-eclipse-openj9/Build_JDK11_x86-64_mac_Nightly/321/OpenJ9-JDK11-x86-64_mac-20200319-020702.tar.gz
Lans-MacBook-Pro:test2 lanxia$ mkdir ./j2sdk-image
Lans-MacBook-Pro:test2 lanxia$ gzip -cd OpenJ9-JDK11-x86-64_mac-20200319-020702.tar.gz | tar xof - -C ./j2sdk-image
Lans-MacBook-Pro:test2 lanxia$ cd j2sdk-image/jdk/lib/
Lans-MacBook-Pro:lib lanxia$ ls *.dSYM | wc -l       
     116                                        <==== *.dSYM files exist in mac jdk/lib. Is this expected?
Lans-MacBook-Pro:lib lanxia$ ls
J9TraceFormat.dat		libdt_socket.dylib		libmanagement_agent.dylib.dSYM
OMRTraceFormat.dat		libdt_socket.dylib.dSYM		libmlib_image.dylib
compressedrefs			libextnet.dylib			libmlib_image.dylib.dSYM
ct.sym				libextnet.dylib.dSYM		libnet.dylib
ddr				libfontmanager.dylib		libnet.dylib.dSYM
fontconfig.bfc			libfontmanager.dylib.dSYM	libnio.dylib
fontconfig.properties.src	libfreetype.dylib		libnio.dylib.dSYM
...
Lans-MacBook-Pro:lib lanxia$ cd /tmp/test2/j2sdk-image/jdk/bin/
Lans-MacBook-Pro:bin lanxia$ ls *.dSYM | wc -l
ls: *.dSYM: No such file or directory.           <==== no *.dSYM in mac jdk/bin as expected
       0

Download mac debug image:

Lans-MacBook-Pro:test2 lanxia$ curl -OLJSks  https://140-211-168-230-openstack.osuosl.org/artifactory/ci-eclipse-openj9/Build_JDK11_x86-64_mac_Nightly/321/debug-image.tar.gz
Lans-MacBook-Pro:test2 lanxia$ mkdir debug-image
Lans-MacBook-Pro:test2 lanxia$ gzip -cd debug-image.tar.gz | tar xof - -C ./debug-image
Lans-MacBook-Pro:lib lanxia$ cd /tmp/test2/debug-image/lib/
Lans-MacBook-Pro:lib lanxia$ ls *.dSYM | wc -l
     116                      <==== number of *.dSYM files in debug-image/lib/ matches with mac jdk/lib above

The same thing in xlinux SDK from OpenJ9. *.debuginfo files exist in lib.

Lans-MacBook-Pro:lib lanxia$ ls /tmp/test2/j2sdk-image_linux/jdk/lib/
Display all 108 possibilities? (y or n)
J9TraceFormat.dat              libawt_headless.debuginfo      liblcms.debuginfo
OMRTraceFormat.dat             libawt_headless.so             liblcms.so
compressedrefs/                libawt_xawt.debuginfo          libmanagement.debuginfo
ct.sym                         libawt_xawt.so                 libmanagement.so
ddr/                           libdt_socket.debuginfo         libmanagement_agent.debuginfo
j9vm/                          libdt_socket.so                libmanagement_agent.so
java.properties                libextnet.debuginfo            libmlib_image.debuginfo
...

Also checked Mac sdk from AdoptOpenJDK. It does not have any *.dSYM files in lib or bin. I would expect this is the ideal case.

keithc-ca · 2020-03-20T18:06:26Z

I expect the absence of debug symbols in builds from adopt is because they use configure option --with-native-debug-symbols=none; see [1].

[1] https://github.com/AdoptOpenJDK/openjdk-build/blob/master/sbin/build.sh#L275

llxia · 2020-03-20T18:46:58Z

Do we expect to see debug symbols to be in OpenJ9 builds? The current behavior is that the debugs symbols are partially in OpenJ9 builds (in lib, but not in bin)

keithc-ca · 2020-03-20T18:59:49Z

There should be debug symbols for all openj9 contributions (e.g. if jitserver is enabled, you'll see both jitserver and jitserver.debuginfo in the bin directory). On Windows, everything is in the bin directory (there are no .pdb files in the lib directory). If adopt didn't use the configure option --with-native-debug-symbols=none, you would see debug symbols for openjdk launchers and libraries.

pshipton · 2020-03-20T19:14:29Z

Seems that debug in OpenJ9 builds is expected, but it varies between jdk8 and jdk11+ atm. Also we may decide to change the OpenJ9 build defaults in the future.
I think the safest thing to do is overwrite any existing files from the debug image. On AIX this will actually replace the .so files, which is fine.
Since Adopt builds don't contain debug, adding the debug image is desired. For OpenJ9 builds it may be a noop, but it doesn't hurt.

llxia · 2020-03-20T19:27:28Z

ok, I will overlay the debug images on top of sdk regardless if the sdk has them or not.
Thanks @pshipton @keithc-ca

fjeremic · 2020-03-26T17:05:43Z

Running into this problem now over in #8992. It outputs a backtrace but it is not useful:

22:51:36  [2020-03-25 22:51:33,042] Agent[1]: stderr: ----------- Stack Backtrace -----------
22:51:36  [2020-03-25 22:51:33,042] Agent[1]: stderr: (0x000003FF9E239332 [libj9jit29.so+0x5b9332])
22:51:36  [2020-03-25 22:51:33,042] Agent[1]: stderr: (0x000003FF9E23A022 [libj9jit29.so+0x5ba022])
22:51:36  [2020-03-25 22:51:33,042] Agent[1]: stderr: (0x000003FF9E238986 [libj9jit29.so+0x5b8986])
22:51:36  [2020-03-25 22:51:33,042] Agent[1]: stderr: (0x000003FF9E23A022 [libj9jit29.so+0x5ba022])
22:51:36  [2020-03-25 22:51:33,042] Agent[1]: stderr: (0x000003FF9E238986 [libj9jit29.so+0x5b8986])
22:51:36  [2020-03-25 22:51:33,042] Agent[1]: stderr: (0x000003FF9E23A022 [libj9jit29.so+0x5ba022])
22:51:36  [2020-03-25 22:51:33,042] Agent[1]: stderr: (0x000003FF9E23F576 [libj9jit29.so+0x5bf576])
22:51:36  [2020-03-25 22:51:33,042] Agent[1]: stderr: (0x000003FF9E47E982 [libj9jit29.so+0x7fe982])
22:51:36  [2020-03-25 22:51:33,042] Agent[1]: stderr: (0x000003FF9E4FD41E [libj9jit29.so+0x87d41e])
22:51:36  [2020-03-25 22:51:33,042] Agent[1]: stderr: (0x000003FF9E4FD604 [libj9jit29.so+0x87d604])

pshipton · 2020-03-26T18:10:15Z

It outputs a backtrace but it is not useful

Ya, I think that's a whole different problem with the RAS code not being able to get the symbols. gdb should work with the debug symbols, but you may need the system libraries as well. This is what jextract collects. See #8772

- add auto download test-images and debug-images - to simplify the story, auto download will only be triggered if users provide only one CUSTOMIZED_SDK_URL and URL filename contains OpenJ9-JDK. In this way, if users want to provide multiple separate URLs or multiple separate URLs from separate servers, they can still do so and auto-download will not be triggered. - Once auto-download is triggered, by default, the flag test_images_required and debug_images_required are set to true in get.sh. If the flag is set to true, it means the script will retry if the download fails and the program will fail if all retry attempts fail (the same behavior as downloading SDK). If the flag is set to false, it means the script will not try to auto download. - In JenkinsfileBase, pass in test_images_required and debug_images_required to get.sh if users want to overwrite the flag(s) - During unzipping process, if debug-images jar is found, overlay debug-images on top of sdk j2sdk-image/jre dir if it exists. Otherwise, extracts into j2sdk-image dir Issue: eclipse-openj9/openj9#8874 Signed-off-by: lanxia <[email protected]>

llxia · 2020-03-31T19:36:09Z

PR adoptium/aqa-tests#1692 is merged. To trigger the auto download, upstream builds (openj9) should be updated to pass in only the CUSTOMIZED_SDK_URL=url_to_sdk. The script will then auto-download test-images and debug-images for OpenJ9 SDK. For sdk that does not have debug-images (i.e., zos), DEBUG_IMAGES_REQUIRED should set to false when trigger the test builds.

FYI @jdekonin @AdamBrousseau

keithc-ca · 2020-07-29T14:08:59Z

Is there anything left to be done for this?

llxia · 2020-07-29T14:45:50Z

The change in the test pipeline is completed. The upstream needs to updated to pass in only the CUSTOMIZED_SDK_URL=url_to_sdk. See #8874 (comment)

pshipton · 2020-07-29T17:09:13Z

I believe everything is completed.

pshipton added the comp:build label Mar 16, 2020

pshipton mentioned this issue Mar 16, 2020

Builds should archive debugimage archives adoptium/temurin-build#1596

Closed

fjeremic mentioned this issue Mar 26, 2020

JTReg Test Fail: sun/nio/cs/FindDecoderBugs.java #8992

Open

llxia mentioned this issue Mar 30, 2020

Auto download test-images and debug-images adoptium/aqa-tests#1692

Merged

pshipton closed this as completed Jul 29, 2020

Run testing at OpenJ9 with debug symbols #8874

Run testing at OpenJ9 with debug symbols #8874

Comments

pshipton commented Mar 16, 2020

pshipton commented Mar 16, 2020

pshipton commented Mar 16, 2020 • edited Loading

DanHeidinga commented Mar 16, 2020

smlambert commented Mar 16, 2020 • edited Loading

pshipton commented Mar 16, 2020

smlambert commented Mar 16, 2020 • edited Loading

pshipton commented Mar 16, 2020

pshipton commented Mar 16, 2020

keithc-ca commented Mar 17, 2020

keithc-ca commented Mar 17, 2020

smlambert commented Mar 17, 2020

pshipton commented Mar 17, 2020

pshipton commented Mar 17, 2020 • edited Loading

keithc-ca commented Mar 17, 2020

pshipton commented Mar 17, 2020 • edited Loading

llxia commented Mar 18, 2020

pshipton commented Mar 18, 2020

smlambert commented Mar 18, 2020 • edited Loading

llxia commented Mar 18, 2020

keithc-ca commented Mar 18, 2020

smlambert commented Mar 18, 2020

keithc-ca commented Mar 18, 2020

llxia commented Mar 18, 2020

pshipton commented Mar 18, 2020

keithc-ca commented Mar 18, 2020

smlambert commented Mar 18, 2020 • edited Loading

keithc-ca commented Mar 18, 2020

llxia commented Mar 18, 2020

smlambert commented Mar 18, 2020 • edited Loading

llxia commented Mar 20, 2020 • edited Loading

keithc-ca commented Mar 20, 2020 • edited Loading

llxia commented Mar 20, 2020

keithc-ca commented Mar 20, 2020

pshipton commented Mar 20, 2020

llxia commented Mar 20, 2020

fjeremic commented Mar 26, 2020

pshipton commented Mar 26, 2020

llxia commented Mar 31, 2020

keithc-ca commented Jul 29, 2020

llxia commented Jul 29, 2020

pshipton commented Jul 29, 2020

pshipton commented Mar 16, 2020 •

edited

Loading

smlambert commented Mar 16, 2020 •

edited

Loading

smlambert commented Mar 16, 2020 •

edited

Loading

pshipton commented Mar 17, 2020 •

edited

Loading

pshipton commented Mar 17, 2020 •

edited

Loading

smlambert commented Mar 18, 2020 •

edited

Loading

smlambert commented Mar 18, 2020 •

edited

Loading

smlambert commented Mar 18, 2020 •

edited

Loading

llxia commented Mar 20, 2020 •

edited

Loading

keithc-ca commented Mar 20, 2020 •

edited

Loading