Re: Segmentation violation problem

[Vic Bancroft]

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 < address@hidden> 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
address@hidden
http://lists.gnu.org/mailman/listinfo/users-prolog