seg fault during analysis

[Todd Doucet]

GnuBg crashes with a segmentation violation whenever I try to run
analysis on a large session.  Large here means about 300 games or so
in an unlimited match.  GNU Backgammon 1.08.003 20260225.

Here is an example (from the command line) that shows such a session, which
I save and then subsequently try to analyze:

(todd) show score
show score

The score (after 1000 games) is: gnubg 636, todd 644 (money session, without Jacoby rule).
(todd) save match /home/todd/Desktop/thousand.sgf
save match /home/todd/Desktop/thousand.sgf


I tried the GUI and the command-line versions of "analyze session".
Both behave the same way -- it chugs along, and gets maybe 60 percent
through in this case and then exits with a segmentation violation.  I
watch the memory usage climb (using System Monitor under Mint) and it
always crashes when the memory usage gets around 1.2 GB or so.  (My
machine has 64 GB of memory and most of it is free.)  It is not a
ulimit set in the OS, because that is set to "unlimited".

Perhaps I am unusual in wanting to analyze large sessions.  It would
be useful to do this, however.  In the above example, my neural net
(called "todd" in this session) is playing gnubg (at World Class)
using no cube and cubeless equity moves set for gnubg.  I find it is
convenient to have gnubg do a PR (Performance Rating) analysis
regardless of which player is probably stronger, because it is a
fairly efficient way to tag questionable plays for my own analysis.

My hunch is that GnuBG wants to have the entire session in memory at
once, including all the annotations for SGF format, and I can see that this
would start to get large if it is recording, for example, every play and every
possible alternative.  Still, at the scale of 1000 games this should work with
that design.  So perhaps there is a limitation in code that could be lifted?

I am a little surprised, because I thought nowadays various sites use
these programs to do large-scale analysis of backgammon play.  And
1000 games is not, in the scheme of things, very large.

PS:  I only recently discovered that I could jump to the next flagged
move with a command (in the GUI).  Even better would be to jump to the
next biggest blunder.  Those are what I'm most interested in and there is
still a lot of manual fussing around to get to the items of interest.

If somebody would direct me approximately where to look in the code, I could
see if I could fix it.  Alternatively, I could provide large sessions if anybody would
like to see them for analysis.  The sky is the limit for that . . .

I'd like to suggest that large-scale analysis is particularly appropriate for PR, especially
for human players, perhaps, because it is the rare blunders that really drive the statistics
here.

--Todd