NOTE: The netcdf-porting mailing list is no longer active. The list archives are made available for historical reasons.
Ah, sorry. GMT (http://gmt.soest.hawaii.edu/) is one of your oldest 'clients'. It uses netcdf for 20 years but up to now with 3.6.x series.Wow, looks very nice! I would certainly love to stop by and learn more about it! ;-)
Ed, You'll be most welcome to pass by when you need to do a nice map.
I am trying to move to netcdf4 but this crash (Windows only) is a show stopper. BTW the test 64 bits version of "nctest" crashes on the "ncsync" step. The debugger shows that this happens at line 709 of ......\netcdf-4.1.2b\nctest\cdftests.c if (ncvarput(ncid0,dd_id,dd_start,dd_edges,(void *)dd_vals) == -1) { where ncid0 has the suspicious value of 65536The value is not suspicious. NetCDF-4 ncids represent more than just a file, they also include an integer for the group. The file number is stored in the first 16 bits, the group in the final 16 bits. This is all part of the v2 API. Unless you are using the v2 API, I suggest you simply disable it. It is provided for backward compatibility only. For windows builds, just don't include the libdispatch/v2i.c code, and set the preprocessor macro NO_NETCDF_2. And then don't run any of the tests under nctest. (There are also some v2 tests scattered about in other directories, which should also be turned off.) The V2 API does provide some additional testing for the build, but the v3 API tests are already very comprehensive. Certainly no one should be writing new code with the v2 API.
Ok, I called it "suspicious" because of its high number but I did not know what I was looking for.
Anyway, I found the real cause. The "Boom" occurs at line 46 of (numbering from 4.1.2beta)
libdispatch/file.c
#endif /* USE_PARALLEL */
{
FILE *fp;
int i;
fp = fopen(path, "r"); <= HERE HERE HERE
if(fp == NULL)
return errno;
i = fread(magic, MAGIC_NUMBER_LEN, 1, fp);
if(i != 1)
return errno;
fclose(fp);
}
when "path" in
fp = fopen(path, "r");
is NULL
When adding the precaution safe valve
if (path == NULL)
return errno;
the crash vanishes and the GMT test runs fine.
I think it won't harm for you guys to add this test, perhaps wrapped in
a #ifdef WIN32
OK, thanks Joaquim! I am reconsidering my decision to go with mingw. It's proved to be rather problematic, and, guess what, not what anyone actually wants. This is a classic engineering mistake, and if I had gotten a tattoo every time I made it, I would be having a hard time finding an empty patch of skin for a new one.
I think there is interest in a MingW build (to Octave for example), but IMO it should not be seen as "the Windows" solution as it serves different targets.
So now I think the best way to proceed would be an officially sanctioned windows build with visual studio. We would then keep it up to date with the unix-based build system.
That would be nice. Thanks Joaquim
netcdf-porting archives: