Re: [Chicken-hackers] [Chicken-janitors] #1045: [panic] out of memory - heap full while resizing - execution terminated (awful-picman)

2013-10-18 Thread Alaric Snell-Pym
On 17/10/13 23:28, Chicken Trac wrote: > > As discovered by Felix, it turned out to be an issue with sql-de-lite, > which has been fixed by Jim in sql-de-lite 0.6.2 > sql-de-lite had a bug? Man! That may have also been a contributing factor to my ugarit backend woes (which mainly happened in

Re: [Chicken-hackers] [PATCH] Fix #1058 and (hopefully) #1045

2013-10-18 Thread Mario Domenech Goulart
On Mon, 14 Oct 2013 22:17:50 +0200 Peter Bex wrote: > On Sun, Oct 13, 2013 at 01:51:01PM +0200, Peter Bex wrote: >> After adding these checks, I noticed that in a DEBUGBUILD, the >> hash-table tests started failing consistently with the dreaded >> "out of memory - heap full while resizing" error.

Re: [Chicken-hackers] [PATCH] Add aggressive debugging checks to squash those damn bugs

2013-10-18 Thread Mario Domenech Goulart
On Sun, 6 Oct 2013 17:06:00 +0200 Peter Bex wrote: > On Sun, Sep 29, 2013 at 10:46:25PM +0200, Peter Bex wrote: >> The first patch adds assertions to all the type accessors like C_unfix, >> C_block_{header,item}, C_character_code etc. It does this through a >> "check" macro which contains a horr

Re: [Chicken-hackers] [Chicken-janitors] #1045: [panic] out of memory - heap full while resizing - execution terminated (awful-picman)

2013-10-18 Thread Jim Ursetto
Yes, an access to freed memory leading (possibly) to segfault. Let me know if you see a difference. > On Oct 18, 2013, at 8:37, Alaric Snell-Pym wrote: > >> On 17/10/13 23:28, Chicken Trac wrote: >> >> >> As discovered by Felix, it turned out to be an issue with sql-de-lite, >> which has bee

Re: [Chicken-hackers] [PATCH] Fix EINTR handling in stream ports

2013-10-18 Thread Mario Domenech Goulart
On Sun, 13 Oct 2013 14:11:46 +0200 Peter Bex wrote: > Here's a fix for another subtle bug: when a read from a file with > read-string[!] is interrupted and gets EINTR, it will probably go > completely nuts because of a FUBAR fixnum calculation based on > treating C_SCHEME_FALSE or C_SCHEME_TRUE a