Free High Performance CORBA Notification Service from AT&T Laboratories |
omniORB Home AT&T Research |
This list is here for historical documentation. You should be using omniNotify 1.2 or later.
Bug Number: | 1 | Summary: | If -DNDEBUG is used, RDIRVM.cc did not compile. |
Date Reported: | Oct ??, 2001 | Reported by: | reg |
Date Fixed: | Oct 28, 2001 | Fixed by: | reg |
Description: | There was a section headed by
#ifndef NDEBUG where this was placed at the wrong point, causing a compilation error if -DNDEBUG is used as a compilation flag. (Use of this flag is not recommended unless obtaining a tiny bit more performance is important.) |
||
Bug Number: | 2 | Summary: | At server level, "cleanup all" did things in the wrong order -- the right order is now used. |
Date Reported: | Oct ??, 2001 | Reported by: | reg |
Date Fixed: | Oct 28, 2001 | Fixed by: | reg |
Description: | "cleanup all" is equivalent to "cleanup both" followed by "cleanup filters" (this is the right order to do things, because after cleanup both is used, some admins and proxies that were not needed have been removed, possibly enabling cleanup of some filters that were attached to these proxies or admins). | ||
Bug Number: | 3 | Summary: | 2 memory leaks |
Date Reported: | Oct 30, 2001 | Reported by: | Mark Zimmerman |
Date Fixed: | Nov 2, 2001 | Fixed by: | reg + mz |
Description: | A typo in RDIEvent.h caused a leak of an internal cached data item. A bug in object initialization in omniorb_poa_wrappers.h causes a leak of ObjectIds. | ||
Bug Number: | 4 | Summary: | CosEvent 2 connect cases allow nil |
Date Reported: | Nov 24, 2001 | Reported by: | Alexey Syomichev, Mike Ladwig |
Date Fixed: | Nov 28, 2001 | Fixed by: | reg |
Description: | For CosEvent (legacy) API, conncet_pull_consumer and connect_push_supplier are supposed to allow nil as the argument, but omniNotify was raising BAD_PARAM. This was due to following the error-checking that is required for the newer CosNotification connect calls. | ||
Bug Number: | 5 | Summary: | object references now released properly |
Date Reported: | Dec 14, 2001 | Reported by: | Janet Tvedt |
Date Fixed: | Feb 28, 2002 | Fixed by: | reg |
Description: | omniORB cleans up object references once their internal ref count goes to zero. The programmer must do the appropriate number of duplicates and releases, otherwise the references stay around, resulting in what is effectively a memory leak. LeakTracer was used to track down and fix a number of these cases. There do not seem to be any other memory leaks at this time. | ||
Bug Number: | 6 | Summary: | deadlock case fixed |
Date Reported: | Jan 22, 2002 | Reported by: | Janet Tvedt |
Date Fixed: | Feb 28, 2002 | Fixed by: | reg |
Description: | Event lock was not always acquired in the correct order relative to acquiring an operation lock, resulting in a deadlock scenario. | ||
For comments, feedback, etc, please see the 'Keep in touch' page. |