fix(examples): allocate geo_z instead of geo_y in 3D readGeometry

[andrewwhitecdw]

Summary

In the readGeometry() helper of the C API examples, the 3D branch allocated *geo_y a second time instead of allocating *geo_z. The subsequent fscanf then wrote through the (NULL) *geo_z pointer, causing a segmentation fault whenever 3D geometry input was used.

Root cause

*geo_x = (double *)malloc(n * sizeof(double));
*geo_y = (double *)malloc(n * sizeof(double));

if (dimension == 3)
{
    *geo_y = (double *)malloc(n * sizeof(double));   // leaks geo_y,
                                                      // geo_z never allocated
    for (int i = 0; i < n; i ++)
        if (3 != fscanf(fin, "%lf %lf %lf\n",
                        *geo_x + i, *geo_y + i, *geo_z + i))  // write to NULL

Callers initialize gz = NULL, pass &gz, and later free(gz) — so *geo_z is expected to be allocated here.

Fix

Allocate *geo_z in the 3D branch (one-word change in each of examples/amgx_capi.c and examples/amgx_capi_multi.c).

Testing

Full AMGX build/tests were not run (GPU/CUDA-heavy dependency). Instead, readGeometry() was extracted verbatim into a standalone C harness and compiled with gcc -Wall -Wextra (clean):

• Fixed version: 3D and 2D geometry files parse correctly, geo_z values verified -> PASS (exit 0).
• Original (pre-fix) version: segfaults on the 3D input (exit 139, SIGSEGV) — confirming the bug and the fix.

Why existing tests missed it

The example programs are not exercised with 3D geometry input files by any automated test; the 2D path (the common case) works fine because geo_z is unused there.