Re: [Bug-gnubg] GNUbg crashes with Analyse - Distribution of Rolls
On Mon, 29 May 2017, motiv4u wrote: I noticed the "Fix memory leaks" in the CVS-repository http://cvs.savannah.gnu.org/viewvc/gnubg/gnubg/?sortby=date#dirlist looking at the Diffs, since the ChangeLog wasn't that clear for me. These are unrelated to your issue. I used a feature from recent versions of gcc (-fsanitize=address) to track another problem and as a side effect it revealed many memory leaks. I fixed some easy ones but many other remain. The one from "analyze rolls" is not among them but limiting the analysis depth to 4 instead of 5 decreased its maximum cost by a factor of 21. That should be enough to prevent the kind off crash you experienced in practical usage. There's no need for depth 5 ... and it is not available anymore: 4 is the max today. I don't know when or where it is changed, but is after May 12 and before May 29. ___ Bug-gnubg mailing list Bug-gnubg@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gnubg
Re: [Bug-gnubg] GNUbg crashes with Analyse - Distribution of Rolls
> > >> [snap] 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 ? I noticed the "Fix memory leaks" in the CVS-repository http://cvs.savannah.gnu.org/viewvc/gnubg/gnubg/?sortby=date#dirlist looking at the Diffs, since the ChangeLog wasn't that clear for me. The depth 5 was merely by coincidence. There's no need for depth 5 ... and it is not available anymore: 4 is the max today. I don't know when or where it is changed, but is after May 12 and before May 29. N. > ___ Bug-gnubg mailing list Bug-gnubg@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gnubg
Re: [Bug-gnubg] GNUbg crashes with Analyse - Distribution of Rolls
On Fri, 12 May 2017, motiv4u wrote: Start with a position (I think it can be just any position) GNUbg ID: bM7gASiYZ8oBMA:cAngAAAE 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 : USERPID %CPU %MEM VSZRSS 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
