October 2007 - PPL-devel - BUGSENG Mailman

ppl ./NEWS interfaces/C/ppl_c.h.in
by Roberto Bagnara 09 Oct '07

09 Oct '07

CVSROOT: /cvs/ppl Module name: ppl Changes by: bagnara(a)cs.unipr.it 2007-10-09 15:59:20 Modified files: . : NEWS interfaces/C : ppl_c.h.in Log message: In the C interface it is no longer an error to call ppl_initialize() or ppl_finalize() multiple times (this matches the behavior of the other interfaces). Patches: http://www.cs.unipr.it/cgi-bin/cvsweb.cgi/ppl/NEWS.diff?cvsroot=ppl&r1=1.21… http://www.cs.unipr.it/cgi-bin/cvsweb.cgi/ppl/interfaces/C/ppl_c.h.in.diff?…

1 0

ppl/interfaces/C ppl_interface_generator_c_cc_ ...
by Roberto Bagnara 09 Oct '07

09 Oct '07

CVSROOT: /cvs/ppl Module name: ppl Changes by: bagnara(a)cs.unipr.it 2007-10-09 15:57:30 Modified files: interfaces/C : ppl_interface_generator_c_cc_preamble Log message: Teach emacs that this is a C++ file. Disable automatic initialization. Use the new Parma_Polyhedra_Library::initialize() and Parma_Polyhedra_Library::finalize() instead of something ad hoc. Patches: http://www.cs.unipr.it/cgi-bin/cvsweb.cgi/ppl/interfaces/C/ppl_interface_ge…

1 0

ppl/interfaces/Prolog/SWI ppl_interface_genera ...
by Roberto Bagnara 09 Oct '07

09 Oct '07

CVSROOT: /cvs/ppl Module name: ppl Changes by: bagnara(a)cs.unipr.it 2007-10-09 15:55:44 Modified files: interfaces/Prolog/SWI: ppl_interface_generator_swiprolog_cc.m4 Log message: Do not rely on automatic initialization of the PPL. Patches: http://www.cs.unipr.it/cgi-bin/cvsweb.cgi/ppl/interfaces/Prolog/SWI/ppl_int…

1 0

ppl/interfaces/Prolog ppl_prolog_common.icc
by Roberto Bagnara 09 Oct '07

09 Oct '07

CVSROOT: /cvs/ppl Module name: ppl Changes by: bagnara(a)cs.unipr.it 2007-10-09 15:28:41 Modified files: interfaces/Prolog: ppl_prolog_common.icc Log message: No longer rely on automatic initialization. Patches: http://www.cs.unipr.it/cgi-bin/cvsweb.cgi/ppl/interfaces/Prolog/ppl_prolog_…

1 0

ppl ./NEWS src/initializer.hh
by Roberto Bagnara 09 Oct '07

09 Oct '07

CVSROOT: /cvs/ppl Module name: ppl Changes by: bagnara(a)cs.unipr.it 2007-10-09 15:27:11 Modified files: . : NEWS src : initializer.hh Log message: Users of the C++ interface of the library can now decide to disable the automatic initialization mechanism of the PPL. To do so, the preprocessor symbol PPL_NO_AUTOMATIC_INITIALIZATION should be defined before including the `ppl.hh' header file. When automatic initialization is disabled it is imperative to explicitly call the new function void Parma_Polyhedra_Library::initialize() before using the library. The new function void Parma_Polyhedra_Library::finalize() and should also be called (to release a small amount of memory) when done with the library. Patches: http://www.cs.unipr.it/cgi-bin/cvsweb.cgi/ppl/NEWS.diff?cvsroot=ppl&r1=1.21… http://www.cs.unipr.it/cgi-bin/cvsweb.cgi/ppl/src/initializer.hh.diff?cvsro…

1 0

Loading the SWI-Prolog interface of the PPL under Mac OS X
by Roberto Bagnara 09 Oct '07

09 Oct '07

Dear Mac OS X users of the PPL, in view of the imminent release of PPL 0.10 we are going through the TODO file. One item I added some time ago to that file says: - In the SWI-Prolog documentation, the command to dynamically load the library has to be modified so as to specify the `.so' extension: this is required under Mac OS X and seems not to do any harm under GNU/Linux. Can you please confirm that ?- load_foreign_library('/usr/local/lib/ppl/libppl_swiprolog'). and ?- unload_foreign_library('/usr/local/lib/ppl/libppl_swiprolog'). do not work under Mac OS X, while ?- load_foreign_library('/usr/local/lib/ppl/libppl_swiprolog.so'). ?- unload_foreign_library('/usr/local/lib/ppl/libppl_swiprolog.so'). do? Thanks a lot, Roberto -- Prof. Roberto Bagnara Computer Science Group Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:bagnara@cs.unipr.it

4 15

ppl/src BD_Shape.inlines.hh Box.inlines.hh Oct ...
by Roberto Bagnara 08 Oct '07

08 Oct '07

CVSROOT: /cvs/ppl Module name: ppl Changes by: bagnara(a)cs.unipr.it 2007-10-08 21:55:40 Modified files: src : BD_Shape.inlines.hh Box.inlines.hh Octagonal_Shape.inlines.hh Log message: Use DIRTY_TEMP instead of static variables. Patches: http://www.cs.unipr.it/cgi-bin/cvsweb.cgi/ppl/src/BD_Shape.inlines.hh.diff?… http://www.cs.unipr.it/cgi-bin/cvsweb.cgi/ppl/src/Box.inlines.hh.diff?cvsro… http://www.cs.unipr.it/cgi-bin/cvsweb.cgi/ppl/src/Octagonal_Shape.inlines.h…

1 0

ppl/interfaces/Prolog/SWI ppl_interface_genera ...
by Roberto Bagnara 08 Oct '07

08 Oct '07

CVSROOT: /cvs/ppl Module name: ppl Changes by: bagnara(a)cs.unipr.it 2007-10-08 21:40:10 Modified files: interfaces/Prolog/SWI: ppl_interface_generator_swiprolog_cc.m4 Log message: Use DIRTY_TEMP0 for temporaries. Patches: http://www.cs.unipr.it/cgi-bin/cvsweb.cgi/ppl/interfaces/Prolog/SWI/ppl_int…

1 0

ppl/src Coefficient.cc Coefficient.defs.hh Coe ...
by Roberto Bagnara 08 Oct '07

08 Oct '07

1 0

Re: [PPL-devel] GMP memory allocation problem in SWI-Prolog 5.6.38 and following versions
by Roberto Bagnara 08 Oct '07

08 Oct '07

Jan Wielemaker wrote: > Hi Roberto, > > On Tuesday 02 October 2007 07:42, Roberto Bagnara wrote: >> Starting from version 5.6.38 of SWI-Prolog, applications using SWI-Prolog >> and GMP started failing. The problem is due to the fact that SWI-Prolog >> overrides the memory allocation functions used by GMP by calling >> mp_set_memory_functions(). I have observed two instances of the problem, >> one of which was reported by users of the Parma Polyhedra Library: >> >> 1) a variable allocated in the C++ code before SWI-Prolog changes the >> allocation functions is destroyed after SWI-Prolog has done that (this >> results in a segmentation fault); >> 2) while executing the C++ code, the realloc function set by SWI-Prolog is >> called (this results into an invalid pointer detected by glibc). >> >> Both instances are caused by the fact that memory allocated by GMP's >> default functions is reallocated/freed by SWI-Prolog's functions. >> Something that is guaranteed to cause problems. However, even if all >> memory allocation was done by the SWI-Prolog's functions, I am sure we >> would have other troubles. I am not sure what is the way out, but the >> problem is rather serious. All the best, > > Rebinding the allocation functions is done to allow SWI-Prolog to detect > and act upon GMP memory overflows. Unfortunately GMP is very weak in > allowing applications to act gracefully on overflows. I see no reason > for problems as long as you initialize Prolog before touching any GMP > number. This is not always possible, unfortunately. > If that should be the case anyway, we must add something to the > foreign interface that allows for initializing Prolog without rebinding > the GMP allocation. This is certainly useful. But what happens if, in some computation in the C++ code that has nothing to do with SWI-Prolog, pl_abort() is called (I am looking at pl-gmp.c)? Perhaps I am missing something, but this will break the overall application completely. I think SWI-Prolog should have his own private version of GMP if it wants to change the allocation functions. In other words, setting the allocation functions on a shared GMP can only be done at the overall application level: if every component does that on its own, things are going to break. All the best, Roberto -- Prof. Roberto Bagnara Computer Science Group Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:bagnara@cs.unipr.it

2 10