[gambit-list] Consistent, small program segmentation fault between 4.6.7 and 4.5.8

Marc Feeley feeley at iro.umontreal.ca
Tue Jun 4 12:15:43 EDT 2013


On Jun 4, 2013, at 8:03 AM, Bradley Lucier <lucier at math.purdue.edu> wrote:

> On 06/04/2013 10:06 AM, Marc Feeley wrote:
>> I will look into this today.  Could you try to add the -:m1 option to gsi to see if the problem goes away?
> 
> No, fails in a similar place.  Sorry.
> 
> Brad

I thought I would document the steps I am taking to debug this issue so that others will have a debugging strategy if such an issue happens again.

Step #1, I suspect there is a GC bug.  Why?  Because the bug seems to declare itself at different moments depending on what was loaded before, the previous REPL commands, the size of the heap, etc.

Step #2, recompile Gambit with --enable-debug and with ENABLE_CONSISTENCY_CHECKS (this enables many different checks during the GC that things are as they should be, and it also adds a loop at the end of the GC to fill the freed space with the value #xCAFEBABE which is easy to notice)

Step #3, run the program:

% gsi/gsi -:d2 chud1.scm
…
| | | | | | | |[12] > (ch-split 27 30)
| | | | | | | |[13] > (ch-split 27 28)
*** ERROR IN ch-split, *** GC: 1 ms, 23.9M alloc, 3.08M heap, 234K live (7% 139520+100344)
"chud1.scm"@14.17 -- (Argument 1) NUMBER expected
(* #\U32bfaeaf #\U32bfaeaf 167)

Now those values passed to * are wrong, but they look familiar…  hmmm

% gsi/gsi -e "(pp (##encoding->object #xCAFEBABE))"
#\U32bfaeaf

So it would seem that the GC is not tracing some values properly.

More to come…

Marc




More information about the Gambit-list mailing list