Menu
▾
▴
#4 docheck2 test failure
Tests fail with this error:
========================================
libEMF 1.0.9: tests/test-suite.log
========================================
# TOTAL: 3
# PASS: 2
# SKIP: 0
# XFAIL: 0
# FAIL: 1
# XPASS: 0
# ERROR: 0
.. contents:: :depth: 2
FAIL: docheck2
==============
cmp: EOF on check2.emf
49 250 310
50 10 0
53 75 2
57 4 0
181 14 16
185 20 24
189 173 0
193 310 0
194 1 0
197 13 0
Related
Hey: I just downloaded, built and tested the 1.0.9 release. It works OK for me (on ubuntu 16.04 and fedora 21 64-bit anyway). Can you give me some more information about your build environment?
Thanks.
I'm on OS X 10.11, using in the built-in clang compiler. I build with the standard
./configure && make && make check. I have no copies of libemf installed that could be pulling in some outdated header or library.I'm not sure I can find such a system to test on. I'll ask around.
Meanwhile, can you attach your check2.emf file to this report? It's in the tests/ subdirectory of your build directory. It should be exactly the same as check1.emf.
Also, do check1 and check3 pass OK?
Here's check2.emf. check1 and check3 pass OK.
It's a race condition in the
make checksequence. I noticed that the output during the build had the dochecks in non-sequential order, so I added -j1 tomake checkand the tests all passed. I've repeated this 5 times each with and without -j1 (I have MAKEFLAGS defaulting to -j4) and it always fails when make has -jN > 1.OK! I can cause the same problem on linux with "make -j2 check". So, I'm at the mercy of autotools. Check2 is supposed to read the output from check1. My brief search for internet solutions didn't yield anything useful. I'll have to look into it.
Thanks for your help!
I also have the same issue.
I add here that the 'docheck2' test fails randomly for me. Sometimes it fails and sometimes it passes.
System Information:
OS: Arch Linux x86_64
Compiler: gcc 8.2.1
libEMF: 1.0.9
For what it's worth, I think I have a fix for this. I'll try to patch it up
over Christmas break.
Thanks for your reports.
On Mon, Dec 3, 2018 at 12:50 PM Daniel Bermond danielbermond@users.sourceforge.net wrote:
--
Allen Barnett
Sr Research Scientist
Varian Medical Systems
Pattersonville, NY 12137 United States
allen.barnett@varian.com
T +1.678.255.3970
varian.com
This message may contain information that is confidential or otherwise
protected from disclosure. If you are not the intended recipient, you are
hereby notified that any use, disclosure, dissemination, distribution, or
copying of this message, or any attachments, is strictly prohibited. If you
have received this message in error, please advise the sender by reply
e-mail, and delete the message and any attachments. Thank you.
Related
Bugs:
#4I guess this is fixed in 1.0.10 (and later). Thanks for the reports.
Hi Allen,
The fix broke libemf on big endian systems, see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919766 .
The attached patch tries to follow the concept of the original fix in an endian-aware way.
Please consider accepting it.
LibEMF could also make use of a test where it tries to read a sample file truncated to 0..n-1 bytes wrapped in Valgrind.
Thanks,
Balint
Hi Balint: Thank you for the patch. I see what you're getting at there. I don't have any way to test the big-endian code. I used to have a sparc-based javastation, but that has long since gone to electronics recycling. Do you have a suggestion for how I could build and test the big-endian code? Does QEMU simulate big-endian systems?
Hi Allen,
Yes QEMU can emulate big endian systems, but I have already tested it on s390x patching the current Debian package. So if you are happy with it on amd64 I think you can safely take it.