Thank you Matthew.

On 17/08/15 17:07, Matthew Flatt wrote:
> That's an especially basic mistake, and it slipped by because low-level
> locks are rarely allocated in the run-time system. Place channels are
> probably the simplest way to trigger new locks, but the test that
> checks for leaks with place channels uses the GC's count.

The sad thing is that years of C programming don't improve one's (I
mean "my") ability to spot broken malloc/free pairs. So although you
say it's a basic mistake -- it doesn't mean that wasn't inevitable!

That's why we all rely on the GC; because the alternative is just too
horrible to contemplate :-O . And send brave souls like you to face the
horrors. Thanks for volunteering.

> I've pushed a repair as commit 641c56b6e9. I expect that patch would
> apply cleanly to v6.2.1.

Tim

-- 
Tim Brown CEng MBCS <tim.br...@cityc.co.uk>
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
                City Computing Limited · www.cityc.co.uk
      City House · Sutton Park Rd · Sutton · Surrey · SM1 2AE · GB
                T:+44 20 8770 2110 · F:+44 20 8770 2130
────────────────────────────────────────────────────────────────────────
City Computing Limited registered in London No:1767817.
Registered Office: City House, Sutton Park Road, Sutton, Surrey, SM1 2AE
VAT No: GB 918 4680 96

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to