From jan@swi.psy.uva.nl Thu Jan 17 10:29:16 2002
Received: from gollem.swi.psy.uva.nl (root@gollem.swi.psy.uva.nl [145.18.152.30])
	by swi.psy.uva.nl (8.11.6/8.11.2) with ESMTP id g0H9TGT29450;
	Thu, 17 Jan 2002 10:29:16 +0100 (MET)
Received: (from jan@localhost)
	by gollem.swi.psy.uva.nl (8.11.6/8.11.6/SuSE Linux 0.5) id g0H9TFM13217;
	Thu, 17 Jan 2002 10:29:15 +0100
Date: Thu, 17 Jan 2002 10:29:15 +0100
Message-Id: <200201170929.g0H9TFM13217@gollem.swi.psy.uva.nl>
From: Jan Wielemaker <jan@swi.psy.uva.nl>
Subject: Re: [SWIPL] Crash in Garbage collection
To: schumann@email.arc.nasa.gov, prolog@swi.psy.uva.nl
In-Reply-To: schumann@email.arc.nasa.gov's message of Wed, 16 Jan 2002 23:03:10 -0800 (PST)
Phone: +31 - 20 - 525 6121
Cc: schumann@email.arc.nasa.gov

> Hallo,
> 
> we are developing a large program synthesis system (~30k lines) using SWI.
> After a recent change, we get crashes during garbage collection.
> The system works seemingly fine when the gc is turned off.
> This problem occurs on 3.4.X and 4.0.11 (didn't try out the new version yet),
> both on sun solaris and linux (x86 and PPC). 
> We are using the basic Prolog set (no GUI, data base,...) but lots of meta
> predicates. Any attempt to turn on traceing or write_ln's makes the error
> go away (of course :-( ). We could narrow down the problem to ~1000 lines 
> of Prolog, but could not find anything suspicious.
> My questions:
> * does this kind of error ring a bell (I browsed the archive, but could not
> 	find a match)

It has (of course) happened in the past.  GC errors are very rare in recent
releases as far as I know (4.1.0 won't help, there is no change in the
garbage collector).

> * is there a C-routine which dumps (parts) of the stacks in a readable manner
> (environments, choicepoints, terms on the global stack, etc.) so we could
> perhaps find how the terms close to the problem look like (and where/how
> they were created)?

You can recompile the system with -DSECURE_GC, which adds a lot of
additional tests to the garbage collector spotting the problem earlier
and therefore easier to track.  Before starting the collection it
validates the consistency of the entire stacks, returning a position-
and garbage-independent key.  It adds a lot of tests during the
process and at the end runs the same consistency check and compares
the keys.

> * any advice or tricks how to tackle such a problem?

Especially in this case (version independent and OS independent) it should
be quite easy for me to track it down.  Best advice is to send me the sources
with instructions on how to reproduce.

	--- Jan

