Max Alekseyev on Tue, 23 Apr 2024 20:59:05 +0200


[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

Re: question on trouble shooting gp pari sessions which suddenly quit running


If a program requests too much memory (more than available) from the system it may be killed.
To check trace this issue, you may like to add logging script's memory usage once in a while. It may be done from within the script, or from outside with a watcher tool.

Regards,
Max

On Tue, Apr 23, 2024 at 1:56 PM American Citizen <website.reader3@gmail.com> wrote:
Hello:

It is a bit difficult to explain to you all, because I could actually
not find enough information to point me in the right direction to
troubleshoot a problem I've not seen before.

Yesterday afternoon I kicked off a script of 6 programs running a
gp-pari program for each of the 6 cores I have on my workstation for
maximum effort. Each script was processing (or was supposed to process)
around 137K points. Oddly enough while I was sleeping last night, all 6
programs quit running, and when I checked this morning using the "ps"
command, no gp pari program was running at all. All 6 had terminated
after each one processing about 22K points and that was that.

How could a person go about troubleshooting this? Right now it appears
that the programs died on their own. The GP Pari command scripts were
also checked using the gp2c-run command and they appeared to pass the C
warnings flags, with no errors at all, so I am puzzled as to what really
happened. I checked the warn log in the /var/logs area, and nothing
shows up pertaining to gp-pari from yesterday and today. A few days ago,
the warn log showed a print malloc error and terminated the run but this
might have been my manual work.

I do have print statements embedded in the main program, but never found
them to be a problem like this before.

I am curious as to how to find out what is really happening here? I
restarted all 6 programs again, and I suppose when the count of output
reaches around 22K again, I could attempt to carefully monitor them.

Randall