Joseph Ferano
d1464ee266
Two loose ends. The arena was invisible to memcheck. free-all is retain-capacity, so from malloc's point of view nothing died and round two of a reset arena could read a byte it never wrote, print round one's value, and draw no report. flan_arena_proc now issues memcheck's MAKE_MEM_UNDEFINED over the whole capacity beside its registry call. Measured on the same machine: the control produced ERROR SUMMARY 0 before and 6 errors from 4 contexts after, with --track-origins naming the client request. It is a control in test_valgrind.ml now rather than a printed note. The macro is vendored, not included, and the argument is measurement: the machine that runs the sweep has valgrind and not valgrind-devel, so a guarded #include would compile to nothing exactly where it matters and the control would go quiet with no diagnostic. There is also nowhere to put an -I -- flan_rt.c is cat'd into an OCaml string literal and handed to clang in a scratch directory. The __x86_64__ guard is load-bearing: the same runtime is built for wasm32-wasi and emscripten. Cost outside valgrind: 23 instructions on the free-all path only, about 1ns per reset over fifty million of them, against a run-to-run spread wider than the effect. Nothing on alloc, resize or free. valgrind.supp still holds no suppressions; the corpus stayed clean across the change, which is its own finding. merged_serve's warning path deserved a test and has one. The discriminating fact is not the log line but the policy: two_process kills its child and fails where merged_serve warns and serves anyway, and nothing held that second answer in place. dev-noagent.flan plus the last block of test_dev.ml assert the session still answers describe after the wait runs out. Verified by reverting the policy: the block reports rather than passing. It costs the full ten seconds and there is no way to spend less. HANDOFF-f1.md is deleted.
16 lines
716 B
Plaintext
16 lines
716 B
Plaintext
;;;; A program [flan dev] can host that never calls (agent/start ...), which
|
|
;;;; is the one condition the merged session and the two-process daemon answer
|
|
;;;; differently: [two_process] kills the child and fails, [merged_serve]
|
|
;;;; warns and serves anyway. See test_dev.ml's last block.
|
|
;;;;
|
|
;;;; No (import agent ...) at all, because the point is a program that has not
|
|
;;;; been told about the agent rather than one that forgot a call. It prints
|
|
;;;; and returns: a Flan main that returns under [flan dev] parks instead of
|
|
;;;; ending the process (flan_merged_exit), so the session outlives it and the
|
|
;;;; accept loop keeps answering.
|
|
(defn step [] i64 7)
|
|
|
|
(defn main [] i32
|
|
(print (step)) (println "")
|
|
0)
|