yarp segfault on exit when YARP_EXPERIMENTAL_CXX11=true

[randaz81]

Observed on Win32, compiled with VS2013 ULTIMATE.
Almost all yarp applications (including the yarp name server) are crashing after a CTRL+C.

Still untested on Linux.

[randaz81]

In particular I get segfault in file CXX11SemaphoreImpl.h near:

  void wait()
    {
        std::unique_lock<std::mutex> lock(mutex);
        count--;
        if (count<0) {
            cond.wait(lock,
                      [this] { return wakeups > 0; });
            wakeups--;
        }
    }

[francesco-romano]

have you tried in Debug mode, so to obtain (hopefully) more information about the segfault, e.g. line number?

[randaz81]

The error is on std::unique _lock. From time to time I get one of the two following error messages:

Unhandled exception at 0x7710C334 (ntdll.dll) in yarpserver.exe: 0xC000000D:
An invalid parameter was passed to a service or function.

Unhandled exception at 0x76F4A6F2 in yarpserver.exe: Microsoft C++ exception:
Concurrency::scheduler_resource_allocation_error at memory location 0x0344F8F8.

The crash happens while the destructor YarpRunInfoVector::~YarpRunInfoVector() is called. The function is safe in other contexts.

[drdanz]

We tested with @randaz81 and the only issue with YARP_EXPERIMENTAL_CXX11 seems to be in CXX11SemaphoreImpl.h.
The other C++11 implementations seem to be ok. I think we should start enabling them by default (except for the one crashing) and see if some issue come out. @randaz81 Is this ok for you?

[damn1]

This seems to be a VS2013 bug involving the std:mutex. This problem does not occur with VS2015.
Since the problem arise from a lock called by destructor ~YarpRunInfoVector() it seems to me the same problem described here:
https://connect.microsoft.com/VisualStudio/feedback/details/1282596

[traversaro]

Great @damn1 ! We should add this to reasons to drop support for VS2013 and just support VS2015/2017 .

[drdanz]

Unfortunately, this also means that we cannot switch to the c++11 implementation until we drop support for VS2013

[claudiofantacci]

Unfortunately, this also means that we cannot switch to the c++11 implementation until we drop support for VS2013

Shall we? 🍻

Seriously speaking, is it something that we must support?
Is it worth supporting it and delaying full/standard C++11 adoption?

[drdanz]

I vote for dropping VS2013 and debian jessie in the next release cycle, i.e. at some point between next the release (next monday) and the following 4 months.
Anyway we should check with the windows users...

[pattacini]

Honestly, I thought VS2013 was already dropped 😛

[claudiofantacci]

@drdanz I see.
Yes, we should check it. And we should also check how painful it would be for a Windows user to switch to a newer version of VS, say VS15.

[pattacini]

@claudiofantacci aside from installing the new toolchain - which can take up much more space on the disk wrt VS2013 - there ain't anything scary or painful in the upgrade.

[claudiofantacci]

@claudiofantacci aside from installing the toolchain, there ain't anything scary or painful in the upgrade.

I was guessing so as well, but preferred to ask.
There should be no issue hindering us from unsupporting VS13.

[lornat75]

I have VS2013! 😄 but I have no objections, especially if we give some time to upgrade before dropping it.

[drdanz]

So, the plan might be:

• Release YARP 2.3.72
• Make an announcement that support for VS2013 will be dropped on the devel branch
• Wait for some time
• Drop support for VS2013
• Get rid of the YARP_EXPERIMENTAL_CXX11 option
• Close this issue

[drdanz]

YARP 2.3.72, we should get rid of the YARP_EXPERIMENTAL_CXX11 option in devel

[drdanz]

Fixed in #1623