Experimental Physics and
Industrial Control System

"Mark Rivers" <[email protected]> · Tue, 13 Sep 2011 12:26:59 -0500

Hi Till,

I must admit that I'm not surprised that asynPortDriver is probably not
(yet) robust against failures in the constructor.  This Model 3 asyn
motor driver class is quite new.

You are saying that it is crashing in the epicsMutexLock here?:

void asynPortDriver::callbackTask()
{
    int addr;

    while(!interruptAccept) epicsThreadSleep(0.1);
    epicsMutexLock(this->mutexId);
    for (addr=0; addr<this->maxAddr; addr++) {
        callParamCallbacks(addr, addr);
    }
    epicsMutexUnlock(this->mutexId);
}

I'm not sure why that's crashing, since your constructor has
successfully called the base class constructor (asynMotorController,
which in turn calls the constructor for asynPortDriver) before you throw
the exception, right?  The base class constructor is what creates the
muxtex, so it should exist.

If your constructor throws an exception, does that automatically result
in a call to the destructor for the base classes?  I would not have
thought so, but I'm not enough of a C++ expert to know the answer to
that.

Mark

-----Original Message-----
From: Till Straumann [mailto:[email protected]] 
Sent: Tuesday, September 13, 2011 11:40 AM
To: EPICS Techtalk; Mark Rivers
Subject: asynMotorController exception safety

I wrote a driver class derived from asynMotorController
(which BTW was easy, thanks for the great package).

I would like the driver to be robust in case e.g., of the
absence of e.g., hardware or a serial communication channel.

Hence, my class does something like:

class MyDrv : public asynMotorController {
public:
     MyDrv() : asynMotorController(<parameters go here>)
     {
         status = detect_hardware(<parameters>);
         if ( status ) {
             throw MyException("HW detection failed\n");
         }
     }
};

In my main application I create a driver object

try {
    new MyDrv();
} catch (MyException &e) {
    printf("Unable to create driver: %s\n", e.what());
}

However, if hardware detection fails and the exception
is thrown and subsequently caught then the IOC application
will eventually (later) segfault in asynPortDriver::callbackTask()
(when trying to lock the mutex). It seems that the work
of the superclass constructor(s)
(asynMotorController/asynPortDriver/...) is
not properly undone.

No segfault happens if I comment the entire try block
(including the 'new' statement), i.e., if I create no
driver at all (but still load the .db file etc.).

How am I supposed to handle failure in the constructor?

Thanks
-- Till

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System