[CCPPETMR/SIRF] gadgetron time-out errors on Travis OSX DEVEL_BUILD (#279)

[Kris Thielemans]

On SIRF Travis, we consistently get errors on the 2 DEVEL_BUILD=ON builds on OSX. Example is here. Compilation is fine, but all MR Python test fail with

connection to gadgetron server failed

The gadgetron log does contain messages like

GadgetStreamController, unable to read message identifier

which is worrying, but it appears to keep on going. Some context:

12-21 17:16:29.033 DEBUG [Gadget.h:123] Shutting down Gadget (EndGadget)
12-21 17:16:29.033 DEBUG [GadgetStreamController.cpp:80] Stream closed
12-21 17:16:29.033 DEBUG [GadgetStreamController.cpp:81] Closing writer task
12-21 17:16:29.033 ERROR [GadgetStreamController.cpp:74] GadgetStreamController, unable to read message identifier
12-21 17:16:29.034 DEBUG [GadgetStreamController.cpp:83] Writer task closed
12-21 17:16:29.034 DEBUG [GadgetStreamController.cpp:159] handle_close called
12-21 17:16:29.034 ERROR [GadgetStreamController.cpp:74] GadgetStreamController, unable to read message identifier
12-21 17:16:29.034 INFO [GadgetStreamController.cpp:164] Shutting down stream and closing up shop...
12-21 17:16:29.034 DEBUG [GadgetStreamController.cpp:159] handle_close called
12-21 17:16:29.034 INFO [GadgetStreamController.cpp:190] Stream is closed
12-21 17:16:29.034 INFO [GadgetStreamController.cpp:164] Shutting down stream and closing up shop...
12-21 17:16:29.034 INFO [GadgetStreamController.cpp:190] Stream is closed

But then at some point the log ends abruptly, it seems always at the same point (although I didn't check this very carefully)

12-14 00:56:17.524 DEBUG [AcquisitionAccumulateTriggerGadget.cpp:436] Trigger (1) occurred, sending out 1 buckets
12-14 00:56:17.524 DEBUG [BucketToBufferGadget.cpp:735] Encoding space : 0 - FOV : [ 600 300 6 ]  - Matris size : [ 512 256 1 ] 
12-14 00:56:17.524 DEBUG [BucketToBufferGadget.cpp:740] Sampling limits : - RO : [ 0 128 255 ] - E1 : [ 0 128 255 ] - E2 : [ 0 0 0 ]
12-14 00:56:17.524 DEBUG [BucketToBufferGadget.cpp:618] Data dimensions [RO E1 E2 CHA N S SLC] : [256 256 1 8 1 1 1]
12-14 00:56:17.529 DEBUG [BucketToBufferGadget.cpp:222] End of bucket reached, sending out 1 ReconData buffers

and then no more messages. This seems to be after/in the SimpleReconGadget as you can see in the log file.

@rijobro, I'm assuming that it all works for you on your Mac?
@evgueni-ovtchinnikov , any ideas?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

[Richard Brown]

Confirmed that this works for the versions of ISMRMRD/Gadgetron with DEVEL_BUILD set to OFF, but not with it set to ON.

We're baffled as to why it works on the Travis Superbuild with DEVEL_BUILD=ON, when it doesn't work on my machine or the Travis SIRF...

Are we agreed to downgrade the devel versions of ISMRMRD/Gadgetron such that they match the versions with DEVEL_BUILD=OFF?

[Richard Brown]

@KrisThielemans you mentioned that some people might want functionality that's in the more recent versions of ISMRMRD & Gadgetron. We could have different versions depending on whether the system is linux or osx? i.e.,

if (DEVEL_BUILD)
   if (OSX)
      set(GADGETRON_tag)
   else()
      set (GAGDETRON_tag)
   endif()
else()
   set(GADGETRON_tag)
endif()

[Kris Thielemans]

it's going to be somewhat confusing for users, but we can hope it's a temporary work-around, so let's do this. (I guess if (APPLE)).

However, let's hope we can help resolve this soon. I've created gadgetron/gadgetron#719 for this.

[Kris Thielemans]

Gdgetron integration tests in our case (assuming standard SuperBuild):

cd /whereever/SB-build/sources/gadgetron/test/integration
python3 get_data.py
python3 run_all_tests.py -I /wherever/SB-build/INSTALL ./test_cases.txt

There's quite a lot of data to download. Note that it puts it in the sources/gadgetron/test/integration directory. Might be best to afterwards move it elsewhere.

[Kris Thielemans]

And

cd /whereever/SB-build/builds/gadgetron/build/test
ctest -VV

[Kris Thielemans]

Testing confirmed by @dchansen at gadgetron/gadgetron#719. @rijobro can you have a look at this later?

[Richard Brown]

Sure

[Kris Thielemans]

Closed #279.

[Kris Thielemans]

This was resolved upstream, see gadgetron/gadgetron#719