tango-controls / cpptango Goto Github PK

Hola a todos,

A bug has been found in the Tango::Except::re_throw_exception()
method when:
1 - The original exception is a CORBA System exception.
2 - It is used in a multi-threaded environment

This bug is the reason of:

• Several Starter crashes
• The problem reported by Vincenzo in http://www.esrf.fr/mail\_archives/tango/archive/msg01828.html

Obviously, the bug fix will be part of Tango 6.1 but it is already in the CVS

Hasta luego

Emmanuel Taurel

Reported by: taurel

Original Ticket: "tango-cs/bugs/158":https://sourceforge.net/p/tango-cs/bugs/158

Executing the command 'Init" on a device with memorized
attributes does not update the attributes with the
memorized values. The device takes the default values
put in init_device. A "set_memorized_values" should be
done.

Reported by: gwen-soleil

Original Ticket: "tango-cs/bugs/69":https://sourceforge.net/p/tango-cs/bugs/69

Supose I register two service instances for the same service:
string service = "Sardana";
string inst1 = "XAS";
string inst2 = "NCD";
string d1 = "my/first/device";
string d2 = "my/second/device";
db.register_service(service, inst1, d1);
db.register_service(service, inst2, d2);

Later in time I would like to know the service providers for all "Sardana" service:
I can do:
DbDatum result = db.get_services(service,"*")
vector<string> providers;
result >> providers;

As a result I get a list of devices that provide the service but I do not know which device provides the service for which instance.

I propose adding another method to extract service instances:
DbDatum get_service_instances(string &servicename);

(up to here it would be the minimum)

and to avoid multiple calls to the database, another get_services:
DbData get_services(string &service, vector<string> &serviceinstances );

In fact, ideally I think the get_propety API should be replicated by having:
DbData get_services(string &servicename, string &serviceinstance);
void get_services(string &servicename, DbData &inst);
DbData get_service_instances(string &servicename);

but this would break compatibility with older versions (although I think nobody is using the "Service" feature yet)

Reported by: tiagocoutinho

Original Ticket: "tango-cs/bugs/178":https://sourceforge.net/p/tango-cs/bugs/178

In Tango V4, for a Scalar short attribute, you normally
code something
which looks like this in the init_device() method :

short start = 12;

Tango::MultiAttribute *m_attr = get_device_attr();
WAttribute &w_att =
m_attr->get_w_attr_by_name("My_Attribute");
w_att.set_write_value(start);

to set the attribute write part. This will not set the
attribute write value any more.

Reported by: taurel

Original Ticket: "tango-cs/bugs/53":https://sourceforge.net/p/tango-cs/bugs/53

Hi,

A reading of the history of an attribute that has only
INVALID quality value result in a SIGSEV in the server.

[1] Tango::PollRing::get_attr_history(0x291fb0,
0x6,0x2860a0, 0x5, 0xff123548, 0x5), at 0xff1a80d4

The issue is triggered when a java client calls
DeviceProxy.attribute_history() on this server.

Reported by: jlpons

Original Ticket: "tango-cs/bugs/47":https://sourceforge.net/p/tango-cs/bugs/47

When Devices names are mixing uppercases and lower
cases, the operation of adding and/or removing devices
from the logged devices is unsuccessfull.
A message indicates an error in the history window

Reported by: buteau

Original Ticket: "tango-cs/bugs/3":https://sourceforge.net/p/tango-cs/bugs/3

Hola a todos

There is a threading issue in Tango 6.1 (and before) for C++ and Python when
a multi-threaded client creates DeviceProxy instances
in its threads "at the same time" if no DeviceProxy instance has been created before starting the threads. The process crashes!
This problem will be fixed in next Tango release

Workaround: Create a DeviceProxy instance (on any device)
before starting your threads.

Cheers

Emmanuel Taurel

Reported by: taurel

Original Ticket: "tango-cs/bugs/164":https://sourceforge.net/p/tango-cs/bugs/164

When using Tango V5 but without modifying device code
(device still inheriting from Device_2Impl), the
attribute last written
value is not returned when the attribute is read
(for READ_WRITE attribute). Instead, 0 is always returned.
Will be fixed in Tango 5.1

Workaround: Modify your device code to inherit from
Device_3Impl (using Pogo)

Reported by: taurel

Original Ticket: "tango-cs/bugs/55":https://sourceforge.net/p/tango-cs/bugs/55

It should be possible to define devices aliases to avoid
very long names especially for beamline control:

exemple:
&quot;phi&quot; means &quot;lucia/monochromateur/galilaxis1&quot;

As far as I know this implies at least

- The Tango DB

• Jive to enter the aliases (version 2.1 seems to do that )
• DeviceTree wich now defines its own aliases

Reported by: buteau

Original Ticket: "tango-cs/bugs/15":https://sourceforge.net/p/tango-cs/bugs/15

Hola a todos,

Polling does not re-start after a Init command executed on a DS admin device.

Will be fixed in next release

Emmnanuel Taurel ([email protected])

Reported by: taurel

Original Ticket: "tango-cs/bugs/99":https://sourceforge.net/p/tango-cs/bugs/99

1. lib/cpp/server/dserverclass.cpp, tango cvs, line 1691:

if (db != NULL)

must be:

if (db != NULL && Util::_FileDb==false) /* patch for db on file */

2. lib/cpp/server/eventsupplier.cpp tango cvs, line 426:

if (Util::_FileDb == false)

must be:

if ((Util::_FileDb == false) && (tg->is_svr_starting() == true))

3. lib/cpp/server/utils.cpp, tango cvs, line 983:

_FileDb = true;

must be:

Tango::Util::_FileDb = true;

4. lib/cpp/server/utils.cpp, tango cvs, line 1325:

db->set_timeout_millis(DB_TIMEOUT);

must be added the check:

if(_FileDb==false) /* must check this first */
db->set_timeout_millis(DB_TIMEOUT);

Reported by: jacum

Original Ticket: "tango-cs/bugs/211":https://sourceforge.net/p/tango-cs/bugs/211

It would be great to have at the device level configuration parameters the same way we have at the attribute level. Also having the corresponding DEV_CONF_EVENT events.

The most interesting parameter for me would be the 'label'. This way we can show in a client application a "nicer" string. The 'alias' feature is useful but is not enough since many times you want to display the same label for different devices.

Other useful configuration parameter would be the 'description'. I know we already have it as a device property (but it doesn't have events, although changing a description of a device should not be a frequent thing)

Reported by: tiagocoutinho

Original Ticket: "tango-cs/feature-requests/4":https://sourceforge.net/p/tango-cs/feature-requests/4

Hola a todos,

There is a bug in the Util::get_device_list_by_class() method if:

- you call your DS admin device init command

• you have a multi-classes device server
• you call the Util::get_device_list_by_class() method in your device's delete_device() method referencing a class already destroyed

The result is a nice "core dumped" instead of throwing an exception

Will be fixed in the next release

Cheers

Emmanuel Taurel

Reported by: taurel

Original Ticket: "tango-cs/bugs/112":https://sourceforge.net/p/tango-cs/bugs/112

A C++ client crashes if you create an empty
DeviceAttribute object and then you insert data using a
C++ vector. This kind of code

DeviceAttribute da;
da.set_name("AnAttribute");

vector<long> vl;
vl.push_back(1111);
vl.push_back(2222);

da << vl;

It is annoying because this feature is used by PyTango
to write Spectrum or Image attribute.
There are a couple of e-mails (Feb/March 2006) in the
Tango mailing list related to this issue.

It is solved and commited in the CVS.
Will be part of 5.5.1 or 5.6

Manu

Reported by: taurel

Original Ticket: "tango-cs/bugs/90":https://sourceforge.net/p/tango-cs/bugs/90

A test bug to check mailing list system

Reported by: taurel

Original Ticket: "tango-cs/bugs/45":https://sourceforge.net/p/tango-cs/bugs/45

delete_device and ~Device_Impl should be virtual in the same manner init_device is.

Reported by: lkrause2

Original Ticket: "tango-cs/bugs/185":https://sourceforge.net/p/tango-cs/bugs/185

Hello all,

It seems that in C++, the adm_name in the DeviceProxy object is not correct in the case the DeviceProxy refers to a device that is not on the current database (defined by the TANGO_HOST env variable).

Example:
I have my TANGO_HOST=BL01:10000
I want to access a device that is managed by a database in another machine: MACHINE:10000

executing the following code:

DeviceProxy d("tango://MACHINE:10000/my/own/device");
try
{
// polling_status needs to access the adm_device
cout << d.polling_status() << endl;
}
catch(DevFailed &e)
{
Except::print_exception(e);
}

will throw the exception:

The device proxy methods that access the database
Tango exception
Severity = ERROR
Error reason = DB_DeviceNotDefined
Desc : device my/own/device not defined in the database !
Origin : DataBase::ImportDevice()

Tango exception
Severity = ERROR
Error reason = API_CommandFailed
Desc : Failed to execute command_inout on device Db device, command DbImportDevice
Origin : Connection::command_inout()

Tango exception
Severity = ERROR
Error reason = API_DeviceNotDefined
Desc : Can't connect to device dserver/Test/t01
Origin : DeviceProxy::DeviceProxy

because it looks for the adm_device in BL01 instead of MACHINE.

I propose that in devapi_base.cpp, the DeviceProxy::adm_name() method takes into account the host:port of the device name.

Cheers
Tiago

Reported by: tiagocoutinho

Original Ticket: "tango-cs/bugs/192":https://sourceforge.net/p/tango-cs/bugs/192

Tango 5.4 :
When the state machine doesn't allow to write on a
write only attribut, its value changes all the same.

Reported by: vince_soleil

Original Ticket: "tango-cs/bugs/86":https://sourceforge.net/p/tango-cs/bugs/86

Hola a todos,

The value applied to a memorized attribute after a device Init command is not the attribute last written value but the attribute value when the device was created.

Fixed in next release

Reported by: taurel

Original Ticket: "tango-cs/bugs/187":https://sourceforge.net/p/tango-cs/bugs/187

trigger_attr_polling(bla, name) expects a reference to string (string &) as parameter. This really should be "string const & attr_name" because trigger_attr_polling does not modify this data and literal strings such as "_EG_FVS" could be handed without creating a string just to have a valid reference.

Compare
string s_EG_FVS("_EG_FVS");
util.trigger_attr_polling( this, string("_EG_FVS") );

with

util.trigger_attr_polling( this, "_EG_FVS");

Reported by: lkrause2

Original Ticket: "tango-cs/bugs/191":https://sourceforge.net/p/tango-cs/bugs/191

I am starting to use the services feature in Tango.

the Database.get_services(<service name>, <service instance>) method accepts a wildcard in the second parameter. However the result is a list of devices. With this information I cannot associate a device that implements the service with the service instance.

I believe nobody is using this feature yet. Having this into account I propose this method returns a list of strings in which the elements are alternatively <service instance> and <device name>
(this is similar what db.get_device_class_list does for classes and devices)

This way if a device is deleted without unregistering the service it is providing, it is still possible to later do a cleanup of the existing services.

Cheers

Reported by: tiagocoutinho

Original Ticket: "tango-cs/bugs/219":https://sourceforge.net/p/tango-cs/bugs/219

Hola a todos,

There is a bug in case of device server started without
database or setting the Util::_UseDb static data member to false. This bug may be the reason of device server process crashes during its startup sequence

A fix is available in the server/utils.cpp file release 3.40.2.1 (in a branch called Release_6_1_1-bugfixes)

Cheers

Emmanuel Taurel

Reported by: taurel

Original Ticket: "tango-cs/bugs/163":https://sourceforge.net/p/tango-cs/bugs/163

I would like to be able to define by code (and not to let
TANGO do it by itself) the following fields of an attribute :

• the timestamp
• the quality

The first need is because there are some attributes that
may be acquired on another control system (the LINAC
control system in our case) and the value is transfered
from this other CS with its timestamp

I guess the &quot;Attribute as Object&quot; development topic will
be the solution

This demand is NOT urgent (LINAC will be installed only
in 2004)

Reported by: buteau

Original Ticket: "tango-cs/bugs/19":https://sourceforge.net/p/tango-cs/bugs/19

Tango::RUNNING state is affected by the following compilation error:

error: expected unqualified-id before numeric constant

The other Tango states are ok.

Reported by: jacum

Original Ticket: "tango-cs/bugs/220":https://sourceforge.net/p/tango-cs/bugs/220

The DeviceAttribute has_failed() method generates a
"seg fault" if it is used on a DeviceAttribute object
which has
never reported any error.

Will be fixed in Tango 5.2

A bug fix is available if needed. Just ask

Reported by: taurel

Original Ticket: "tango-cs/bugs/62":https://sourceforge.net/p/tango-cs/bugs/62

the get_host_info() method of the data base object returns DbServerInfo with the host field being " ".

Reported by: lkrause2

Original Ticket: "tango-cs/bugs/189":https://sourceforge.net/p/tango-cs/bugs/189

In case of database server release 2.3 (or above), bug
in the
Database::get_device_attribute_property() and in
Database::get_class_attribute_property() : The size of
the returned DbData object (it's a vector) is not correct.

This generates instabilities (could even be core
dumped) when a process linked with V5 requests
attribute configuration to a device still implementing
Device_2Impl (not passed through Pogo) or create an
AttributeProxy object for an attribute belonging to a
Device_2Impl device.
Will be fixed in Tango 5.1

Workaround : Update device code to inherit from
Device_3Impl (using Pogo)

Reported by: taurel

Original Ticket: "tango-cs/bugs/56":https://sourceforge.net/p/tango-cs/bugs/56

Hola a todos,

There is a bug in case you remove a dynamic attribute
and delete the memory allocated for the corresponding
"Attr" instance in the init_device() of a class with a single device.

Fixed in device.cpp file release 3.39.2.1 in the
Release_6_1_1-bugfixes branch

Thank's to Julien from Soleil for reporting and fixing

Regards

Emmanuel Taurel

Reported by: taurel

Original Ticket: "tango-cs/bugs/194":https://sourceforge.net/p/tango-cs/bugs/194

There is a bug in Tango 5.5 when removing attribute
dynamically created. It is a bad mangement of internal
indexes which is the reason of "Core dump" or
"Seg fault" when reading attributes after a dynamic one
has been deleted

Will be fixed in next release

Cheers

Manu

Reported by: taurel

Original Ticket: "tango-cs/bugs/93":https://sourceforge.net/p/tango-cs/bugs/93

Hola,

Actually, it is not possible to use the Tango::Util::fill_attr_polling_buffer() method for attribute which are READ-WRITE.

This will be changed in next release

Cheers

Emmanuel Taurel ([email protected])

Reported by: taurel

Original Ticket: "tango-cs/bugs/96":https://sourceforge.net/p/tango-cs/bugs/96

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.

Reported by: ollupac

Original Ticket: "tango-cs/bugs/182":https://sourceforge.net/p/tango-cs/bugs/182

There is a memory leak in Tango V5.3 (and 5.4 I presume).

This leak happens when you try to set an attribute
value asking Tango to free the memory for you. If give
a wrong pointer type or if the data size if greater
than the maximum defined, you will receive an exception
but memory will not be freed.

Normally, this case should happened very rarely.

Will be fixed in next release

Bye

Emmanuel Taurel

Reported by: taurel

Original Ticket: "tango-cs/bugs/76":https://sourceforge.net/p/tango-cs/bugs/76

TANGO DS exit with useless exit code making it impossible to know wether starting a DS succeeded or why not.

see http://www.linuxtopia.org/online\_books/advanced\_bash\_scripting\_guide/exitcodes.html
and /usr/include/sysexits.h

Reported by: lkrause2

Original Ticket: "tango-cs/bugs/221":https://sourceforge.net/p/tango-cs/bugs/221

The attribute lable default property is always written in
database during a set_attribute_config() call even if
it is the
library default value

Will be fixed in Tango 5.1

Workaround : None

Reported by: taurel

Original Ticket: "tango-cs/bugs/57":https://sourceforge.net/p/tango-cs/bugs/57

Within POGO , we declare an attribute as :

• "Memorized AND Write Hardware at INIT "

The behaviour is the following :

Case 1: Memorized value is in fact well applied during a DeviceServers launch from ASTOR

Case 2 : But, when once started, the Init command does not apply this values on the hardware

We are happy with case 1, but we think in Case 2 , memorized values should be written on hardware

Reported by: buteau

Original Ticket: "tango-cs/bugs/140":https://sourceforge.net/p/tango-cs/bugs/140

There is a memory leak in the C++ API in case you call
the DeviceProxy::get_attribute_config() or
DeviceProxy::get_attribute_config_ex() methods for a
non existent attribute.
It leaks 12 bytes...

It is solved and will be part of the bugs fixed in
Tango 5.5

Manu

Reported by: taurel

Original Ticket: "tango-cs/bugs/83":https://sourceforge.net/p/tango-cs/bugs/83

Hola,

Some "Core dump" or "Seg Fault" or other "funny things" like this may happens if you have a DS with a long shutting down sequence and clients listenning on event when you kill the DS.
This is due to the event heartbeat system between DS and clients

Will be fixed in next release

Cheers

Emmanuel Taurel ([email protected])

Reported by: taurel

Original Ticket: "tango-cs/bugs/97":https://sourceforge.net/p/tango-cs/bugs/97

it is not possible to write

dev.get_attribute_config("attr_name");

we need to write

std::string attr_name("attr_name");
dev.get_attribute_config(attr_name);

So it seems that get_attribute_config do not accept const char or const string.

Is it possible to solve this problem

thanks

Frederic

Reported by: piccaf

Original Ticket: "tango-cs/bugs/217":https://sourceforge.net/p/tango-cs/bugs/217

Hi all,

A double memory free could happen (therefore sometimes a core dump) if you request a command to be executed by a device using the command_inout_asynch() call while the server hosting the device is down, then before you get the command answer with command_inout_reply(), the server is re-started but the command failed for one reason or another

Will be fixed in next release

Emmanuel Taurel

Reported by: taurel

Original Ticket: "tango-cs/bugs/193":https://sourceforge.net/p/tango-cs/bugs/193

When starting a device server without the database
(option -nodb) and specifying the device list (-dlist)
the device names are not converted to small letters.
However the client api does convert to small letters.
This means clients cannot connect to devices in servers
running with -nodb and having capital letters in their
names e.g. X06SA/MicroDiff/General.

The work around today is to use only small letters when
specifying the device names in -dlist when starting the
server. The client can then connect to the server using
any mix of small and capital letters.

Reported by: andygotz

Original Ticket: "tango-cs/bugs/32":https://sourceforge.net/p/tango-cs/bugs/32

A device server serving device(s) inheriting from
Device_3Impl (the Tango V5 IDL) crashes when client
linked with Tango V4 requested one device attribute
history.

Workaround: None except re-linked the client with Tango V5

Will be fixed in Tango V5.1

Reported by: taurel

Original Ticket: "tango-cs/bugs/58":https://sourceforge.net/p/tango-cs/bugs/58

Hola a todos,

It is not possible for a non omni-thread thread
(a python thread for instance) to subscribe to an event.

This will be solved in the next release.

If this problem is a blocking one for you, update your local copy of the C++ api "server/readers_writers_lock.h" file and re-generate Tango

Cheers

Tiago, Jens and Emmanuel

Reported by: taurel

Original Ticket: "tango-cs/bugs/156":https://sourceforge.net/p/tango-cs/bugs/156

Hola a todos,

There are two memory leaks in the dynamic attribute management. These leaks happen when:

1 - You add one dynamic attribute to a device of class A and this class already has this attribute
2- You add one attribute to a device which already has this attribute

Will be fixed in next release

Cheers

Emmanuel Taurel ([email protected])

Reported by: taurel

Original Ticket: "tango-cs/bugs/95":https://sourceforge.net/p/tango-cs/bugs/95

Hola a todos,

There is a memory leak in the method DeviceProxy::read_attributes() when it throws an exception.

Will be fixed in next Tango release

Cheers

Emmanuel Taurel

Reported by: taurel

Original Ticket: "tango-cs/bugs/170":https://sourceforge.net/p/tango-cs/bugs/170

Hola a todos

I am using Jive 3.8 with TangORB 4.9.2 and ATK 2.5.1
I think there is a bug in the Test Device panel if it
has been opened using a device alias name and if you
are requesting for the polling status on the admin tab.
You get an error telling you that the device name
<alias name> is unknown.

Cheers

Emmanuel Taurel ([email protected])

Reported by: taurel

Original Ticket: "tango-cs/bugs/94":https://sourceforge.net/p/tango-cs/bugs/94

It would be great to be able to define aliases on
Attributes .

Exemple:

- Imagine an I/O board with theses 3 attributs :
out_channel1, in_channel1, in_channel2

then defining the following attributes :

in1 = &quot;lucia/acquisition/in_channel1&quot;
in2 = &quot;lucia/acquisition/in_channel2&quot;
out = &quot;lucia/acquisition/out_channel1&quot;

It would be possible to write this kind of script (thanks to
python magic for instance)

out= in1+in2

Reported by: buteau

Original Ticket: "tango-cs/bugs/16":https://sourceforge.net/p/tango-cs/bugs/16

In C++ API the get_logging_target and the add_logging_target methods are not coherent.

the add_logging_target method takes 2 input parameters (e.g. file and /tmp/log_data)
and get_logging_target method returns one string (e.g. file::/tmp/log_data)

Reported by: Pascal-Verdier

Original Ticket: "tango-cs/bugs/9":https://sourceforge.net/p/tango-cs/bugs/9

Hola a todos,

There is one case where the transparency re-connection between client and server will not take place. The re-connection is done at the second call instead of the first one.
Will be fix in next release

This case is when the re-connection takes place between a client and a server badly killed (kill -9, crash...) while the client is still connected to the server (before omniORB closes the connection due to inactivity)

Cheers

Emmmanuel Taurel ([email protected])

Reported by: taurel

Original Ticket: "tango-cs/bugs/136":https://sourceforge.net/p/tango-cs/bugs/136

Executing the command 'Init" on a device with memorized
attributes does not update the attributes with the
memorized values. The device takes the default values
put in init_device. A "set_memorized_values" should be
done.

Reported by: gwen-soleil

Original Ticket: "tango-cs/bugs/68":https://sourceforge.net/p/tango-cs/bugs/68

When a device server is destroyed, the order of object
destruction is wrong. The class object is destroyed
first then the devices. It should be the reverse order:
First the devices and then the class object.

Will be fixed in Tango V5.5

Reported by: taurel

Original Ticket: "tango-cs/bugs/78":https://sourceforge.net/p/tango-cs/bugs/78