This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-06-21
Channels
- # announcements (3)
- # aws (8)
- # babashka (14)
- # beginners (39)
- # biff (22)
- # cider (5)
- # clj-kondo (1)
- # cljs-dev (12)
- # cljsjs (4)
- # clojure (16)
- # clojure-europe (47)
- # clojure-germany (6)
- # clojure-uk (2)
- # clojurescript (36)
- # core-async (29)
- # cursive (19)
- # datalevin (14)
- # etaoin (10)
- # helix (1)
- # hyperfiddle (6)
- # introduce-yourself (5)
- # kaocha (43)
- # keechma (1)
- # lsp (7)
- # nbb (68)
- # new-channels (1)
- # off-topic (12)
- # pathom (11)
- # quil (14)
- # rdf (3)
- # re-frame (5)
- # reitit (6)
- # shadow-cljs (88)
New Kaocha release! This fixes a bug added to gc-profiling
in the previous version: https://github.com/lambdaisland/kaocha/releases/tag/v1.68.1059
Perhaps a post in #announcements and/or #releases may be useful to raise awareness too?
Not a bad idea. We try to release frequently, which is beneficial for existing users, but makes it less obvious when to promote a release. Maybe I'll sum up the last couple of releases.
I believe #releases are for small incremental changes, and #announcements for the bigger ones.
i.e., in #releases A place to post minor releases of libraries and projects that you would not otherwise post in #announcements
I'm sorry to bother you guys but I keep getting errors, this one is a bit tricky to reproduce so I'm not opening an issue on Github until I figure out what's causing it
The issue is that "sometimes" (non deterministic so it's probably tied to my particular test cases) kaocha just exit mid way returning exit code 1
.
The problem is that nothing is printed in the console and I don't know how to get to the underlying cause or exception.
I quickly skimmed thru Kaocha code base and it looks like it's all running in a giant try+
catch
and I'm afraid that is blocking the actual exception to bubble up. Is there any way to avoid that?
We only catch our own own early-exit exception in there, any "normal" exceptions will bubble, or be reported as errors depending on which stage they happen in.
If the exit code is 1 then the only way that is coming from kaocha is if there's a single failing test.
> Is it possible you're hitting some of your own code that does a System/exit?
It's extremely unlikely, we don't call System/exit
directly anywhere and it's happening randomly at different points.
> What does "exit mid way" mean exactly?
I'm using the kaocha.report/documentation
and I can see that (when it's stopping early) it's in a different spot everytime.
> Have you tried reusing the random seed to reproduce the issue?
First thing I tried, I'm always running with a set seed but the exit is not tied to any particular test case
My first guess was a memory issue (and that's why I tried the gc-reporter btw) but it's happening even after increasing the heap space (via Xmx
). Measuring system memory indicates that we are nowhere near the end of addressable memory.
I know, right? I can't figure out what though and I've got no output message to work with 馃槗
Maybe I should try running the tests from the REPL. Can I access the results/outputs when running it this way?
It's happening also on the REPL when running (k/run-all)
it starts running, it prints a bunch of unit tests and then it just stops running without returning the map with the results. The REPL is still running and everything is still up.
> what's the return value of run-all
?
There's no return value as far as I can see, I'm back to the REPL ns waiting for an input. No message, no anything..
btw re-running run-all
in the same REPL didn't triggered any error and completed fine returning the map with #:kaocha.result
. This at least looks consistent with what I was seeing in the CLI.
Same issue using api/run
the output looks something like:
user=> (kaocha.api/run (kaocha.repl/config))
--- unit (clojure.test) ---------------------------
a.test
testing something
testing something
[.... other tests .....]
z.test
testing something
user=>
it's very fascinating, I must admit 馃槃 trying to come up with a hypothesis and failing...
> are you using parallelization? The tested code is highly parallel but I'm not using the parallelization from Kaocha, I'm running on the latest release..
you could try examing the process with jcmd
/`jstack`, but without a hypothesis I'm not sure what that would yield
I'll try to dig deeper into the rabbit hole as soon as I have a little bit of time. In the mean time, thank you for your help!!!
something else, make sure to disable output capturing. That's general advice when debugging issues, you don't want some relevant warnings or other output to get swallowed