#63 Network Wrapper fails to close


Server Control Board wraps a device which reads and writes from a socket among other things. Sometimes -maybe if blocket on a read/write operation?- the server control board fails to close when requested. It does not reach the close function of the wrapped device. Is the thread in charge of serving remote control board commands also in charge of closing the device? If that were the case, if that thread is blocked, you're unable to close the device. The only solution is killing the device.


  • Paul Fitzpatrick

    Hi Pol,
    Thanks for the report. Just to be clear, what method is used to request the device to stop? In wamtest.cpp there is a test for a keypress. On the mailing list, you talked about sending SIGTERM, with a response that looked like it was coming from a yarpdev instance.

    The thread in charge of serving commands is not the thread that closes the device (for the code you've attached, that would be your main thread). However, it looks like the ServerControlBoard close method makes no request to interrupt the port(s) serving commands, in which case the main thread would block while shutting down those ports if the ports in turn were blocked. I'll take a look at fixing this.

  • Paul Fitzpatrick

    • assigned_to: nobody --> eshuy
  • Paul Fitzpatrick

    I've added a port interrupt to the ServerControlBoard close method in YARP SVN. Does this have any affect for you? I haven't manage to replicate your problem.

  • Pol Monsó

    Pol Monsó - 2009-10-22

    To stop the ServerControlBoard I'm sending a SIGTERM, I didn't know there was another way. Usually, it reaches the device close method but, from time to time, it does not. I haven't found the source yet, so I'm not able to reproduce it...

    It just started happening about several weeks ago, when the async thread launch was introduced, however, it may not have anything to do with the bug.

    I'll update to the latest version of yarp and let you know if it happens again.

  • Pol Monsó

    Pol Monsó - 2009-10-22

    I've just noticed that I'm sending SIGINT, not SIGTERM, that is Ctrl+c on the terminal where the ServerControlBoard has been launched. What would be the expected exit keypress you mentioned? Is there anyway to call the close method from the remoteControlBoard?

  • Paul Fitzpatrick

    If you are using yarpdev, we treat SIGINT in just the same way as SIGTERM. The keypress I mention is from the test code you attached (wam_test.cpp or a name like that). I just need to be clear if we are talking about killing that program, or yarpdev. Can you tell me exactly what program is being killed? Then I can check its interrupt handlers.

    The remoteControlBoard does not have the authority to call close.

    There is a termination message you can send to yarpdev remotely, but I'm not sure if we are talking about yarpdev yet or not.

    By the way, did the change mentioned in comment dated 2009-10-22 03:27 below change anything for you?

  • Pol Monsó

    Pol Monsó - 2009-10-23

    I'm using yarpmoddev to call the device, that is:
    ./yarpmoddev --name /wamarm --device wamArm
    which is the one I signal when the behaviour described occurs.

    I haven't tried the latest version yet, however, I haven't found how to reproduce it still, so I won't be able to prove it has worked yet...

    Don't rely on wamtest.cpp, it's just a testing code I made some time ago, i'm not using it anymore, just yarpmoddev and a YARP client which calls the device interfaces through remote and serverControlBoard.

    If you need the code wrapped by the device wamArm (the wamDriver) I can post it.

    In a nutshell, I'm running yarpmoddev casting the device I mentioned wrapped by ServerControlBoard. I'm still with yarp 2.2.2, I'll update to the latest version as soon as possible and let you know.


  • Lorenzo Natale

    Lorenzo Natale - 2013-02-15
    • status: open --> closed

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.

No, thanks