[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