Zero the new entries when the shared library list grows

[Esteban82]

The Windows CI tests print "Failure while closing GMT z shared library" many times, so I asked Claude to look into it. This is its explanation:

GMT keeps its list of shared libraries in an array that grows by realloc once it has more than 8 entries. The new entries were never cleared, so the handle of the extra libraries held garbage, and closing the session passed it to dlclose/FreeLibrary. Depending on the platform this shows up as a crash or as a spurious "Failure while closing GMT ... shared library" message. The fix clears the new entries after each realloc.

Tested with:

This PR also adds test/gmt_core/sharedlibs_many.sh, which sets up 9 empty libraries and fails without the fix. I ran it on Linux and, without the fix, it fails with a segfault.

This should remove that message from the Windows CI and fix pssolar_missing_plusd, which fails only because of it.

Written with Claude Sonnet 5.5, reviewed with Claude Opus 5.5-

[joa-quim]

That cannot be true because I never saw any of those warnings in my local build. And even in the CI they start to appear a couple months ago, making me thing in some kind of issue with a dependency.

[Esteban82]

Claude's explanation of why this shows up in the Windows CI but not in a regular build:

In a regular build the plugin directory only has supplements. In the Windows CI, the vcpkg toolchain runs vcpkg z-applocal after building supplements.dll, which copies its dependencies (z, hdf5, hdf5_hl, netcdf, libcurl, szip, tinyxml2) into build/src/plugins/. GMT registers every .dll it finds there, so the list reaches 9 entries (core + the 8 DLLs in that folder) and the ninth (z.dll) lands in the part of the array that realloc did not clear.

How many DLLs are there in the plugin folder of your local build? If there are few, the bug cannot show up there.

About "a couple of months ago": the Windows job of tests.yml did not reach "Run full tests" before #9134 (Aug 25), so the messages could not appear in the logs before that date.

Another option would be to change the Windows workflow so that vcpkg does not copy those DLLs, by passing -DVCPKG_APPLOCAL_DEPS=OFF when configuring in tests.yml. That would avoid the trigger in the CI, but it would be a separate change. The bug itself would still be there for anyone with 9 or more libraries, so I think this fix is still needed.

[Esteban82]

The Windows job of this PR has finished: the message "Failure while closing GMT z shared library" no longer appears.

As a result, pssolar_missing_plusd now passes. The other Windows failures are unchanged and unrelated. dataserver_alias and WL_example_2 failed with a libcurl timeout, which is consistent with what we also see intermittently on Linux and macOS in recent runs.

The other Windows failures (GMT_splines, smooth, smooth_deriv, proj4_nox0y0, trend_xy_plot, eqearth) are unchanged and unrelated.

[joa-quim]

How many DLLs are there in the plugin folder of your local build?

Only the dlls that are dynamically loaded. In my case it is supplements_w64.dll, mbsystem.dll and gmtsar.dll but the case of the CI it should be only supplements.dll. Other dlls should not go into bin\gmt_plugins. At least on Windows.

[Esteban82]

the case of the CI it should be only supplements.dll. Other dlls should not go into bin\gmt_plugins. At least on Windows.

Ok, so I suspect we should try this:

Another option would be to change the Windows workflow so that vcpkg does not copy those DLLs, by passing -DVCPKG_APPLOCAL_DEPS=OFF when configuring in tests.yml.