On 17 czerwca 2017 at 07:08:24, Bart Schaefer (schaefer@brasslantern.com) wrote:
> On Jun 16, 5:14pm, Sebastian Gniazdowski wrote:
> }
> } ============ The maybe-suspicious reports ============
>  
> A few of these look like they're probably the same report reached via
> slightly different script paths. The backtraces aren't very helpful
> without knowing which specific test case set them off.

I've fixed this, before each Valgrind error currently executed test case is shown (attached how it looks like).

> I'm guessing most of these are going to turn out to be from a subshell
> exec'ing or exiting without bothering to clean up allocations done by
> the parent, particularly in the case where the leaked memory is from
> the stdio library (indicating "FILE *bshin" was never fclose()d).

I muted many fork / zfork errors initially.

Today I wanted to catch something. The bicat() usage seems to leak what getoutputfile() returns:

- that function always calls: gettempname(NULL, 0), and the 0 == zalloc() memory
- in stringsubst(), after memcpy(), result of getoutputfile() is unused, free to release

Attached is a patch with fix for this, it removes the Valgrind error. The error (Valgrind stack-trace) is attached in the PNG.

I've added 2 error definitions, A04 is now fully silent:

https://github.com/zdharma/VATS-zsh

Does this maybe prove usability of VATS, and open way to add to upstream?

--  
Sebastian Gniazdowski
psprint /at/ zdharma.org