Ticket #98 (closed defect: wontfix)

Opened 11 years ago

Last modified 11 years ago

xuvtools: cannot load files in HDF5-format anymore (win64)

Reported by: ne704 [niko@… Owned by: ne704
Priority: blocker Milestone:
Component: xuvtools Version:
Keywords: xuvtools, error, win64, hdf5, win32 Cc: developers@…

Description

current trunk (r3014) compiles fine (release) under win64, but I'm not able to load Imaris-Files. LSMs still work without problems.

Tried this with several different .ims files, every time the same result. Here's the error message from the first file of our second set of testdata at xuvtools.org:

NOTE: File Z:/xuv_testfiles/xuvtools.org/To15100740xm/To15100740xma001.ims does not appear to be a supported file and  will be ignored.
Error was: Could not retrieve global attribute /DataSetInfoDirectoryName

Change History

Changed 11 years ago by emmenlau

There is a java-based freeware on the hdf5 website, called hdfview. Could you try and open the file with that, to see if /DataSetInfoDirectoryName exists? In hdfview, directories are shown at the left, attributes at the bottom (when clicking on the directory or dataset).

Changed 11 years ago by ne704 [niko@…

  • keywords hdf5, win32 added; hdf5 removed

I've just done a bit more testing on this, the bug applies to win32 as well.

Tests with older binaries I kept on the machine here yield that the bug was introduced somewhere in the following commit-range:

May I add one more suggestion? It's called "git-bisect" ;-)

Changed 11 years ago by emmenlau

I think the code that triggers this error is in inspectImaris(), here:

src/GenFile.cc:1289:    std::string DataSetInfoDirectoryName;
src/GenFile.cc:1290:    objFile.readAttribute( DataSetInfoDirectoryName,
src/GenFile.cc:1291:                           "DataSetInfoDirectoryName", "", "/");

Line 1289 is this first string that is read from any Imaris file, when opening the file. AFAIK there havent been any changes there lately.

If this code suddenly fails, I think something with string-reading from hdf5 is broken for you. This error doesnt happen on Linux, so I think it might actually be a Windows compilation issue? Have there been any changes to string encoding, UNICODE, etc.?

Changed 11 years ago by ne704 [niko@…

So if I got this right, a recompile of r2971 should now fail as well? I'm going to do a short check on that...

Changed 11 years ago by emmenlau

That is difficult to say. But I think it is safe to assume that this bug actually is "string reading from hdf5 fails on Windows" in the newer revisions/compiles you mention.

I don't remember if I mentioned it, but this might be related to Bug #100 where reading of environment variables (suddenly?) fails.

Changed 11 years ago by ne704 [niko@…

Well, recompiling r2971 leads to the supposed result: it has the same error trying to load HDF5 files...

This is very strange, since I don't remember having changed any settings *and* it happens on 32 bit as well, which is compiled on a completely different machine (native).

I don't think this is related to bug #100 since the issue described there also applies to many earlier versions (which are not affected by the bug discussed here).

Changed 11 years ago by ne704 [niko@…

  • owner changed from emmenlau to ne704
  • status changed from new to assigned

some more testing here:

  • completely cleaned source-tree (including thirdparty-stuff)
  • prepared build with xuvbuild.sh -q -r
  • opened XuvTools.sln in Visual Studio, switch to "Release", build solution

resulting binary has the same error as described above.

next try:

  • completely cleaned source-tree (including thirdparty-stuff)
  • prepared build with xuvbuild.sh -q -r
  • opened XuvTools.sln in Visual Studio, stick to "Debug", build solution
  • after the build has finished, switch to "Release", build solution

resulting binary works without error. debug-binaries always work, btw.

Changed 11 years ago by ne704 [niko@…

  • status changed from assigned to closed
  • resolution set to wontfix

Just an update with the findings from last week's digging on this issue.

Note the different compilers for Qt:

latest ICC (11.1.051), Qt-4.5.3 compiled with VisualStudio?

  • fresh SVN checkout, clean builddirs
  • a simple release-build using "xuvbuild.sh -v -q -b -r" leads to the error described above
  • cleaning up evereything
  • building debug via "xuvbuild.sh -v -q -b -d" delivers a debug-binary without the error
  • using the same build-tree for the release without cleaning up via "xuvbuild.sh -v --noclean -b -r" gives a working binary without the HDF5/imaris-issue

latest ICC (11.1.051), Qt-4.5.3 compiled with ICC

  • fresh SVN checkout, clean builddirs
  • building via "xuvbuild.sh -v -q -b -r" delivers a working release-binary

So my conclusion is to close this bug (at least unless someone else has the same problem(s)) since we have a workaround.

Note: See TracTickets for help on using tickets.