Fix GPTL to support 7-digit PIDs and fix some error handling

[billsacks]

Description

GPTLget_memusage had a hard-coded string size that only supported PIDs up to 6 digits. This caused problems on derecho, where PIDs can be up to 7 digits. This PR allows for significantly longer PIDs (longer than will be encountered in practice) and adds error checking of the relevant sprintf (changing it to snprintf with a check). In addition, this fixes the error check on another line, as noticed by Claude.

Changes were made by Claude and carefully reviewed by myself

• Closes length of local variable file in GPTLget_memusage too short #5052

Testing

I tested this via SMS_D_Ld2_P128x1.f19_g17.X.derecho_intel

In addition, with this diff:

diff --git a/CIME/non_py/src/timing/GPTLget_memusage.c b/CIME/non_py/src/timing/GPTLget_memusage.c
index 7c5b8273c..c0dc065fc 100644
--- a/CIME/non_py/src/timing/GPTLget_memusage.c
+++ b/CIME/non_py/src/timing/GPTLget_memusage.c
@@ -108,7 +108,7 @@ int GPTLget_memusage (int *size, int *rss, int *share, int *text, int *datastack
 #elif (defined HAVE_SLASHPROC)
   FILE *fd;                       /* file descriptor for fopen */
   int pid;                        /* process id */
-  char file[32];                  /* full path to file in /proc */
+  char file[19];                  /* full path to file in /proc */
   int dum;                        /* placeholder for unused return arguments */
   int ret;                        /* function return value */
   static int pg_sz = -1;          /* page size */

I verified that we now get an abort rather than writing past the end of the file string:

dec2450.hsn.de.hpc.ucar.edu 0: get_memusage: path for pid 3147893 too long
dec2450.hsn.de.hpc.ucar.edu 0:  (shr_mem_init): GPTLget_memusage mrss0 failed

Checklist

• My code follows the style guidelines of this project (black formatting)
• I have performed a self-review of my own code
• My changes generate no new warnings
• I have added tests that exercise my feature/fix and existing tests continue to pass
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding additions and changes to the documentation

[billsacks]

@jgfouca @jasonb5 or others - do you know the story with this GPTL code? I know there is an external GPTL library, but it looks like we are out of sync with that, at least for this file, and from what I can tell, it looks like recent changes have been made directly to the GPTL here rather than patching upstream and pulling it in via a subtree / submodule.

[jgfouca]

I do not, sorry.

[rljacob]

We use the version kept in E3SM/share/timing which is almost the same code. They diverged from the upstream a long time ago. Back when CIME had a driver and data models, maybe this was the timing library built with those CIME-only applications. Or we include it as a feature that comes with CIME that a model can use?

[rljacob]

What application is @klindsay28 using that is linking to this version?

[billsacks]

CESM apparently is still using this version. At least, changes I made in this version clearly had an impact on a CESM run. I was surprised because I didn't think we were using any Fortran code from CIME anymore, but apparently we are. But if E3SM isn't using this version, I'll reassign it to someone on the CESM side for review.