Closed GoogleCodeExporter closed 8 years ago
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.
Original comment by schu...@gmail.com
on 5 Feb 2013 at 1:49
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
Original comment by adrp...@gmail.com
on 5 Feb 2013 at 5:35
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.
Original comment by schu...@gmail.com
on 5 Feb 2013 at 7:14
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.
Original comment by adrp...@gmail.com
on 6 Feb 2013 at 10:28
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)?
Original comment by schin...@gmail.com
on 6 Feb 2013 at 1:30
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?
Original comment by adrp...@gmail.com
on 6 Feb 2013 at 4:26
Can you try the following?
SCALARIS_CT_NAME=ct@127.0.0.1 make test
Maybe it works around your hostname issues.
Original comment by schu...@gmail.com
on 6 Feb 2013 at 10:02
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?
Original comment by adrp...@gmail.com
on 7 Feb 2013 at 1:44
SCALARIS_CT_NAME=ct@127.0.1.1 make test
gave same result (strange Debian 0.1.1 thing)
Original comment by adrp...@gmail.com
on 7 Feb 2013 at 2:15
Note: Skipped tests are fine they were deactivated by us.
Original comment by schin...@gmail.com
on 7 Feb 2013 at 3:28
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.
Original comment by schu...@gmail.com
on 7 Feb 2013 at 3:35
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.
Original comment by adrp...@gmail.com
on 7 Feb 2013 at 3:35
Hello,
why is this issue not closed? Thanks to your help, it now "works for me".
Pierre M.
Original comment by adrp...@gmail.com
on 13 Feb 2013 at 1:37
you are right - now with 537 ok, 0 failed, 10 skipped, everything seems fine
Original comment by nico.kru...@googlemail.com
on 13 Feb 2013 at 1:42
Original issue reported on code.google.com by
adrp...@gmail.com
on 5 Feb 2013 at 1:17