backend.testc - some state hanging around between tests?

[elliefm]

On Sat, Sep 15, 2018, at 9:27 PM, Sergey wrote:

On Monday 19 October 2015, Sergey wrote:

I found messages with similag error (threads.c:342: krb5int_key_register ...)
with krb5-1.13 (I use 1.13.1) in Google. I attempted to rollback to krb5 1.12
and test was passed. That is probably it is the problem of krb5.

The problem remains with Cyrus-IMAP 3.0.8 and krb5-1.16.1:

Suite: backend
Test: badhost ...passed
Test: badservice ...lt-unit: threads.c:353: krb5int_key_register:
Assertion `destructors_set[keynum] == 0' failed.

Ivan A. Melnikov found an interesting nuance (sorry, comments on Russian):
https://bugzilla.altlinux.org/show_bug.cgi?id=31381#c9

In short: test suite is not passed in all, but it passed by one by one.

It works:

for test in ./unit -l | grep backend ; do ./unit -v "$test"; done

It isn't:

./unit -v "backend"

--
Regards,
Sergey

[elliefm]

Wonder if 1cd8e90 helps...

[elliefm]

Today I noticed I had a bunch of backend.testc's server processes still hanging around from yesterday, I wonder if that's related to whatever is going on here.

This usually isn't an issue for me when running the cunit tests via 'make check'

[elliefm]

I've just noticed that when I run the full lot of tests, like make check does, then the backend tests all pass.

If I run just the backend suite, like make check-backend or cunit/unit backend, then many of the tests fail:

Suite: backend
  Test: badhost ...passed
  Test: badservice ...passed
  Test: sasl_plain ...FAILED
    1. cunit/unit.c:116  - CU_FAIL_FATAL("Code under test exited")
  Test: sasl_digestmd5 ...FAILED
    1. cunit/unit.c:116  - CU_FAIL_FATAL("Code under test exited")
  Test: multiline_caps ...FAILED
    1. cunit/unit.c:116  - CU_FAIL_FATAL("Code under test exited")
  Test: oneline_caps ...FAILED
    1. cunit/unit.c:116  - CU_FAIL_FATAL("Code under test exited")
  Test: starttls ...FAILED
    1. cunit/unit.c:116  - CU_FAIL_FATAL("Code under test exited")

Run Summary:    Type  Total    Ran Passed Failed Inactive
              suites     43      1    n/a      0        0
               tests    487      7      2      5        0
             asserts     11     11      6      5      n/a

Elapsed time =    0.015 seconds

If I run just the "oneline_caps" test individually in the debugger, it ends up fataling out during backend_connect() because it tries to read config, and it triggers one of the assert(config_loaded) assertions in libconfig.c. (I expect the other ones fail for the same reason; the only reason I'm looking at oneline_caps specifically is cause it's short.)

config_loaded is only ever set by config_read(), so for this assertion to pass in the "run the entire set" implementation it must be calling that at some point, whereas when individual suites or individual tests are run, it must be bypassed, and therefore anything that tries to read config crashes...

[elliefm]

Aaaaand I think I've found the cause of that. config_reset() in libconfig.c does NOT reset config_loaded, so as long as any unit test explicitly sets up some config, any subsequent test will be able to read config without asserting. Tests in aaa-db.testc set up config, so in a normal run when this suite runs before backend.testc, by the time backend.testc runs, libconfig will no longer assert on missing config.

So there's two problems: config_reset doesn't reset config_loaded, and backend.testc needs config but doesn't properly initialise any in its own setup. Cool.

[elliefm]

Today I noticed I had a bunch of backend.testc's server processes still hanging around from yesterday, I wonder if that's related to whatever is going on here.

This usually isn't an issue for me when running the cunit tests via 'make check'

I think this happens any time a test in the backend suite fails for any reason. I expect the "toy test server" thing isn't being cleaned up correctly on test failures. Have not yet investigated why.