that is just a waste of log space.
Reviewed-by: Stefan Schmidt <stefan@datenfreihafen.org>
Differential Revision: https://phab.enlightenment.org/D11297
asan is most unhappy about using a priori stack frame's data for
this.. it seems check uses the char * buf directly as-is without
duplicating it... so we can't sensibvly use local stack data. that is
what asan is saying... and this makes our tests not work under asan to
begin with... nto to mention other possible issues i have yet to see
as i got to this one first.
Summary:
* some variables were defined, only when fork() was available
* since Eina.h is included unconditionally, add Eina path in Makefile_Evil.am
Test Plan: compilation
Reviewers: zmike, cedric, raster, devilhorns
Reviewed By: zmike
Subscribers: #reviewers, #committers
Tags: #efl_build
Differential Revision: https://phab.enlightenment.org/D8586
windows means HAVE_FORK is false... thus missing eina.h and now we
have macros that use eina calls always... so this fixes nbuild of
tests on windows
@fix
Summary:
sometimes it is not enough to just disable aborting on critical error
messages. Sometimes it is better to explicitly expect an error, and fail
the testcase if there is no error.
This is used in later commits here.
Depends on D8417
Reviewers: YOhoho, segfaultxavi, zmike, woohyun, Jaehyun_Cho
Reviewed By: zmike
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D8519
The timeout_reached bool is only used in this function when HAVE_FORK is
available. This is not the case on windows. Eina.h would only be
included with fork available so the Eina_Bool type causes a compilation
fail on windows. Guarding them as the other parts of the function using
it solves the problem.
Reviewed-by: Vincent Torri <vincent.torri@gmail.com>
Differential Revision: https://phab.enlightenment.org/D7947
Summary:
(1) EFL_START_TEST(TEST_NAME) is defined as follows if you are using
the 0.12.0 check:
START_TEST(TEST_NAME) \
_timing_start();
(2) START_TEST(__testname) is defined as follows
(To make it simple I am using 'blah-blah' here):
static void __testname_fn (blah-blah);\
static const TTest __testname_ttest = { blah-blah };\
static const TTest * __testname = & __testname_ttest;\
static void __testname_fn (blah-blah)
For example we are using as follows in a test case:
EFL_START_TEST(evas_object_smart_paragraph_direction)
{
...
}
EFL_END_TEST
This made a build error.
Test Plan: make check
Reviewers: Hermet, zmike
Reviewed By: Hermet
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6969
if a test is continually deadlocking then it's useful to know which
test is failing to complete
Differential Revision: https://phab.enlightenment.org/D6785
some tests manage to deadlock themselves on travis, seemingly due to some
hard to reproduce issues which are a result of the extremely low amount of
resources available on travis builds
this adds a simple 'timeout' process which does nothing but sleep(60);
and then returns. the exiting of this process will cause the main test
process to break out of the deadlock and then exit instead of timing out
a ci build
Differential Revision: https://phab.enlightenment.org/D6697
Summary:
the exit status value is not valid unless the process has terminated normally
by calling exit() or _exit(), so only use the status if this is true. otherwise
mark the process as a failed test
Depends on D6597
Reviewers: ManMower
Reviewed By: ManMower
Subscribers: cedric, #committers
Tags: #efl_tests
Differential Revision: https://phab.enlightenment.org/D6600
this is mostly fine to thrash the cpus on beefy desktop computers, but
it completely destroys travis's wimpy 2cpu/2gb ram configurations and causes
all the tests to fail
instead, restrict forking to the number of cpus detected and wait until a fork
exits before beginning a new one
ref T7151
Differential Revision: https://phab.enlightenment.org/D6597
Summary:
now that eldbus tests can safely run in parallel there is no reason to
prevent them from doing so
fix T6848
Depends on D6204
Reviewers: stefan_schmidt, cedric, ManMower, devilhorns
Reviewed By: cedric, ManMower
Subscribers: cedric, #committers
Tags: #efl
Maniphest Tasks: T6848
Differential Revision: https://phab.enlightenment.org/D6205
in many cases, a test will intentionally trigger an error to verify that it
is handled correctly. when the test is manually run with EINA_LOG_ABORT set,
this may cause the test to abort, preventing further debugging. by wrapping
intentional cases where critical errors are triggered, debugging tests
becomes easier
ref T7002
Differential Revision: https://phab.enlightenment.org/D6269
Summary:
avoid having lines from the main pid repeated in forks
Depends on D5963
Reviewers: stefan_schmidt
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D5964
Summary:
this was only a temporary measure
Depends on D5916
Reviewers: stefan_schmidt
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D5937
Summary:
this is buggy somehow and prints its info a few dozen times, likely
taking longer to print the info than to run the actual test
Depends on D5879
Reviewers: stefan_schmidt
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D5880
Summary:
check does not internally do any parallelizing and is impossible to use
with threads, so using fork appears to be the only viable option for
using more cpu without radically redesigning all existing tests
ref T6825
ref T6848
Reviewers: stefan_schmidt
Subscribers: cedric
Maniphest Tasks: T6848, T6825
Differential Revision: https://phab.enlightenment.org/D5877
individual tests should not need to explicitly call init/shutdown functions
in most cases, and many did not properly do this anyway
see followup commit which resolves some issues with eina tests
ref T6813
ref T6811
Reviewed-by: Stefan Schmidt <stefan@osg.samsung.com>
efl_check.h must be included and the EFL_START/END_TEST macros must be
used in place of normal START/END_TEST macros
timing is enabled when TIMING_ENABLED is set
https://phab.enlightenment.org/w/improve_tests/
Reviewed-by: Stefan Schmidt <stefan@osg.samsung.com>