#182 Firing change events on attributes whith INVALID quality
I have a device server that fires Change events for some attributes. In a certain moment, the attribute quality can become INVALID. When, after sending valid change events I send a change event which invalid quality, sometimes the program crashes. The problem seems that Tango is trying to delete Attribute::value.db_seq. It comes from the call to "delete_seq();" around atribute.cpp:5960 in Tango 6.1b ( probably line 6439 in CVS attribute.cpp revision 3.58).
Just commenting this line the problem disappears, but valgrind will say that there are "definitely lost" leaks. My solution is to change:
delete send_attr;
// delete the data values allocated in the attribute
if ( name_lower != "state" )
{
bool data_flag = get_value_flag();
if ( data_flag == true )
{
delete_seq();
set_value_flag (false);
}
by:
bool quality_invalid = (send_attr->quality == Tango::ATTR_INVALID);
delete send_attr;
// delete the data values allocated in the attribute
if ( name_lower != "state" )
{
bool data_flag = get_value_flag();
if ( data_flag == true )
{
if ( !quality_invalid ) {
delete_seq();
set_value_flag (false);
}
}
}
It seems to work properly and without extra memory leaks. Probably the catch(...) under these lines needs something similar.
Hope this helps and it gets properly solved.
Logged In: YES
user_id=569547
Originator: NO
Hola,
Thank's for the report and the bug fix.
Before inserting it into th elib, I have a question:
How do you fire the event? Do you use the DeviceImpl::push_change_event() method
or do you use a Attribute::set_value_date_quality() method followed by a Attribute::fire_change_event()
or any other way ?
Thank's for your answer
Emmanuel Taurel
Logged In: YES
user_id=496442
Originator: YES
Bonjour!
I am firing it this way:
Tango::AutoTangoMonitor synch(this);
Tango::WAttribute& a = this->get_device_attr()->get_w_attr_by_name(attrName);
if(valid) {
a.set_value_date_quality(data,lastAcqTime, Tango::ATTR_VALID);
} else {
a.set_quality(Tango::ATTR_INVALID);
a.set_date(lastAcqTime);
}
a.fire_change_event();
Logged In: YES
user_id=569547
Originator: NO
Hola,
I am not able to re-produce your problem in a small test device server using code similar to yours.
If the attribute quality is set to INVALID, you are not calling the Attribute::set_value() or Attribute::set_value_date_quality() methods. Therefore the flag tested in Tango lib to delete or not the sequence created internally should not be true and the Tango lib should not try to delete the memory.
I have run my little test device server with Valgrind and did not notice special complains from Valgrind about memory usage.
What do you think ?
Cheers
Emmanuel Taurel
Logged In: YES
user_id=496442
Originator: YES
Hello,
I am not sure where the problem comes from anymore :P
I have prepared a little test DS that looks similar to mine, and I it's been really hard to reproduce the error. But, finally I did it!
Maybe you can find there that I am doing something obviously wrong.
I isolated the crash: It happens in Tango 6.1b when I have an ATK panel open connected to the device.
The test device has a thread sending change events for an attribute. It can be start/stop. If the thread is stopped, then it will send a last event setting the quality as INVALID.
Even though the attribute has change events and ATK panel recognises this is in the "Diagnostic" form, it still polls the attribute (both gets real change events and the software polling, don't know if it is normal or another bug in ATK ).
The problem seems to happen when after an attribute has been read with a Valid value I try to fire an Invalid one (by "stop"ing the device). Example output:
Hola?
MONITOR BEGIN
MONITOR END
Reading Valid
Reading Valid
Reading Valid
joined
MONITOR BEGIN
firing invalid
Violació de segment
Where "Reading Valid" is written when reading the attribute and "MONITOR BEGIN/END" when firing change attributes. If the last "Reading" was time ago ("Stop refreshing" in ATKPanel before really stopping it)...
Reading Valid
MONITOR BEGIN
MONITOR END
MONITOR BEGIN
MONITOR END
MONITOR BEGIN
MONITOR END
joined
MONITOR BEGIN
firing invalid
MONITOR END
Then the thread stops without problems.
Sorry for this extremely long delay...
I have written a small test case to reproduce this problem.
I have a server with one Scalar DevLong attribute
I have a client which polls this device attribute as fast as it can (Python client)
In the server, I have a thread which every second fire a change event on the same attribute but with a quality factor
set to INVALID. I have another client listening on the change event from this attribute
I do not notice any problem.
Is this case similar to yours ?
Do you still confirm the "seg fault" on your side?
Emmanuel Taurel