"No messaging setup" in START_TEST #18
Comments
|
Thanks for coming up with a minimal example to work from! I've forked the example and got it building for both Linux and OSX in this branch. What I've found is that the issue does not occur using Check 0.10.0. That is, if Check 0.10.0 was installed before tests were run either using apt (for Linux) or brew (for OSX) the test suite in question will compile and fail in the expected way: I attempted to use a locally built version of Check to reproduce the issue. At first I used the latest version of Check. My first attempt did find the "no messaging setup" issue, but only on Linux; OSX does not hit the issue. However, I realized that Check was still being installed prior to building it locally. To remove the possibility that the wrong version was being used, I then attempted to not install Check and only build locally. Using both revision 0.10.0 and the latest master branch, the issue did not occur. Note though that when building locally I needed to make the following adjustments to the Makefile for the unit tests: Namely, I used the dynamically built library which was locally built instead of the static library which is available on Ubuntu. This build shows building the latest Check locally, linking using -lcheck, and the test failing in the expected way. This was the .travis.yml configuration script which was used. I do not know the root issue, as I've not seen the issue locally and cannot poke around in detail. However, I wonder about two things:
If you are up for it, could you attempt to update the configure.ac and Makefile.am files to leverage pkg-config more and see if the issue still happens using either a version of Check built locally or the Ubuntu provided static library? |
|
It's uncommon (in my experience) that the installation from source requires manual adjustment (see https://travis-ci.org/krichter722/check-no_messaging_setup-issue/builds/119692062 without Ubuntu-provided The fix works with 0.10.0-69-g82cdb29 (see https://travis-ci.org/krichter722/check-no_messaging_setup-issue/builds/119725269) (had to add |
I'm not really sure. It appears this is what Ubuntu choose to name the Check library when it was build statically.
It seems to be that the issue is how the linker dependencies are generated. When the static library is used (check_pic) additional dependencies are necessary which were missing from the Makefile. pkg-config should report the necessary flags. Why the "no messaging" issue can occur is still a mystery to me. |
|
I still have a lot of trouble with the reproduction of I'm not very good with autotools and couldn't figure out a bunch of compilation errors which made me add a lot of extranous files to the (no longer) minimal example. |
|
I've had such an issue, too. It comes from build (execute) folder permissions. I didn't had rights to create files while running tests. And I've figured out what is wrong not so fast... I've quickly checked the code and |
|
I think that the open_tmp_file() function attempts to open a temporary file in one of several different places. If the system does not have mkstemp() defined (e.g. Windows) then tempnam() is used. This results in the following heuristic for determining where to put the temporary file:
For system with mkstemp() defined (e.g. Linux) the following heuristic is used:
This could be updated to better map with what Windows would do. Namely, check if TMPDIR is defined first, then fallback to TEMP, then use the current directory. |
|
@krichter722, could you see if the change in the following merge request resolves the issue you are seeing? |
|
I've checked on my system, TMPDIR is not set. But |
|
I'll add a check for |
|
A fix for the permission issue has been merged. Kindly re-test to determine if it resolves the issue. |
|
Due to no response after a fix has been submitted, I'll close this issue. If the issue is not resolved in the master branch, let me know. |
|
Hi, I appear to be getting a similar error when attempting to build the When asked to view the |
|
From what was found in the past this appears to be a permissions issue with
where the tests attempt to create temporary files. Changes which help the
tests find a more suitable temporary location are committed but do not yet
appear in a release. You may be able to get around this by setting the TEMP
environment variable to a location which is writable, perhaps /tmp .
…On Sat, Apr 29, 2017 at 4:11 PM, Earnestly ***@***.***> wrote:
Hi, I appear to be getting a similar error when attempting to build the
libinput <https://cgit.freedesktop.org/wayland/libinput> project.
When asked to view the tests/test-suite.log file I find the "No messaging
setup" message which appears to be causing the tests to fail:
=========================================
libinput 1.7.0: test/test-suite.log
=========================================
# TOTAL: 3
# PASS: 2
# SKIP: 0
# XFAIL: 0
# FAIL: 1
# XPASS: 0
# ERROR: 0
.. contents:: :depth: 2
FAIL: libinput-test-suite-runner
================================
check_msg.c:80: No messaging setup
FAIL libinput-test-suite-runner (exit status: 2)
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
<#18 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AFBUl5_d9Jj33ONydv9P8kM21bE81zGkks5r05ltgaJpZM4HVL1D>
.
|
|
Ah, when I submit bug reports I try to make sure I'm using the latest code, in this case the check I'm using is from 24e3067. If the committed code you're refering to is elsewhere I can try that too, but from the master branch this issue still seems present. Nevertheless I've tried setting |
|
Just to update that the issue is still present on ce7da2b |
|
You should be running with the change I was referring to then. The change is here, which setups a file on the file system for passing data between the process which is running a single test and the parent process which is waiting for the result. If this is a permission issue, I've a change here which will stop the tests when the tmp file creation fails, instead of slightly later on. If the tests on that change pass, it may be worth giving it a shot to see if that condition is it. If it is hit, then the algorithm for determine a tmp directory is finding a directory where a file cannot be created. This algorithm is: It may also be interesting to strace a test, to see where it is trying to create a tmp file and why it is failing. For example, on my system running tests successfully produces the following trace: That is, a tmp file is created for storing a test result, then fork() is called to create a child process to run the test. |
|
I've gone and attempted to get some strace messages and something even stranger appears to be happening: Here is the full strace: |
|
Does this mean that Check is determining that /run/udev/rules.d is a suitable tmp directory? But, the call that Check should be making, mkstemp, will not create a directory and will fail if the directory does not exist. There is no explicit mkdir in Check, so I am curious as to what is making the call and why. Do you know the environment of the unit test? Namely, do you know if TEMP are defined and what they are, and what PWD is? Can you point me to what revision of libinput this is occurring on? May I can try to reproduce it myself. |
|
@Earnestly As I see you test libinput? So may it be that some function that being tested is trying to create directory in "/run/udev/rules.d" without root permissions (and so it fails)? |
|
@9fcc Yes, that is what's happening and why it ultimately fails. The code appears to print a useful error message but it is never seen. I think the issue now is how check handles these cases as the current message isn't very helpful. |
|
OK, I think I understand the issue now. It is a question of API usage, I believe. The Check assertion calls are valid when a test or a setup/teardown function is being run. Outside of these times the behavior of the assertions is undefined. Looking at the source for libinput 1.7.2 I see the following: where srunner_run(), which runs the tests with Check, is invoked in litest_run_suite() or litest_fork_subtests(). However, litest_init_udev_rules() contains the following: Note the ck_abort_msg calls. As the litest_init_udev_rules() function is not being executed within the context of Check, the call behavior is not defined. When they are called outside of running tests in Check they attempt to communicate to the process which started the test (of which there is none). Given this, the message which is reported from Check, namely |
|
Refer to the following for the updated error message: #123 |
|
Ah thank you very much for looking into this. I wasn't clear at all, but indeed it seems to have become an API usage question when we realised it not displaying the expected diagnostic messages as you explained. The proposed PR #123 provides a better message which should help directing maintainers or developers to the source of the problem. |
ck_assert can only be called while a test is running. See libcheck/check#18 and libcheck/check#123 There was a race condition where the server loop tried to lock the mutex and assert the return value, although the tests already finished. Fixes #2331
ck_assert can only be called while a test is running. See libcheck/check#18 and libcheck/check#123 There was a race condition where the server loop tried to lock the mutex and assert the return value, although the tests already finished. Fixes #2331
ck_assert can only be called while a test is running. See libcheck/check#18 and libcheck/check#123 There was a race condition where the server loop tried to lock the mutex and assert the return value, although the tests already finished. Fixes #2331
ck_assert can only be called while a test is running. See libcheck/check#18 and libcheck/check#123 There was a race condition where the server loop tried to lock the mutex and assert the return value, although the tests already finished. Fixes #2331
ck_assert can only be called while a test is running. See libcheck/check#18 and libcheck/check#123 There was a race condition where the server loop tried to lock the mutex and assert the return value, although the tests already finished. Fixes #2331
ck_assert can only be called while a test is running. See libcheck/check#18 and libcheck/check#123 There was a race condition where the server loop tried to lock the mutex and assert the return value, although the tests already finished. Fixes #2331
Continuing http://sourceforge.net/p/check/bugs/111/: Running
make checkin anautotools-based project causes all tests to fail andcheck_msg.c:80: No messaging setupto be logged totest-suite.log. I found http://sourceforge.net/p/check/bugs/74/ which doesn't apply because I don't use Windows and http://sourceforge.net/p/check/mailman/message/2750522/ which doesn't contain any replies.Minimal working example is provided at https://github.com/krichter722/check-no_messaging_setup-issue based on
check'scheck_moneyexample. I'm also providing a travis build result at https://travis-ci.org/krichter722/check-no_messaging_setup-issue/builds/107650108 which reproduces the issue!I didn't manage to upload the project as a zip because travis didn't let me. I think it would be good to archive it here and for me to keep by repository list clean in the future.
The text was updated successfully, but these errors were encountered: