Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Windows CI: a 1-row netCDF grid is read back with a collapsed y range (test/grdtrend/trend_xy_plot.sh)

オープン
  • 何か問題がありますか？
#9,261 コメント 4 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
15/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
活発
技術スタック
c
領域
data, testing

調査の方向性

The bug is in gmtnc_grd_info in src/gmt_nc.c, where the y range of a 1-row grid comes only from actual_range (around lines 774-803). Reproduce with gmt grdmath to make row.grd, then gmt grdinfo -C row.grd, and compare with test/grdtrend/trend_xy_plot.sh. Done means a 1-row grid reads back with y range -0.2/0.2 on the Windows CI build, without the #pragma optimize workaround. The maintainers have not chosen a fix yet, so confirm the approach first.

索引モデルが issue の本文から書いたものです。

説明

bug

I asked Claude to look for a solution to the failure of this test in the Windows CI, and this is its analysis. I am posting it to ask what you prefer to do about it.

test/grdtrend/trend_xy_plot.sh fails only in the Windows CI (MSVC 14.51.36231, Visual Studio 2026 image, Release /O2 /Ob2 /DNDEBUG, vcpkg netCDF 4.9.3): grdtrend prints Grid y increment <= 0.0 [data.grd] and crashes. I would like to ask what you prefer for this one, because I could not find the root cause.

What fails. The grid written by grdmath is valid and reads fine on Linux and through GDAL, but on the Windows CI the same call reads a 6x1 grid with y range 0/0:

gmt grdmath -R-1.2/1.2/-0.2/0.2 -I0.4 -r 0.5 X ADD X X MUL ADD X 3 POW ADD = row.grd
gmt grdinfo -C row.grd
  • good: row.grd -1.2 1.2 -0.2 0.2 -0.5 3.5 0.4 0.4 6 1 1 0
  • CI: row.grd -1.2 1.2 0 0 -0.5 3.5 0.4 0 6 0 1 0 (y range 0/0, y_inc 0, 0 rows)

It fails when the test runs alone (no -j4), and also outside the test (https://github.com/GenericMappingTools/gmt/actions/runs/38145255398). A 1-column x 6-row grid reads fine, GDAL reads y#actual_range={-0.2,0.2} fine, and the only netcdf.dll copies on PATH are vcpkg's. For a 1-row grid the y range comes only from actual_range (there is no usable y vector), in the y block of gmtnc_grd_info (src/gmt_nc.c, around lines 774-803); the x block has the same structure.

What I tried.

  • Any debug print inside gmtnc_grd_info, even a passive one, makes the failure disappear.
  • #pragma optimize("", off) around gmtnc_grd_info only, with nothing else changed, makes the test pass (https://github.com/GenericMappingTools/gmt/actions/runs/38176185877).
  • ASAN and UBSAN builds on Linux find nothing in this path, and I found no undefined behaviour by reading it.
  • A gmt 6.8.0_f6039ec build from September on a Windows 10 PC reads the grid correctly, but I don't know its toolset or flags. gmtnc_grd_info is identical to the one in master.

So it looks like an optimizer problem (compiler bug or an undefined behaviour that /O2 exploits), but I could not prove either.

Questions.

  1. Does anyone with a local MSVC 14.50 or 14.51 build reproduce the grdinfo output above?
  2. The 6.7.0 Windows binaries were linked with MSVC 14.50. Does the official 6.7.0 binary read the 1-row grid correctly? If not, users are affected and not only the test.
  3. How do you prefer to handle it: (a) the #pragma optimize change above, guarded by _MSC_VER (I have a 6-line patch ready), (b) mark the test with # GMT_KNOWN_FAILURE_WINDOWS, or (c) something else?

Reviewed with Claude Opus 5.5 (read-only review of the analysis). Written with Claude Sonnet 5.5.

主要言語
C
スター
985
フォーク
414
平均マージ
22時間 51分
マージ済み PR（30日）
35

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

GenericMappingTools/gmt のほかの issue

GenericMappingTools/gmt の issue をすべて見る

似ている issue

C の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。