From jan@swi.psy.uva.nl Fri May 18 11:41:35 2001
Received: from gollem.swi.psy.uva.nl (root@gollem [145.18.152.30])
	by swi.psy.uva.nl (8.11.2/8.11.2) with ESMTP id f4I9fY326767;
	Fri, 18 May 2001 11:41:34 +0200 (MET DST)
Received: from localhost (localhost [[UNIX: localhost]])
	by gollem.swi.psy.uva.nl (8.11.2/8.11.2/SuSE Linux 8.11.1-0.5) id f4I9fY813145;
	Fri, 18 May 2001 11:41:34 +0200
From: Jan Wielemaker <jan@swi.psy.uva.nl>
Organization: SWI, University of Amsterdam
To: Yan Guiborat <yan.guiborat@caramail.com>, prolog@swi.psy.uva.nl
Subject: Re: [SWIPL] Error embedding swi prolog in a C app.
Date: Fri, 18 May 2001 11:33:40 +0200
X-Mailer: KMail [version 1.0.29.2]
Content-Type: text/plain
References: <990181739014558@caramail.com>
In-Reply-To: <990181739014558@caramail.com>
MIME-Version: 1.0
Message-Id: <01051811413400.13032@gollem>
Content-Transfer-Encoding: 8bit

On Fri, 18 May 2001, Yan Guiborat wrote:
>
>Hi,
>
>I made a small C progam looking like this.
>
>main()
>{
>...
>...
>PL_initialize(..).
>Parse_an_XML_File().
>exit
>}
>
>The purpose of parsing the XML file is to get information
>about some foreign predicates(name, arity, flag), wich will
>be dynamically loaded, an them registered to the prolog
>engine through PL_register_foreign().
>I am parsing the XML using GNU libXML and sax API.
>Sadly, when I try it, once the first callback function from
>sax terminates, I get this error message from prolog:
>"
>[PROLOG SYSTEM ERROR: Thread 1
>	Recursively received fatal signal 11
>
>PROLOG STACK:
>"
>when this happens, I haven't even called
>PL_register_foreign(), neither any of the foreign module
>interface functions, nothing, only libXML and it's sax API.
>Could someone help, please ?
>I was wondering so what was hapenning when PL_initialize is
>called. Is there a Fork made to launch swi-prolog in a new
>process, or does it still belong to the initial one.
>Great Thnks to any help.

It initialises the program infrastructure, loads the boot-file
(boot32.prc) and creates the stacks.  On many Unix systems it
installs a signal-handler for SEGV (11), which is used to detect
stack overflows.  If external code is generating SEGV it might
think there is a stack overflow and extend the stacks.  It then
returns and the foreign code will probably trap again.  Now
Prolog says it doesn't understand it anymore.

Run the system under a debugger to see where your foreign code
is failing.  When using lots of foreign code and performance isn't
too critical you might wish to configure using the option

	--disable-segv-handling

Forcing Prolog to use software guards on the stacks even if it
thinks it can use hardware on this platform.

	--- Jan

P.s.	SWI-Prolog 4.x comes with an SGML/XML parser.  See
	library(sgml). 

