Export to GitHub

scalaris - issue #79

Targets for "make test" seem somewhat truncated in Makefile


Posted on Feb 5, 2013 by Grumpy Monkey

What steps will reproduce the problem? 1. try "make test". 2. see it fail. 3. look in Makefile around line 95-97.

What is the expected output? What do you see instead? The tests can't be launched. I see $(UNITTESTARGS) as the beginning of the command line (an argument, no command). UNITTESTARGS seems used without being defined. Hence bad command line.

What version of the product are you using? On what operating system? 0.5.0+svn on Linux.

Please provide any additional information below. Other targets seem to suffer the same issue. See test-with-cover.

Context: before trying to write a db_hanoidb disk backend driver, I'd like to see tests running for original scalaris ; then run them against db_hanoidb.

Comment #1

Posted on Feb 5, 2013 by Quick Horse

Please rerun configure. I guess that you get the following error message: "neither run_test nor ct_run found - on erlang < R14 consider running install.sh in the common_test directory otherwise you won't be able to run the unit tests" You need either run_test or ct_run to run the unit-tests. It depends on your Linux distribution, but in my case ct_run is part of the erlang-common_test package.

Comment #2

Posted on Feb 5, 2013 by Grumpy Monkey

Yes, you narrowed the issue, thanks for your fast response. I run R15B1. ls /usr/lib/erlang/bin/ gives me ct_run, not run_test.

I made make clean then ./configure and I see

(snip) checking for Erlang/OTP 'xmerl' library subdirectory... /usr/lib/erlang/lib/xmerl-1.3.1 checking for Erlang/OTP 'xmerl' library version... 1.3.1 checking for Erlang/OTP 'common_test' library subdirectory... /usr/lib/erlang/lib/common_test-1.6.1 checking for Erlang/OTP 'common_test' library version... 1.6.1 checking for Erlang/OTP 'edoc' library subdirectory... /usr/lib/erlang/lib/edoc-0.7.9.1 checking for Erlang/OTP 'edoc' library version... 0.7.9.1 checking for /usr/lib/erlang/lib/common_test-1.6.1/priv/bin/run_test... no checking for /usr/lib/erlang/bin/run_test... no checking for run_test... no configure: run_test not found - on erlang < R14 consider running install.sh in the common_test directory otherwise you won't be able to run the unit tests checking for Erlang/OTP 'toke' library subdirectory... not found checking for Erlang/OTP 'toke' library version... not found configure: toke erlang library not found, disabling toke support... (snip)

So I have R15 and a working Common Test (I have run it ok on another project). I thought the issue was with the Makefile. It seems rather related to configure.ac around lines 151~158. Is it supposed to work with R15?

Pierre M. in need of one more clue

Comment #3

Posted on Feb 5, 2013 by Quick Horse

Do you have by any chance an old version of configure? Before January 21st, configure would only check for run_test and give up if there is no such file. With r4349, we added an additional test for ct_run.

You mentioned that the checks are around lines 151~158. But in the most recent version, they are on lines 151~167.

Please run: svn up configure configure.ac ./configure This should hopefully fix your problem.

Comment #4

Posted on Feb 6, 2013 by Grumpy Monkey

Hello,

yes, you are right: svn up configure configure.ac gave me revision 4466 of those files and now after ./configure the target of "make test" has a nice /usr/lib/erlang/bin/ct_run as a command. Yeah ! Thanks.

Unfortunately after "make clean" and "make" (which ran ok) "make test" still has some issue : /usr/lib/erlang/bin/ct_run -name ct -pa pwd/ebin pwd/test pwd/contrib/yaws/ebin pwd/contrib/log4erl/ebin -spec test/scalaris.runtests-default.cfg -ct_hooks scalaris_cth -noshell | tee ct.log ; \ grep " 0 failed" ct.log {error_logger,{{2013,2,6},{11,7,32}},"Can't set long node name!\nPlease check your configuration\n",[]} {error_logger,{{2013,2,6},{11,7,32}},crash_report,snip...

Aren't those pwd funny ?-) I did a whole svn update (I'm now with 4466 scalaris wide, not just configure) and I tried: make clean (ok) make (ok) time /usr/lib/erlang/bin/ct_run -name ct -pa ./ebin ./test ./contrib/yaws/ebin ./contrib/log4erl/ebin -spec test/scalaris.runtests-default.cfg -ct_hooks scalaris_cth -noshell | tee ct.log ; \ grep " 0 failed" ct.log

but I got the same result: {error_logger,{{2013,2,6},{11,17,46}},"Can't set long node name!\nPlease check your configuration\n",[]} {error_logger,{{2013,2,6},{11,17,46}},crash_report,snip...

In test/scalaris.runtests-default.cfg I don't see anything about node names, nothing about length of node names.

I newbiely think I still have an issue with "configure" (because of the pwd in the Makefile) and I'm lost with the "long node name" error message. Thank you for your assistance so far. I hope you have another clue to help me go forward on "make test".

Pierre M.

Comment #5

Posted on Feb 6, 2013 by Grumpy Horse

Does bin/scalarisctl checkinstallation run without errors or gives you some hints what the problem may be?

Does 'hostname -f' on your machine result in a full qualified domain name (foo.bar.com) and not only in a hostname (foo)?

Comment #6

Posted on Feb 6, 2013 by Grumpy Monkey

Seems you are right again (hostname issue?)

bin/scalarisctl checkinstallation outputs: Running basic tests... INFO: could not find Scalaris' Java-API files. You won't be able to use the 'scalaris' command line script to access Scalaris. 'make java' will build the Java-API We were trying to run: /home/(snip)/DBMS/scalaris/scalaris-read-only/java-api/scalaris --noconfig -h Running Scalaris run-time tests... NOTE: yaws port not specified. Python, Python3, Ruby API tests may fail if the port is different in one of the config files. Java-API ... NOT INSTALLED Python-API ... SUCCESS Python3-API ... NOT INSTALLED Ruby-API ... SUCCESS

(I had not "make java" or anything else, only "make". I only do erlang scalaris).

hostname -f give only one word(foo), not a F.Q.D.N (foo.bar.org). There is something localy wrong here on my (Debian Testing) system. But it doesn't prevent me to run several nodes (n1 to n5)@127.0.0.1 to setup a scalaris cluster. Is there a similar way to give "localhosty" names for ct_run to launch ok?

Comment #7

Posted on Feb 6, 2013 by Quick Horse

Can you try the following? SCALARIS_CT_NAME=ct@127.0.0.1 make test Maybe it works around your hostname issues.

Comment #8

Posted on Feb 7, 2013 by Grumpy Monkey

Yes, thanks, SCALARIS_CT_NAME=ct@127.0.0.1 make test makes things better. ct_run has run for more than 15 minutes and I got HTML reports. Here is the end of the console output: Testing scalaris.scalaris-read-only: TEST COMPLETE, 80 ok, 26 failed, 383 skipped of 489 test cases

Updating /home/(snip)/DBMS/scalaris/scalaris-read-only/index.html... done Updating /home/(snip)/DBMS/scalaris/scalaris-read-only/all_runs.html... done

make: * [test] Erreur 1

I often see such things in the console: 2013-02-07 14:16:12.468 Trying to build Scalaris with ids

=ERROR REPORT==== 7-Feb-2013::14:16:12 === Error in process <0.3610.0> on node 'ct@127.0.0.1' with exit value: {badarg,[{gen_component,start,5,[{file,"src/gen_component.erl"},{line,373}]}]}

In index.html I see: Ok=80 Failed=26 Skipped(User/Auto)=383(10/373) Missing Suites=0 Node=ct@127 (NOT ct@127.0.0.1)

In suite.log.html for SKIPPED (orange) lines I see "init_per_suite failed" or "init_per_testcase timed out" or "init_per_testcase failed" or "init_per_suite timed out" comments (or "ignore benchmarks" or some other messages). The last line of that big table is: TOTAL 1174.197s FAILED 80 Ok, 26 Failed, 10 Skipped of 116

How can we diagnose those failed/timeout inits to have less tests skipped?

Comment #9

Posted on Feb 7, 2013 by Grumpy Monkey

SCALARIS_CT_NAME=ct@127.0.1.1 make test gave same result (strange Debian 0.1.1 thing)

Comment #10

Posted on Feb 7, 2013 by Grumpy Horse

Note: Skipped tests are fine they were deactivated by us.

Comment #11

Posted on Feb 7, 2013 by Quick Horse

Every time you run the unit-tests Erlang will create a directory for the log- and html-files. The directory's name is something like ct_run.ct@127.0.0.1.2013-.... Could you send me a copy of this directory (if you click on schuett, you can get my email address)? We are wondering which tests fail and whether we can see a pattern.

Does your loopback-device support 127.0.0.1 as well as 127.0.1.1? Or is it only one of them? Unfortunately, I am not that familiar with Debian.

Comment #12

Posted on Feb 7, 2013 by Grumpy Monkey

Hello again, I have made clean, svn update, rerun configure and make. ct@127.0.0.1 seems incorporated now and "make test" has same numerical results (80 Ok, 26 Failed, 10 Skipped of 116). But good news, read on.

In ct.log I also see: 2013-02-07 15:35:04.545 Starting unittest [{current,{api_json_SUITE,init_per_suite}}, {successful,0}, {failed,0}, {skipped,{0,0}}, {total,0}]


2013-02-07 15:35:04.563 unittest_helper:make_ring size 4


2013-02-07 15:35:04.665 [error] [ CC ] can't listen on 14195: eaddrinuse


2013-02-07 15:35:04.666 [error] Error: exception error:function_clause in comm_acceptor:init/2: [{prim_inet,sockname,[abort],[]}, {comm_acceptor,init,2,[{file,"src/comm_layer/comm_acceptor.erl"},{line,51}]}]


2013-02-07 15:35:04.666 [error] Error in process <0.1329.0> on node 'ct@127.0.0.1' with exit value: {function_clause,[{comm_acceptor,init,2,[{file,"src/comm_layer/comm_acceptor.erl"},{line,62}]}]}

I investigated this eaddrinuse with netstat. There wera losts of old BEAM process there. killall epmd and killall beam.smp helped to clean. After this pretesting cleanup, "make test" was much better: Testing scalaris.scalaris-read-only: TEST COMPLETE, 537 ok, 0 failed, 10 skipped of 547 test cases

Yeah! Thanks for the working update. And congrats to all test writers: nice job.

Little suggestion by the way: ERL_EPMD_ADDRESS=127.0.0.1 if it makes sense.

Pierre M.

Comment #13

Posted on Feb 13, 2013 by Grumpy Monkey

Hello,

why is this issue not closed? Thanks to your help, it now "works for me".

Pierre M.

Comment #14

Posted on Feb 13, 2013 by Swift Lion

you are right - now with 537 ok, 0 failed, 10 skipped, everything seems fine

Status: Fixed

Labels:
Type-Defect Priority-Medium