Hi,

I've encountered a problem with XmlRpc++, using the Win32 port of ROS
and Visual C++ 2008. Sometimes, when my application was running, it
crashed with a assertion failure (in debug mode). I spent a lot of time
debugging my code and the ROS and XmlRpc++ sources and probably found
the reason of the problem in the work() method of XmlRpcDispatch:

=====

    // Process events
    for (it=_sources.begin(); it != _sources.end(); )
    {
      SourceList::iterator thisIt = it++;
      XmlRpcSource* src = thisIt->getSource();
      int fd = src->getfd();
      unsigned newMask = (unsigned) -1;
      if (fd <= maxFd) {
        // If you select on multiple event types this could be ambiguous
        if (FD_ISSET(fd, &inFd))
          newMask &= src->handleEvent(ReadableEvent);
        if (FD_ISSET(fd, &outFd))
          newMask &= src->handleEvent(WritableEvent);
        if (FD_ISSET(fd, &excFd))
          newMask &= src->handleEvent(Exception);

        if ( ! newMask) {
          _sources.erase(thisIt);  // Stop monitoring this one
          if ( ! src->getKeepOpen())
            src->close();
        } else if (newMask != (unsigned) -1) {
          thisIt->getMask() = newMask;
        }
      }
    }

=====

The problem is that sometimes in the event handlers
(src->handleEvent()...) the addSource() and removeSource() methods of
XmlRpcDispatch are called directly and hence the _sources member is
changed. In some cases, this invalidates the iterator thisIt, causing
undefined behaviour (and an assertion failure in debug mode as soon as
thisIt->getMask() is called). I've fixed this bug similarly to the way
the clear() method is realized: in addSource and removeSource I check if
_inWork is true, and if so I won't modify _sources immediately but
rather use two other lists (_addedSources and _removedSources) which are
processed later in work(). This fixes the problem for me. I've also
updated the sources in the ROSWIN32 repository (so anyone who updates
his working copy should rebuild ROS). Now i'd like to know if this could
cause new problems because the _sources list isn't altered immediately.
Can anyone give me a hint?

I also see that all this doesn't seem to be a problem on Linux with
current g++ compilers. But I'm really wondering if some time it could
become one, e.g. if the STL implementation is altered. Does anyone know
a little more about that? Perhaps the problem didn't occur with older
Visual C++ releases (6.0 or .NET 2002) either...

Regards
Christoph Ciesla

-- 
___________________________________________
REC GmbH
Christoph Ciesla
Dipl.-Inf. Univ.

Robert-Koch-Str. 2, 82152 Planegg

Tel:   +49 (0)89 85902119
Fax:   +49 (0)89 85902327
Mobil: +49 (0)174 7746034
E-Mail: ciesla@servicerobotics.eu

Geschäftsführer: Dr. Christian Verbeek
Registergericht: AG München (HRB 154463)
___________________________________________