oce does not build on ppc64le aarch #559
Comments
|
IBM has created a $200 bounty on Bountysource to fix the failing test on PPC64LE Linux. |
|
Are you interested in a specific distro ? |
|
The test failure should not be distro-specific. Ubuntu is more common for Linux on PPC64LE. Thanks! |
|
I've been playing with this for the last few days, and I'm having trouble understanding what the problem is exactly. Following the instructions in INSTALL.Unix I'm able to run the following commands without any error:
When it comes down to testing however, running make test gives me the following results: Note that while the failing test is the same, the error message and number is different from the one @leitao posted. I'm able to build and install oce on my setup (with ppc64le arch), but this test keeps failing. Is it right to assume that this issue will be closed when the test is fixed, then? |
|
Are you consistently seeing the same (different) failure or does oce run the tests in a randomized order? Is the real problem some state left by a previous test? We would like to achieve clean testsuite on ppc64le. |
|
Yes, I'm consistenly seeing the following error: No randomized order. I've already performed the build proces a couple of times (with and without the flag -DOCE_TESTING:BOOL=ON) and the test order is always the same. I doubt it fails because a previous test leaving the environment unstable. At least in my case, BRepOffsetAPITestSuite.testEvolvedShape is always the first test that runs (notice that there's another test inside the same suit, and it passes). The most I've been able to do is track down the place where it blows up to this line. with on each run. If the test is run with this code, then it passes: (notice all the commented lines) And if you change that code just a little, like this: and run only this test with the following command then you get So appearently, calling throws an Standard_NotImplemented exception. I still couldn't figure out why, but I believe that's what causing the test to fail. |
|
Can you find out where it's failing within the oce runtime for the BRepOffsetAPI_MakeEvolved call? This implies that something is not implemented in the Power code, which could be a configuration failure not finding something in the math library. |
|
I'm probably reaching the limits of my technical skills right now. I'll keep trying but in the meantime here's what I could find out so far: I tried to debug the failing test using gdb. Set a breakpoint on this line and when I tried to step in, the following occurred: At that point I used the bt full command (shows the backtrace of the current thread), and this is the output: I don't have a lot of experience with gdb, but I found annoying those "optimized out" messages, so I looked around and found out that they had to do with optimization settings when compiling (gcc -O1, -O2, -O3 flags). I changed the compile flags and added -g, -O0 -fbuiltin and rebuilt the test again. The following is the output of the test run through gdb (without optimization). Now I'm even more confused than before: Note that it's a different object's vtable than before, that is, when the test was compiled with -O3. This is the new backtrace. Hope this helps. |
|
Does the testcase fail if you build the package without optimization? -O0 -g. It's a lot easier to debug without optimization. |
|
Yes. When building without optimization (-O0) the test case still fails. I'm sorry, perhaps my last post was too long and wasn't clear enough. I posted two gdb outputs, the first one corresponds to the test case compiled with -O3, and the second with -O0. |
|
The second one still shows frames that state "optimized out", so it cannot be -O0. |
|
Definitely, this looks like a compiler bug (I'm running g++ (Ubuntu 4.9.2-10ubuntu13) 4.9.2). The conflicting chunk of code is at https://github.com/tpaviot/oce/blob/master/src/Adaptor3d/Adaptor3d_SurfaceOfRevolution.cxx#L550 Here, when building with optimizations (that is, every -O* value except -O0), the call to Position() gets somehow optimized out, and Axe ends uninitialized. As a workaround, both changing the code to use a direct value instead of a reference: or referencing gp_Lin first: will do the trick. If you would consider applying one of those workarounds, please let me know and I'll generate the corresponding PR. |
|
Hello, Thank you for reporting your findings! Andrey On 07.10.2015 13:12, Sergio L. Pascual wrote:
|
|
@a-betenev You're right, the fact that this issue didn't appear when running with other compilers/platforms confused me. So, using a direct value instead of a reference is the way to go, isn't it? Should I summit a PR? |
|
@slp Yes please submit a PR if you want this bug to be fixed and merged into master before the next release. |
Replace gp_Ax1 reference with direct value. Fixes #559
Currently oce does not pass tests on new POWER architecture with the following error:
Errors while running CTest
48/48 Test #28: BRepMeshTestSuite.testMeshTorus ................. Passed 2.61 sec
98% tests passed, 1 tests failed out of 48
Total Test time (real) = 3.15 sec
The following tests FAILED:
24 - BRepOffsetAPITestSuite.testEvolvedShape (Failed)
make[1]: *** [test] Error 8
dh_auto_test: make -j8 test ARGS+=-j8 returned exit code 2
make: *** [build-arch] Error 2
Makefile:140: recipe for target 'test' failed
make[1]: Leaving directory '/«PKGBUILDDIR»/obj-powerpc64le-linux-gnu'
debian/rules:14: recipe for target 'build-arch' failed
We would like to have it ported and full building in ppc64el architecture
The text was updated successfully, but these errors were encountered: