ConnectionTestSuite.h hangs in MacOS

[phmasek]

I've traced a ConnectionTestSuite.h timeout failure to one line of code.

This line hangs when the testsuite runs. This results in a testsuite timeout without any Errors other than a timeout in accordance to this variable.

More specifically I believe it is a bug related to function ssize_t send(int, const void *, size_t, int); found in sys/socket.h.

[chrberger]

Can you please test changing the port from 12345 to 12347 in this test case:

OpenDaVINCI/libopendavinci/testsuites/ConnectionTestSuite.h

Line 128 in 0ccaa4e

void testTransfer() {

Let's test if the socket from the first test case is in a "closing" state making it not readily available for the last test case.

[phmasek]

Didn't work. I get the same issue after changing both the acceptor port and connection port to 12347.

[chrberger]

Can you systematically disable two out of the three test cases by added "no" to the test cases' method name to see, what test case passes and what no?

[phmasek]

testErrorHandler()and testAcceptAndConnect() work flawlessly by themselves while testTransfer() does not work no matter configuration.

[phmasek]

It actually seems to be failing at this line https://github.com/se-research/OpenDaVINCI/blob/master/libopendavinci/src/odcore/data/Container.cpp#L254

This is probably a result of the performance improvements which were committed here. Not sure why this works in Linux but not MacOS, any clue?

[chrberger]

@pletron: is this issue still relevant?

[phmasek]

@chrberger I've done some digging. It seems that the function pubsetbuf at line 212 and 227 does not do anything in the standard c++ library in Mac OS, it simply returns this.

Here is a post regarding the same issue, however, the link refers to an issue in Microsoft Visual Studio. I had a look in the c++ library files in Mac OS and found that the case is the same for Mac OS. Here is a snippet with the function from Mac OS.

A possible fix might be to use the function sputn (reference) although I'm not very familiar with these parts of c++.

[chrberger]

@Pletron Thanks for the description; your pastebin snippet refers to the super-class basic_streambuf. The comment suggests that deriving subclasses shall overwrite that behavior. Can you verify that stringstream is indeed not overwriting that behavior?

[chrberger]

@Pletron The lines 212 and 227 could also be changed with an #ifdef directive separating MacOS/Win from "correct" implementations by simply copying the content from vector into bufferIn (even though that might be expensive).