Interesting, there is definitely more than one way to start [1]. However,
if we can identify exactly where r2g is producing the segmentation
violation, then we can try to reduce that particular strain on the virtual
machine. Perhaps there an alternate form of this information that would
allow a predicate to run in a more constant space . . .
Feel free to post me a copy of your predicate definitions and I will try to
reproduce the error under a 64 bit environment.
more,
l8r,
v
[1] do you have a debuggable copy of gprolog ?
In one approach, you could enable the generation of core files, e.g.,
$ ulimit -c unlimited
then generate your fatal error. This should produce some core dump file,
say you see,
$ ls core*
core.123
then check the backtrace using gdb using `which` to find prolog in your
PATH,
$ gdb $(which gprolog) core.123
[...]
(gdb) bt
#0 0x00000000004033c2 in main ()
[...]
Often you will need to rebuild it using debug if you see gdb complain with,
(no debugging symbols found)
The other approach would be to make the algorithm lighter like to rework
your flatten or use of member
On 5/30/07, Vincent Schachter <[EMAIL PROTECTED]> wrote:
I encounter a "fatal error : segmentation violation" in the following
context :
Environment : a PC under Linux / GNOME, Gnu Prolog 1.2.19
Program :
- a predicate gpr(L,R) is defined in a separate (consulted) file. gpr is
intended to record the association between a reaction R and L, a list of
lists of genes. L can become rather large. The definition of gpr/2 includes
*many* (~800) atoms and no clauses, excerpt below.
- A predicate r2G is defined as follows :
r2g(R,G):-gpr(GPR,R),flatten(GPR,Geneset),member(G,Geneset).
where flatten turns a list of lists into a simple list.
Execution :
r2G(g,R) is called at the toplevel. g is a gene that is associated with a
large number of gpr clauses.
After the 11th alternative solution, I get a segmentation violation.
I assume this is the consequence of some data structure getting too large.
I set the stack sizes at GLOBALSZ = 1000000, LOCALSZ=24000, TRAILSZ=24000.
I have tried a few other manipulations involving the gpr/3 predicate, and
they all result in a segmentation violation.
I would welcome any suggestion on what I could do to prevent that.
Vincent
Excerpt of gpr definition :
gpr([[g]],r0084).
gpr([[g0178,g0180,g0182,g0183,g0184,g0185,g0186,g0187,g0188]],r0128).
gpr([[g1009]],r0129).
gpr([[g]],r0081).
gpr([[g]],r0080).
gpr([[g1447]],r0523).
gpr([[g1726]],r0649).
gpr([[g2314]],r0648).
gpr([[g2983],[g3598]],r0645).
gpr([[g1017,g1018,g1019,g1020]],r0644).
gpr([[g1757,g1756,g1755,g1753,g1754,g1758,g1759]],r0647).
gpr([[g0544]],r0646).
gpr([[g1689],[g1450],[g1706]],r0641).
gpr([[gSPONT]],r0640).
gpr([[g2984]],r0643).
gpr([[g1211]],r0642).
gpr([[g0166]],r0512).
gpr([[g3633]],r0528).
gpr([[g3523]],r0482).
gpr([[g3078,g3079,g3080]],r0010).
gpr([[g3232]],r0011).
gpr([[g3232]],r0012).
_______________________________________________
Users-prolog mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/users-prolog
_______________________________________________
Users-prolog mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/users-prolog
