Thomas Linke wrote: > > [eclipse 3]: nomore. > Welcome to noMoRe! > Please enter a file: kladder4_20.lp % A LARGER EXAMPLE WITH FAILS > > computing block-graph ... ok > symbolizing block graph... ok > compiling block graph ... ok > Segmentation violation - possible reasons are: > - a faulty external C function > - certain operations on circular terms > - machine stack overflow > - an internal error in ECLiPSe > Aborting execution.... > Eclipse 5.1 fortunately gave me a better error message :-) [eclipse 2]: nomore. Welcome to noMoRe! Please enter a file: kladder4_20.lp computing block-graph ... ok symbolizing block graph... ok compiling block graph ... ok *** ECLiPSe fatal error: dictionary overflow in atom/functor creation It turns out that the problem is caused by all the generated variable names (like _123) in the compiled file. By default, Eclipse tries to retain the source variable names, which is fatal in this case... If you switch this off, it works: [eclipse 1]: set_flag(variable_names,off). %%%% ADD THIS yes. [eclipse 2]: [nomore2]. ... yes. [eclipse 3]: nomore. Welcome to noMoRe! Please enter a file: kladder4_20.lp computing block-graph ... ok symbolizing block graph... ok compiling block graph ... ok consulting compieled block graph ... compiled.pl compiled traceable 5366596 bytes in 8.17 seconds ok goal succeeded PROFILING STATISTICS -------------------- Goal: count_solutions(a_color_nodes([r1, r10, r100, r101, r102, r103, r104, r105, r106, r107, r108, r109, r11, r110, r111, r112, r113, ...], _901), _898) Total user time: 1.73s Predicate Module %Time Time %Cum -------------------------------------------------------- r208 /3 eclipse 97.1% 1.68s 97.1% integer_overflow_h/2 sepia_kernel 0.6% 0.01s 97.7% is_u /2 eclipse 0.6% 0.01s 98.3% count_solutions /2 eclipse 0.6% 0.01s 98.8% color_all_0 /3 eclipse 0.6% 0.01s 99.4% prop_1_0 /5 eclipse 0.6% 0.01s 100.0% Duration : 2.94 number of 1 colorings : 255 number of 0 colorings : 133 total number of color actions : 388 total number of propagations : 384 number of choice points : 4 number of solutions : 1 (file kladder4_20.lp) yes. > Now the same with nomore.pl which works better but... .... > [eclipse 2]: nomore. > Welcome to noMoRe! > Please enter a file: kladder20_10.lp > > computing block-graph ... ok > symbolizing block graph... ok > > *** Overflow of the global/trail stack in spite of garbage collection ! > The stack sizes are limited by the available swap space. > Current sizes: global stack 130814 kbytes, trail stack 30 kbytes > compiling block graph ... [eclipse 3]: This also works when variable_names is switched off (because it uses slightly less stack space as well): [eclipse 3]: nomore. Welcome to noMoRe! Please enter a file: kladder20_10.lp computing block-graph ... ok symbolizing block graph... ok compiling block graph ... ok goal succeeded PROFILING STATISTICS -------------------- Goal: count_solutions(a_color_nodes([r1, r10, r100, r1000, r1001, r1002, r1003, r1004, r1005, r1006, r1007, r1008, r1009, r101, r1010, r1011, r1012, ...], _2525), _2522) Total user time: 32.30s Predicate Module %Time Time %Cum -------------------------------------------------------- r444 /3 eclipse 95.4% 30.82s 95.4% garbage_collect /0 sepia_kernel 3.3% 1.06s 98.7% update_list /3 eclipse 0.8% 0.26s 99.5% is_u /2 eclipse 0.2% 0.05s 99.7% exit_block /1 sepia_kernel 0.1% 0.02s 99.7% cost_handler /2 sepia_kernel 0.1% 0.02s 99.8% getval_body /3 sepia_kernel 0.0% 0.01s 99.8% incval /1 sepia_kernel 0.0% 0.01s 99.8% call_count /1 eclipse 0.0% 0.01s 99.9% choose_first_node /3 eclipse 0.0% 0.01s 99.9% count_solutions /2 eclipse 0.0% 0.01s 99.9% prop_0_1 /5 eclipse 0.0% 0.01s 100.0% backprop_1_1 /5 eclipse 0.0% 0.01s 100.0% Duration : 33.59 number of 1 colorings : 855 number of 0 colorings : 473 total number of color actions : 1328 total number of propagations : 1292 number of choice points : 36 number of solutions : 1 (file kladder20_10.lp) yes. However, quite a lot of global stack was needed: [eclipse 4]: statistics. times: [237.99, 6.79, 288.38] seconds session_time: 288.38 seconds global_stack_used: 1608 bytes global_stack_allocated: 4456448 bytes global_stack_peak: 115867648 bytes ... To solve even larger problems, you will have to start Eclipse with a larger stack limit using the -g command line option, e.g. % eclipse -g 200M (the default is 128M, ie 128 megabytes) -- Joachim Schimpf / phone: +44 20 7594 8187 IC-Parc, Imperial College / mailto:J.Schimpf@ic.ac.uk London SW7 2AZ, UK / http://www.icparc.ic.ac.uk/eclipseReceived on Thu Jan 11 11:35:22 2001
This archive was generated by hypermail 2.1.8 : Wed 16 Nov 2005 06:08:03 PM GMT GMT