-
Notifications
You must be signed in to change notification settings - Fork 47
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
cannot pass unit test in s390x #323
Comments
We have had errors on s390x before (#226 and #227). The text in those issues indicate that they are fixed but they are not closed, I suppose we waited to get feedback on if it was really fixed with the PR that those issues refer to. Could you perhaps figure out if the error output from the failing tests are the same? (I don't have any s390x to try it on ;-) |
root@debian:/build/cgreen-1.6.2/build# ctest --rerun-failed --output-on-failure
|
Are you sure that this is the first error message shown? This looks like either a failed build of the library (libcgreen) or a failure to find it at dynamic load time (shared libraries are loaded at runtime). The build script assumes that on Linux the extension for a shared library is |
I also noticed the error. I tried "amd64" again with the same build procedure. "amd64" passed the test. I have no idea at this moment. I think this needs a deeper look ... |
Looks like the library was built with the wrong name, 1.6.1 instead of 1.6.2. I'm not sure this should make a difference, but I don't know the look-up rules for shared libraries. Can you try to rename it and see if that fixes it? I'll have a look in the build scripts to see if I missed something when bumping to 1.6.2. |
Thanks for the prompt reply! Unfortunately, the result is the same.
|
Sorry ... I think I see merge mistakes on my side. I will fix it and run the test again. Apologize for taking your time ... |
No problem. (crossing fingers...) |
I think I merge the code correctly, but the result looks the same. debian source code: https://salsa.debian.org/gavinlai-guest/cgreen
|
One strange thing: why is there only 4 tests? When I run Can you try the following command in the Cgreens build/test directory:
If that fails with the same message as above ("error while loading shared libraries: libcgreen.so.1"), try
If any of those ends with a line something like
then there is something wrong with how this environment looks up shared libraries that are different from "normal", or |
Thanks for your prompt reply.
|
So, with the LD_LIBRARY_PATH set it loads the library correctly and passes all test in that suite. Again, I suspect that the environment in which the Cgreen tests are run are not set up correctly (= same as on other machines) wrt. how shared libraries are found and loaded. If it were the tests would pass. Do you use CMake to build and run the tests? Do you know if that's the same version as on other machines? Is it only on s390 it fails? And succeeds on all other architectures? Sorry, I don't know what else to suggest, apart from blaming CMake or the OS. |
I've uploaded the 1.6.2 version to the experimental distribution. The build results of every architecture are listed at https://buildd.debian.org/status/package.php?p=cgreen&suite=experimental Not all the build statuses are completed at this moment. At least "s390x", "powerpc" and "ppc64" indicate some testing failure. You can get the detailed build log by clicking the text in the "Status" column. I also found that the information on this web page may be helpful: https://wiki.debian.org/ArchitectureSpecificsMemo It is very welcome to share any thoughts from your side : ) |
Thanks for that page! Could you paste the indicated log file ( (Edited this comment, since the previous one was a red herring and would not have given any new information, sorry if you did read it before I did that...) |
Or... can you check if the output in the log file contains something like this as the error output for the failing test:
If it does, I might have a clue to why the tests fail. |
Ignore that. Looking at completely wrong things... |
Based on my knowledge, the buildd does not keep the data. So, I am considering uploading a second revision to experimental distribution to collect the information for debugging. I would like to Thanks! |
Nothing that comes to mind at this point. Maybe after seeing the logs ;-) |
I have uploaded the second revision (1.6.2-1~exp2) to experimental distribution: https://buildd.debian.org/status/package.php?p=cgreen&suite=experimental This is the log of s390x: https://buildd.debian.org/status/fetch.php?pkg=cgreen&arch=s390x&ver=1.6.2-1%7Eexp2&stamp=1695568441&raw=0 |
Thanks. It looks like all the actual tests passed. The suspicius and the lines that fails the run is
|
Do test case 3 & test case 6 actually pass the test? The summary indicates two of the test cases fail
|
Yeah, sorry. I was scrolling on my phone and missed the actual output from running those two tests. The 46th and 47th hit on "fail" in the log are actual fails. There is very little output. I'll dig further when I get home. |
Those two tests both somehow signal failure. If you search for They both generate the test results in XML-output in files called TEST-*.xml. That's why they are, and should be, as silent as they are. No output on the console. So why do they fail? I have no idea. I've ran the exact same command on Linux x86-64 and MacOS arm64 and get no errors or return codes indicating anything. I've also ran they under In my environments the generated files from those tests, The only thing I can think of right now is to get the content of those XML-files using I noticed that those two tests also fail on PPC64, Sparc64 and PowerPC. On PowerPC there was additional failures on two other tests, all which are actually the same suite of tests, just compiled with C resp. C++ and run either as a compiled executable or dynamically loaded library. The PowerPC output indicates, the To test this last theory (guess, really...) we could disable the
change that to
|
The following are the messages I found in my qemu environment
Another piece of information is that the bugzilla 2068898 – cgreen's test fails on s390x (redhat.com) maybe state the same observation. I have not studied whether the "capture" feature is architecture-dependent. Feel free to give any feedback : ) |
Thank you very much! Finally something to go on. I'll investigate. |
The code for the "capture parameter" feature might be sensitive to architecture differences. The sensitive code is this line (611 or there about, in
It assumes that it is possible to save the address to a local variable (in this case in the test), and the size of that variable, ( The problematic part here is that the type of the actual value is not known so the code uses If For example if When an
and copying 4 bytes from this to the local I'll have to figure out how to handle this. Meanwhile, we could disable this test and document the fact that |
I managed to add an s390x architecture to the Travis CI and it failed with the expected output, so that's a good step (and we will never have an "s390x problem" surprising us again...). Now for a fix... |
Ok, so the commit e014a7a should fix the problem. You actually only need the part in How do you want to proceed from here? Take the patch and see if the other builds (PowerPC, ppc64 and Sparc64) also pass? There's a chance that they will, since they also are, at least basically, bigendians. |
Thanks for the great work! I also double-checked the cgreen with commit (e014a7a). It passed test case 3 and test case 6. So, I think we can close this issue : ) Regarding PowerPC, ppc64, and Sparc64, it seems debootstrap does not support these architectures. Maybe it is because they are not official support [1]. I cannot locally build the environment for testing. I plan to upload a version with the commit (e014a7a) to the 'unstable' distribution because all the official supported architectures can pass the test. A patch in Debian or a newer version release from this upstream is acceptable to me. |
There is now a new release, 1.6.3, available. |
The error starts from 1.5.1 because it was reported here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1038145.
Unfortunately, 1.6.2 gets more errors for s390x
The text was updated successfully, but these errors were encountered: