Qpid
  1. Qpid
  2. QPID-2186

Windows - "vector iterator not dereferencable"

    Details

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

      XP-SP2, VS2008, Boost_1_35, Python 3.0.1, ruby 1.8.6 and working copy revision: 828034

      Description

      i have the direct listener built from the examples, and it throws the above exception when there is no broker running at the supplied address. It does connect and get messages when the broker is running.

      The call stack when the exception occurs:
      ----------------------------------------------

      > msvcp90d.dll!std::_Debug_message(const wchar_t * message=0x00fa7e28, const wchar_t * file=0x00fa7798, unsigned int line=98) Line 24 C++
      qpidcommond.dll!std::_Vector_const_iterator<boost::intrusive_ptr<qpid::sys::TimerTask>,std::allocator<boost::intrusive_ptr<qpid::sys::TimerTask> > >::operator*() Line 98 + 0x14 bytes C++
      qpidcommond.dll!std::_Vector_iterator<boost::intrusive_ptr<qpid::sys::TimerTask>,std::allocator<boost::intrusive_ptr<qpid::sys::TimerTask> > >::operator*() Line 340 C++
      qpidcommond.dll!std::vector<boost::intrusive_ptr<qpid::sys::TimerTask>,std::allocator<boost::intrusive_ptr<qpid::sys::TimerTask> > >::front() Line 790 + 0x24 bytes C++
      qpidcommond.dll!std::priority_queue<boost::intrusive_ptr<qpid::sys::TimerTask>,std::vector<boost::intrusive_ptr<qpid::sys::TimerTask>,std::allocator<boost::intrusive_ptr<qpid::sys::TimerTask> > >,std::less<boost::intrusive_ptr<qpid::sys::TimerTask> > >::top() Line 207 C++
      qpidcommond.dll!qpid::sys::Timer::run() Line 114 + 0xf bytes C++
      qpidcommond.dll!`anonymous namespace'::runRunnable(void * p=0x101e63d0) Line 32 + 0xf bytes C++
      msvcr90d.dll!_callthreadstartex() Line 348 + 0xf bytes C
      msvcr90d.dll!_threadstartex(void * ptd=0x0116b6d8) Line 331 C
      kernel32.dll!7c80b729()
      [Frames below may be incorrect and/or missing, no symbols loaded for kernel32.dll]
      boost_program_options-vc90-mt-gd-1_35.dll!003a0043()
      msvcr90d.dll!_mbsnbcpy_l(unsigned char * dst=0x00730063, const unsigned char * src=0x00000073, unsigned int cnt=6619236, localeinfo_struct * plocinfo=0x00610066) Line 57 + 0x3d bytes C++

      1. screenshot-1.jpg
        31 kB
        Larry Roloson

        Activity

        Hide
        Andrew Stitcher added a comment -

        Minor changes to previous change, including a fix to lock correctness.

        Show
        Andrew Stitcher added a comment - Minor changes to previous change, including a fix to lock correctness.
        Hide
        Andrew Stitcher added a comment -

        I don't think half this fix can do anything as the condition tasks.empty() is checked at the very top of the while loop and nothing else can be removing tasks from the tasks priority queue but this loop itself.

        Monitor::ScopedLock l(monitor);
        while (active) {
        if (tasks.empty())

        { monitor.wait(); }

        else {
        intrusive_ptr<TimerTask> t = tasks.top();
        tasks.pop();
        assert(!(t->nextFireTime < t->sortTime));
        ....
        if (t->cancelled)

        { ... continue; }

        else if(Duration(t->nextFireTime, start) >= 0)

        { >>>> HERE tasks.empty() COULD BE TRUE continue; }

        else

        { // If the timer was adjusted into the future it might no longer // be the next event, so push and then get top to make sure // You can only push events into the future t->sortTime = t->nextFireTime; tasks.push(t); }

        if (!tasks.empty())
        monitor.wait(tasks.top()->sortTime);
        }
        }

        so the second !tasks.empty() is a tautology as we already know it must be true - every path which ends with the task popped has a continue and the path that leads there pushes it just before.

        However as noted above it could be empty at the first tasks.top() though - I'd like to take a short look at this.

        Show
        Andrew Stitcher added a comment - I don't think half this fix can do anything as the condition tasks.empty() is checked at the very top of the while loop and nothing else can be removing tasks from the tasks priority queue but this loop itself. Monitor::ScopedLock l(monitor); while (active) { if (tasks.empty()) { monitor.wait(); } else { intrusive_ptr<TimerTask> t = tasks.top(); tasks.pop(); assert(!(t->nextFireTime < t->sortTime)); .... if (t->cancelled) { ... continue; } else if(Duration(t->nextFireTime, start) >= 0) { >>>> HERE tasks.empty() COULD BE TRUE continue; } else { // If the timer was adjusted into the future it might no longer // be the next event, so push and then get top to make sure // You can only push events into the future t->sortTime = t->nextFireTime; tasks.push(t); } if (!tasks.empty()) monitor.wait(tasks.top()->sortTime); } } so the second !tasks.empty() is a tautology as we already know it must be true - every path which ends with the task popped has a continue and the path that leads there pushes it just before. However as noted above it could be empty at the first tasks.top() though - I'd like to take a short look at this.
        Hide
        Steve Huston added a comment -

        I believe this is fixed at trunk r939117. It was triggering in one of the unit_tests and is not now. Larry, if you have an opportunity to verify this in your environment, that would be great.

        Show
        Steve Huston added a comment - I believe this is fixed at trunk r939117. It was triggering in one of the unit_tests and is not now. Larry, if you have an opportunity to verify this in your environment, that would be great.
        Hide
        Larry Roloson added a comment -

        This is the dialog that pops up when the cable is unplugged

        Show
        Larry Roloson added a comment - This is the dialog that pops up when the cable is unplugged
        Hide
        Larry Roloson added a comment -

        I tested the direct listener with the latest version of Timer.cpp and I still get the exception when the network connectivity is dropped (tested by unplugging the network cable on the windows server). I will try to attach a screen shot of the error.

        Show
        Larry Roloson added a comment - I tested the direct listener with the latest version of Timer.cpp and I still get the exception when the network connectivity is dropped (tested by unplugging the network cable on the windows server). I will try to attach a screen shot of the error.
        Hide
        Steve Huston added a comment -

        I think this patch will do it, but I'd like some review before checking it in... Andrew Stitcher, can you please check this?

        Index: Timer.cpp
        ===================================================================
        — Timer.cpp (revision 886848)
        +++ Timer.cpp (working copy)
        @@ -136,7 +136,8 @@
        tasks.push(t);
        }
        }

        • monitor.wait(tasks.top()->sortTime);
          + if (!tasks.empty())
          + monitor.wait(tasks.top()->sortTime);
          }
          }
          }
        Show
        Steve Huston added a comment - I think this patch will do it, but I'd like some review before checking it in... Andrew Stitcher, can you please check this? Index: Timer.cpp =================================================================== — Timer.cpp (revision 886848) +++ Timer.cpp (working copy) @@ -136,7 +136,8 @@ tasks.push(t); } } monitor.wait(tasks.top()->sortTime); + if (!tasks.empty()) + monitor.wait(tasks.top()->sortTime); } } }

          People

          • Assignee:
            Andrew Stitcher
            Reporter:
            Larry Roloson
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development