Re: Segmentation violation problem

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