Opened 2 years ago

Last modified 5 months ago

#4069 new defect

Deal with UDP socket test failures on Ubuntu 12 (issues in boost 1.48)

Reported by: marcin Owned by:
Priority: medium Milestone: Outstanding Tasks
Component: Unclassified Version: git
Keywords: Cc:
CVSS Scoring: Parent Tickets:
Sensitive: no Defect Severity: N/A
Sub-Project: DHCP Feature Depending on Ticket:
Estimated Difficulty: 0 Add Hours to Ticket: 0
Total Hours: 0 Internal?: no

Description

The UDPSocket.sequenceTest fails on Ubuntu 12, with boost 1.48:
{{{[ RUN ] UDPSocket.SequenceTest?
../../../../../src/lib/asiolink/tests/udp_socket_unittest.cc:306: Failure
Value of: client_cb.getCalled()

Actual: false

Expected: true
../../../../../src/lib/asiolink/tests/udp_socket_unittest.cc:307: Failure
Value of: client_cb.getCode()

Actual: 32

Expected: 0
../../../../../src/lib/asiolink/tests/udp_socket_unittest.cc:308: Failure
Value of: client_cb.getLength()

Actual: 12345

Expected: sizeof(INBOUND_DATA)
Which is: 36
../../../../../src/lib/asiolink/tests/udp_socket_unittest.cc:314: Failure
Value of: equal(&data[0], &data[server_cb.getLength() - 1], INBOUND_DATA)

Actual: false

Expected: true
../../../../../src/lib/asiolink/tests/udp_socket_unittest.cc:318: Failure
Value of: server_address == client_remote_endpoint.getAddress()

Actual: false

Expected: true
../../../../../src/lib/asiolink/tests/udp_socket_unittest.cc:319: Failure
Value of: client_remote_endpoint.getPort()

Actual: 0

Expected: SERVER_PORT
Which is: 5301
/bin/bash: line 5: 25452 Segmentation fault (core dumped) /bin/bash ../../../../libtool --mode=execute ${dir}$tst
FAIL: run_unittests
======================================
1 of 1 test failed
}}}

I have chased this down to be an issue in boost 1.48, apparently fixed in boost 1.50 - I verified that tests pass with boost 1.50 on the same machine.

The test sets up two sockets and performs async receive and async send between them. Then it executes io_service.run_one twice to perform send and receive. It seems that send handler is executed as a result of two runs of io_service. The receive handler is not executed at all. Adding two more runs on io_service executes the receive handler and the test passes. So, the test needs four runs on io_service rather than two.

It has been also found that using BOOST_ASIO_DISABLE_EPOLL solves the problem on boost 1.48. We have to decide if we want to use BOOST_ASIO_DISABLE_EPOLL on boost versions prior to 1.50, or that we perhaps want to use this for all versions. In any case, this issue should be solved with reasonably high priority because it causes failures in our Continuous Integration system.

Subtickets

Change History (4)

comment:1 Changed 2 years ago by fdupont

I already expressed my opinion on jabber: we already disabled /dev/poll so there is no issue to disable poll too. Hopefully when we'll have to revisit both (i.e., use better alternative to select) old boost versions will be rare enough...

comment:2 Changed 2 years ago by hschempf

  • Milestone changed from Kea-proposed to DHCP Outstanding Tasks

per team meeting 7 oct, move to outstanding

comment:3 Changed 2 years ago by tomek

  • Milestone changed from DHCP Outstanding Tasks to Outstanding Tasks

Milestone renamed

comment:4 Changed 5 months ago by AndreiPavel

This issue is old, but seemingly still present. Sharing my findings.

On Ubuntu 17.04 with gcc 6.3, Boost 1.62 and optimization level -O0, this unit test now passes.

However, -O1 or higher makes it fail. Compiling with any of the optimization flags under -O1 (https://gcc.gnu.org/onlinedocs/gcc-6.3.0/gcc/Optimize-Options.html) that might introduce the fail yields that none of them are responsible (suggesting that -O1 optimizes further?!).

-DBOOST_ASIO_DISABLE_EPOLL=1 makes the unit test pass even with -O3.

Note: See TracTickets for help on using tickets.