Qpid
  1. Qpid
  2. QPID-2388

user-defined signals can cause process terminate

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 0.5
    • Fix Version/s: 0.7
    • Component/s: C++ Client
    • Labels:
      None
    • Environment:

      Linux

      Description

      I have an application which uses some user-defined signals for process control. When trying to bind qpid in to this application I've found that the client library spawns an i/o thread which ignores signal masks that the process has defined before making any calls to qpid. The i/o thread changes it's own signal mask to sigemptyset and is catching signals intended for another thread in my process which has called sigtimedwait(). The default action for user defined signals is process terminate, so the process is subsequently dying.

      I've made the following change to EpollPoller.cpp to work around the problem within my environment:

      $ diff -w EpollPoller.cpp EpollPoller-fixed.cpp
      248c248
      < ::sigemptyset(&sigMask);

      > ::sigfillset(&sigMask);

        Activity

        Azim Fatehi created issue -
        Hide
        Andrew Stitcher added a comment - - edited

        If you have a small test case that would help verify that we have fixed this bug.

        Also could you say what you would consider a correct solution to this issue:

        1. Whichever signals were blocked before using any qpid apis carry on being blocked. but changing the process signal mask after any qpid api has been called will have an undefined effect.

        2. Introducing a way to change the blocked signals on the fly.

        1. is feasible to implement in a short time. 2. would need very careful thinking and would be a non portable API to boot.

        Show
        Andrew Stitcher added a comment - - edited If you have a small test case that would help verify that we have fixed this bug. Also could you say what you would consider a correct solution to this issue: 1. Whichever signals were blocked before using any qpid apis carry on being blocked. but changing the process signal mask after any qpid api has been called will have an undefined effect. 2. Introducing a way to change the blocked signals on the fly. 1. is feasible to implement in a short time. 2. would need very careful thinking and would be a non portable API to boot.
        Hide
        Andrew Stitcher added a comment -

        try this line instead:
        ::pthread_sigmask(0, 0, &sigMask);

        Show
        Andrew Stitcher added a comment - try this line instead: ::pthread_sigmask(0, 0, &sigMask);
        Andrew Stitcher made changes -
        Field Original Value New Value
        Assignee Andrew Stitcher [ astitcher ]
        Hide
        Andrew Stitcher added a comment -

        On reflection I concluded that there is actually no very good reason to unmask signal handling whilst waiting for IO to happen: The only place we actually use signals in qpid is to cause the broker to exit, and a tester.

        So I fixed this issue by no longer unmasking signals here.

        Show
        Andrew Stitcher added a comment - On reflection I concluded that there is actually no very good reason to unmask signal handling whilst waiting for IO to happen: The only place we actually use signals in qpid is to cause the broker to exit, and a tester. So I fixed this issue by no longer unmasking signals here.
        Andrew Stitcher made changes -
        Status Open [ 1 ] Resolved [ 5 ]
        Fix Version/s 0.7 [ 12314455 ]
        Resolution Fixed [ 1 ]
        Justin Ross made changes -
        Status Resolved [ 5 ] Closed [ 6 ]

          People

          • Assignee:
            Andrew Stitcher
            Reporter:
            Azim Fatehi
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development