Systems Biology Markup Language (SBML) / libSBML / #393 tests fail on arm

Frank Bergmann - 2014-12-16

Unfortunately I don't have an arm machine available for testing. So I cannot do any testing myself on this. However, it is not out of the question that you are running into a stack issue here (so if you could try to change the --main-stacksize, that would help). Could you please re-run the tests after having set the envrionment variable:

export CK_FORK=no

this will tell libcheck to not spawn several processes to run the tests. Which will help us to get more detailed information about what is going wrong.

It could also be that your machine would run out of memory, the code right now does not check for failing allocations. How much memory does the chromebook have?

thanks
Frank
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Zbigniew Jędrzejewski-Szmek - 2014-12-16

I don't think that's the problem. It has 2GB RAM (approx 1.7 GB free). In this regards it's not that much different from a normal notebook a few years old.

CK_FORK=no makes the test suite run faster (37 s vs 61 s), but does not change which tests fail.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Frank Bergmann - 2014-12-16

I was hoping that we would get more information about line numbers, but if you say that they are the same as before, then that would not work.

Other things to try would be to change the ld flags to increase the stack (maybe -Wl,--stack,4194304)

Frank

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Zbigniew Jędrzejewski-Szmek - 2014-12-16

--stack is x86 only, according to the man page.

I used -Wl,-z,stack-size=4194304, and bumped ulimit -s, this causes no difference.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Zbigniew Jędrzejewski-Szmek - 2014-12-16

Here are some instructions to start an arm Fedora21 instance in qemu virtualization: https://fedoraproject.org/wiki/User:Zbyszek/arm-vexpress-a15.
They are a simplified version of Fedora QA instructions. This is not very fast, but should suffice to test libsbml.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Sarah Keating - 2015-01-21

Apologies for the delay in looking at this. I have finally got a fedora instance running under qemu and can replicate the issues you have listed.

So I can start to address these - but when you said "not very fast" you were not joking

Thanks

Sarah

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Sarah Keating - 2015-02-04

Hi

I think I may have found the issue. Attached is a patch that certainly fixes the fails in the core libsbml. I have not tried it yet with packages or python and since it will take me some hours to build and test I thought I would supply the patch so you could test it.

I do have the strange anomaly that ctest reports that test_sbml_units fails but when I run ctest -V to get more information they apparently pass!!

If you get a chance to test this it would be great to hear any feedback.

Thanks

Sarah

libsbml.patch

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Indeed it seems to help a lot:

/usr/bin/ctest --force-new-ctest-process 
Test project /builddir/build/BUILD/libSBML-5.11.0-Source/build
      Start  1: test_sbml_package_render_run
 1/29 Test  #1: test_sbml_package_render_run ......   Passed    3.17 sec
      Start  2: test_comp_extensions_run
 2/29 Test  #2: test_comp_extensions_run ..........   Passed    1.39 sec
      Start  3: test_comp_sbase_run
 3/29 Test  #3: test_comp_sbase_run ...............   Passed    0.32 sec
      Start  4: test_comp_util_run
 4/29 Test  #4: test_comp_util_run ................   Passed   12.94 sec
      Start  5: test_comp_validator_run
 5/29 Test  #5: test_comp_validator_run ...........   Passed    2.19 sec
      Start  6: test_extension_package_qual_run
 6/29 Test  #6: test_extension_package_qual_run ...   Passed    0.14 sec
      Start  7: test_sbml_package_qual_run
 7/29 Test  #7: test_sbml_package_qual_run ........   Passed    0.34 sec
      Start  8: test_qual_validator_run
 8/29 Test  #8: test_qual_validator_run ...........   Passed    0.67 sec
      Start  9: test_sbml_package_fbc_run
 9/29 Test  #9: test_sbml_package_fbc_run .........   Passed    0.17 sec
      Start 10: test_fbc_validator_run
10/29 Test #10: test_fbc_validator_run ............   Passed    0.46 sec
      Start 11: test_sbml_package_layout_run
11/29 Test #11: test_sbml_package_layout_run ......   Passed    2.01 sec
      Start 12: test_layout_validator_run
12/29 Test #12: test_layout_validator_run .........   Passed    2.83 sec
      Start 13: test_sbml_annotation_run
13/29 Test #13: test_sbml_annotation_run ..........   Passed    1.35 sec
      Start 14: test_sbml_conversion_run
14/29 Test #14: test_sbml_conversion_run ..........   Passed    1.64 sec
      Start 15: test_sbml_extension_run
15/29 Test #15: test_sbml_extension_run ...........   Passed    0.15 sec
      Start 16: test_sbml_math_run
16/29 Test #16: test_sbml_math_run ................   Passed    5.32 sec
      Start 17: test_sbml_sbml_run
17/29 Test #17: test_sbml_sbml_run ................   Passed    9.81 sec
      Start 18: test_sbml_units_run
18/29 Test #18: test_sbml_units_run ...............   Passed    2.99 sec
      Start 19: test_sbml_util_run
19/29 Test #19: test_sbml_util_run ................   Passed    0.12 sec
      Start 20: test_sbml_validator_run
20/29 Test #20: test_sbml_validator_run ...........   Passed   11.57 sec
      Start 21: test_sbml_xml_run
21/29 Test #21: test_sbml_xml_run .................   Passed    0.61 sec
      Start 22: test_csharp_bindings
22/29 Test #22: test_csharp_bindings ..............   Passed    1.99 sec
      Start 23: test_csharp_bindings_full
23/29 Test #23: test_csharp_bindings_full .........   Passed    4.19 sec
      Start 24: test_java_binding
24/29 Test #24: test_java_binding .................   Passed    5.39 sec
      Start 25: test_perl_binding
25/29 Test #25: test_perl_binding .................   Passed   27.52 sec
      Start 26: test_octave_binding
26/29 Test #26: test_octave_binding ...............   Passed   44.56 sec
      Start 27: test_python_binding
27/29 Test #27: test_python_binding ...............   Passed    7.14 sec
      Start 28: test_ruby_binding
28/29 Test #28: test_ruby_binding .................***Exception: Other  4.03 sec
      Start 29: test_r_binding
29/29 Test #29: test_r_binding ....................   Passed    6.70 sec
97% tests passed, 1 tests failed out of 29
Total Test time (real) = 161.87 sec
The following tests FAILED:
     28 - test_ruby_binding (OTHER_FAULT)

Thanks!

Zbigniew Jędrzejewski-Szmek - 2015-02-04

For reference, full log is at https://kojipkgs.fedoraproject.org//work/tasks/8558/8818558/build.log.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Frank Bergmann - 2015-02-05
  
  I'm afraid the log is not accessible to me ( I receive a 404 when trying to access it). Could you let us know what the 'other' exception of the ruby binding is? Thank you:
  
  ctest -V -R test_ruby_binding
  
  thank you
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
  - Zbigniew Jędrzejewski-Szmek - 2015-02-06
    
    Sorry, I forgot that the failed builds go away quickly. New set with the patch:
    
    s390, s390x: http://s390.koji.fedoraproject.org/koji/taskinfo?taskID=1723766 → OK
    
    arm64: http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=2871009 → OK
    
    ppc64, ppc64le: http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=2318140
    This is strange. The build works, the tests pass, but there's a mismatch in the docs package:
    
    BuildError: mismatch when analyzing libsbml-docs-5.11.0-9.fc22.noarch.rpm, rpmdiff output was: removed /usr/share/doc/libsbml/cpp-api/search/defines_f.html removed /usr/share/doc/libsbml/cpp-api/search/defines_f.js
    
    arm, amd64, i386: http://koji.fedoraproject.org/koji/taskinfo?taskID=8837245 → OK
    
    So the ruby failure on arm is either intermittent, or was dependent on the environment and was already fixed. I'll try to do some more rebuilds on arm, and if things fail I'll complain. I think this can be considered fixed for now.
    
    If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Frank Bergmann - 2015-02-06

Thanks for letting us know, please do not distribute the documentation generated by the CMake process yet. Generating the API docs has not been fully ported from the gnumake build system. As such the CMake generated docs are not of sufficient quality to be distributed.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Sarah Keating - 2015-02-06

The fix is now in svn.

Note it is slightly different from the patch attached here as we restricted the changed datatype to signed char rather than long that was in the patch. It still works for me.

Thanks for all the feedback.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Sarah Keating - 2015-02-06

status: open --> closed

Priority: -->
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

tests fail on arm

A file format for exchanging computational models in systems biology

Version

Priority

Searches

Help

#393 tests fail on arm

Discussion