On Fri, 12 May 2017, motiv4u wrote:
Start with a position (I think it can be just any position)
GNUbg ID: bM7gASiYZ8oBMA:cAngAAAAAAAE
Now do:
Analyse - Distribution of rolls
Change Depth from 1 to 2 to 3 to 4 to 5 (takes 10 minutes on i7 3th gen)
With GNUbg build on Windows 10 (msys2) from CVS, May 7th, 2017
continue playing: after couple of rolls, gnubg crashes
With GNUbg from www.gnubg.org, version 1.05.00-mingw 32-Bit 20150725
when depth 5 is almost done, a window pops up with:
"GLib-ERROR (recursed) **:../../glib-2.44.1/glib/gmem.c:103: failed to
allocate 12 bytes"
and next lines identical with "failed to allocate 16, 704, 272 bytes"
Click OK: GNUbg crashes.
Rolls distribution analysis can apparently use a lot of memory and leak
it massively.
Looking a a ps output, I get something like this :
Initial :
USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND
pm 1453 0.8 2.6 490968 211980 4 S+ 18:38 0:00.96 ./gnubg
After depth 5 analysis :
pm 1453 0.0 13.3 1375704 1098672 4 I+ 18:38 7:01.79 ./gnubg
About 800 MB used...
After OK and moving to another move :
pm 1453 1.7 7.4 888280 609976 4 S+ 18:38 7:05.35 ./gnubg
After anoter depth 5 analysis :
pm 1453 0.0 16.1 1609176 1331752 4 S+ 18:38 14:16.61 ./gnubg
After OK and moving to another move :
pm 1453 4.6 10.6 1156568 879024 4 S+ 18:38 14:19.73 ./gnubg
etc...
I don't know much about gtk programming but the gtkrolls.c file is
relatively short and the leak issue may be obvious to someone
knowledgeable in this area.
On the other hand, I don't know why looking at rolls up to such a depth
would be useful. To analyse market losing sequences, depth 2 seems enough
(and then evaluate the leaf nodes at 0, 1, or 2 ply, but build a list of
only 21^2 rolls sequences, not 21^5...).
For now, a simple way to avoid the problem would be to limit the usable
depth to 4. Is there a reason you needed to go to 5 ?
_______________________________________________
Bug-gnubg mailing list
Bug-gnubg@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnubg
