ome / ome-files-cpp Goto Github PK

I'm trying to integrating ome-files in a CMake C++ project. In my hands, the following is a minimal CMakeLists.txt to successfully build a ome-files project. I am building on macOS 10.12.6 with clang 4.0.

cmake_minimum_required(VERSION 3.9)
project(ome-test) 

set(CMAKE_CXX_STANDARD 11)

set(CMAKE_PREFIX_PATH "$ENV{OME_FILES_ROOT}")

find_package(Boost COMPONENTS log iostreams) # <- Build fails without this line
find_package(OMEXML REQUIRED)
find_package(OMEFiles REQUIRED)

include_directories($ENV{OME_FILES_ROOT}/include)
add_executable(ome-test main.cpp)
target_link_libraries(ome-test OME::Files)

If I exclude the find_package(Boost COMPONENTS log iostreams) line (or use different boost components) CMake fails with the following error:

CMake Error at CMakeLists.txt:14 (add_executable):
  Target "ome-test" links to target "Threads::Threads" but the target was not
  found.  Perhaps a find_package() call is missing for an IMPORTED target, or
  an ALIAS target is missing?


CMake Error at CMakeLists.txt:14 (add_executable):
  Target "ome-test" links to target "Threads::Threads" but the target was not
  found.  Perhaps a find_package() call is missing for an IMPORTED target, or
  an ALIAS target is missing?


CMake Error at CMakeLists.txt:14 (add_executable):
  Target "ome-test" links to target "Boost::log_setup" but the target was not
  found.  Perhaps a find_package() call is missing for an IMPORTED target, or
  an ALIAS target is missing?


CMake Error at CMakeLists.txt:14 (add_executable):
  Target "ome-test" links to target "Boost::log" but the target was not
  found.  Perhaps a find_package() call is missing for an IMPORTED target, or
  an ALIAS target is missing?


CMake Error at CMakeLists.txt:14 (add_executable):
  Target "ome-test" links to target "Boost::iostreams" but the target was not
  found.  Perhaps a find_package() call is missing for an IMPORTED target, or
  an ALIAS target is missing?

[SNIP]

CMake Error at CMakeLists.txt:14 (add_executable):
  Target "ome-test" links to target "Boost::filesystem" but the target was
  not found.  Perhaps a find_package() call is missing for an IMPORTED
  target, or an ALIAS target is missing?

As far as I understand, find_package(OMEFiles REQUIRED) should automatically import its dependencies and this line should not be required. This error occurs when using either the downloaded ome-files build or when using a freshly compiling super-build from head.

I have the build working now but thought I'd let you know as it look a while to figure this out.

see:

• ome-files-cpp/lib/ome/files/CoreMetadata.h

  Line 89 in e5a4d5c

  /// Number of channels.

• http://lists.openmicroscopy.org.uk/pipermail/ome-devel/2018-April/004183.html

Using the simple zzuf fuzzer I tried feeding fuzzed images into the info tool shipped with ome-files-cpp and found that large ImageWidth and ImageLength parameters in the TIFF header will cause info to attempt to allocate very large amounts of memory, leading to OOM kills in my testing VM, even for very small input files. Anecdotally, the libtiff tiffinfo tool also allocates large amounts of memory when examining these files but I could successfully run tiffinfo against these where I couldn't run the info tool.

I noticed that someone else filed a similar bug against libtiff last year with no resolution yet. It's not obvious that this is a bug but it could be a DoS vector if ome-files-cpp backs a web application that accepts user data.

Here is a set of examples. Each of these is derived from the single-channel.ome.tif from the OME-TIFF sample data and is about 70k; they can lead to memory allocations of 8GB+:
examples.zip

The current behaviour when writing a plane is to flush tiles sequentially. This was, I think, done for the purpose of strict compatibility with the Bio-Formats TiffWriter/TiffSaver which strictly require writing in order. Looking at the libtiff documentation, libtiff does not have this restriction, and it should be possible to flush files as soon as they are completed. It would even be possible to support rewriting. This would require the IFD flush method to be adjusted to update the behaviour for coverage checking and tile ordering.

See this mail for further details.

Consider the following steps:

• git clone [email protected]:ome/ome-files-cpp.git
• mkdir build
• cd build
• cmake ..
• make
• grep OME_FILES_VCS_SHORTREVISION lib/ome/files/Version.h
  #define OME_FILES_VCS_SHORTREVISION "3a25964"

Now if you change branches in the repo which has a different HEAD commit and rebuild with make and call grep OME_FILES_VCS_SHORTREVISION lib/ome/files/Version.h again the output has not changed.

A fix could be to regenerate Version.h at every make invocation.

I've compiled ome-files-cpp on my debian jessie machine.
The creation of the pdf manual was not successfull, this stopped the build process.
See make-doc.txt for the build log.

$doxygen --version
1.8.13
$sphinx-build --version
Sphinx (sphinx-build) 1.5a1

With a current build, I'm seeing lots of this type of warning/error:

[warning] Unable to handle reference of type: St10shared_ptrIN3ome3xml5model9ReferenceEE

That's std::shared_ptr<ome::xml::model::Reference> in English.

That's indicative of something wrong in the model code, or invalid input. The former is most likely. Either way, it's something which should be investigated and fixed. Has there been a change to the model without a corresponding update to the C++ model code or templates?