Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Mar 30 22:16
    kugel- commented #347
  • Mar 24 11:56
    lgutter commented #345
  • Mar 23 23:46
    kugel- opened #347
  • Mar 22 21:25
    kugel- commented #345
  • Mar 22 15:30
    Snaipe commented #345
  • Mar 22 15:30
    Snaipe commented #345
  • Mar 22 14:33
    kugel- commented #345
  • Mar 22 13:55
    Snaipe commented #345
  • Mar 21 16:49
    Snaipe commented #345
  • Mar 21 15:28
    Snaipe commented #345
  • Mar 21 15:13
    Snaipe edited #321
  • Mar 18 21:28
    kugel- commented #345
  • Mar 17 17:32
    laikq closed #346
  • Mar 17 17:32
    laikq commented #346
  • Mar 17 13:24
    kugel- commented #345
  • Mar 17 12:06
    laikq opened #346
  • Mar 17 08:35
    kugel- commented #303
  • Mar 17 08:34
    kugel- commented #303
  • Mar 12 17:39
    nloomans commented #321
  • Mar 10 18:13
    lgutter commented #345
Ben Turrubiates
@bturrubiates
:clap: oh i’m an idiot, that works
Franklin Mathieu
@Snaipe
no worries :smile:
Ben Turrubiates
@bturrubiates
hmm, that wasn’t mentioned anywhere in the docs on readthedocs, i was following that and i guess i dropped the static part
could you maybe add in something to the docs that explicitly states that it needs to be static if not dynamically allocated?
Franklin Mathieu
@Snaipe
Sure
Ben Turrubiates
@bturrubiates
thanks!
Ben Turrubiates
@bturrubiates
@Snaipe Is it valid to use the assertion macros in the teardown/setup functions?
Franklin Mathieu
@Snaipe
@bturrubiates no, use cr_skip_test()
(although cr_skip_test() is only logical on a setup standpoint -- if something goes terribly wrong in initialization or finalization just call abort() and let the test crash)
Ben Turrubiates
@bturrubiates
Thanks. I upgraded to 2.3.0rc1 so I could use cr_skip_test, and I see that —pattern is now —filter and —no-early-exit is now deprecated. I used to make use of pattern and no-early-exit for inspecting leaks with valgrind. How do I accomplish that now?
Valgrind output is always clean (even though I know that this test has a memory leak)
Franklin Mathieu
@Snaipe
You just need to pass --trace-children=yes to valgrind
Ben Turrubiates
@bturrubiates
Oh, you’re awesome.
Why didn’t I need that before?
Franklin Mathieu
@Snaipe
well it seems that fork() didn't count as a "child" for valgrind
now that criterion calls exec() after fork, valgrind needs that option
Ben Turrubiates
@bturrubiates
Oh, I see now.
Franklin Mathieu
@Snaipe
also now that criterion is calling exec, your valgrind logs should be much cleaner, as the new sandboxes won't inherit the memory of the parent
Ben Turrubiates
@bturrubiates
I haven’t been tracking development on Criterion so wasn’t aware of that change.
Also, that works great. :fire: :sparkles: Thanks
Btw, I looked at the docs for master on readthedocs and didn’t see anything about cr_skip_test, is that just because that change hasn’t made it into master / a stable release yet?
Franklin Mathieu
@Snaipe
yes
the latestdocs should mirror the most current edition
once the stable 2.3.0 release is out, the stable docs will be updated automatically
Ben Turrubiates
@bturrubiates
i hadn’t even noticed that option. thanks!
so I know you mentioned abort/cr_skip_test, but if i want to mark a test as failed if something fails during setup/teardown is abort the best option (or maybe something like cr_assert_fail?)
Franklin Mathieu
@Snaipe
abort is indeed the best solution right now. cr_assert and all of its variant actually longjmp()s, and the jmp_buf isn't setup during setup or teardown
if a initialisation condition fails often, perhaps it's best to actually include it in the test itself and itest it
failures in setup/teardown should probably either mandate a skip, or remain exceptional
also if you call abort in those functions you'll still be notified with a warning that the setup or teardown crashed, which reinforces the fact that it's an exceptional condition
Ben Turrubiates
@bturrubiates
well they shouldn’t fail, i put that stuff in setup/teardown because it’s boilerplate that a whole suite will share. but sometimes it’s useful to be able to error if something in setup/teardown fails. i think it makes sense for abort to be the most obvious choice
yeah, sounds good to me. they shouldn’t fail, if they did then something has gone wrong
Franklin Mathieu
@Snaipe
right. downright exiting for these conditions makes the most sense because you're not explicitely testing that failure
Ben Turrubiates
@bturrubiates
what is the —debug option supposed to do if TYPE is not provided?
the -h output seems to indicate that it’s optional
Franklin Mathieu
@Snaipe
@bturrubiates it chooses a debugging server appropriately depending on the compiler used
gcc/icc make it use gdbserver, clang makes it use lldb-server
Ben Turrubiates
@bturrubiates
Oh, that makes sense. The system I’m working on has clang but not lldb. So I’m getting something like:
bturrubi at blade11 :: ./src/usnic-av-tests -j1 --debug
[----] Criterion v2.3.0-rc1
[====] Running 2 tests from bind_ep:
criterion: Could not spawn test instance: No such file or directory
[1]    23360 abort      ./src/usnic-av-tests -j1 --debug
Franklin Mathieu
@Snaipe
Ah, I thought I made the "No such file or directory" message a bit clearer, but I must've forgot
It should definitely print that the debugging server could not be found
Ben Turrubiates
@bturrubiates
Cool, I don’t think lldb-server works on Linux yet
Franklin Mathieu
@Snaipe
I'm on archlinux, and it works quite well on my end
Ben Turrubiates
@bturrubiates

Oh, weird. I was going off of this paragraph:

LLDB is improving on Linux. While the debugserver has not been ported (to enable remote debugging) Linux is nearing feature completeness with Darwin to debug x86_64 programs, and is partially working with i386 programs. ARM architectures on Linux are untested. For more details, see the Features by OS section below.

Found here: http://lldb.llvm.org/status.html

Franklin Mathieu
@Snaipe
It's probably bleeding edge, as Arch is doing rolling releases
I did not realize that the debugging server wasn't quite ready yet
perhaps it would be better to fallback to gdbserver if lldb-server isn't there
Ben Turrubiates
@bturrubiates
Yeah probably. I used to use Arch, having access to the most up-to-date packages was really nice.
Also, has Criterion always created *.sock files in the tests working directory? Or is that new?
Franklin Mathieu
@Snaipe
it's a side effect of nanomsg, so it's new
Ben Turrubiates
@bturrubiates
Whenever I get that abort due to lldb-server not being found, I also get left with a criterion_$pid.sock