ErrorLogger Package -- Problem Tracking ================================================================== ErrorLogger 015: Improper Time Zone Output Initial Report 10/29/03 ------------------ Version 2.2 CDF (E. Wicklund) reports that the time zone output is wrong, saying CST when it means CDT. THe time reported is correct, but the zone is misleading. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Technical Points ----------------- This is due to supplying the number of characters in a string (rather than the number plus one for the trailing zero) to strftime. Since it can't fit the last field (%Z, the timezone) it leaves the entire field unchanged -- and the template string was CST. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Repair Plans ----------------- Done immediately - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Status of repair ---------------- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Problem Rectified 4/9/04 ----------------- Will cut a release with this and the exit option ASAP. ================================================================== ErrorLogger 014: Crash in ELextendedID.clear() Initial Report 10/29/03 ------------------ Version 2.2 Martin Van Der Mey reports: There is a CDF crash in ELextendedID.clear() at end-of-job in some rare jobs. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Technical Points ----------------- This is on KCC; has a repeatable catch (not very clean, but crashes in both opt and noopt versions. Apparently the allocator for string is going haywire. MF sees some chance that the ELunspecified is becoming corrupted at the end of the job. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Repair Plans ----------------- This needs serious investigation; it does not look like an easy one to trace down. The probablility that it is in ErrorLogger is not overwhelming, but given that I can't at all understand what is happening here, we have to try to find out. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Status of repair 10/19/03 ---------------- Initial tests using gdeb. MvdM will send mail describing how to get to that point on my own, and how to rebuild with different package. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Problem Rectified ----------------- ================================================================== ErrorLogger 013: tbins not building right Initial Report 1/9/03 ------------------ Version 2.1.10 The builds are failing on tbins on several platforms. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Technical Points ----------------- The Multithread stuff adds considerable complication to the builds! - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Repair Plans ----------------- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Status of repair 3/13/03 ---------------- Repaired; all tbins build and run nicely. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Problem Rectified 3/20/03 ----------------- (checked in; to be tagged) ================================================================== ErrorLogger 012: ELsender virtual destructor Initial Report 8/30/02 ------------------ Version 2.1.9 Rodolfo Pellizzoni and Jim Kowalkowski report that the ELsender abstract class has no virtual destructor. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Technical Points ----------------- Abstract classes typically should have virtual destructors. This is likely an oversight. We need to consider whether this is worth making an ELsender.cc file in order to have a non-inline destructor implementation. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Repair Plans ----------------- For the moment I will implement the destructor as inline, and not pure virtual, pending further discussion as to the need for a pure virtual destructor in this class in future. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Status of repair 8/30/02 ---------------- Implemented as described above. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Problem Rectified ----------------- Version 2.1.10 ================================================================== ErrorLogger 011: Pedantic and Wall warnings Initial Report 11/9/01 ------------------ Version 2.1.2 When SRT activated the -pendantic -Wall options on gcc, a large number of compiler warnings started to be emitted. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Technical Points ----------------- Most warnings have to do with comparisons of int to unsigned. In particular, the hexTrigger mechanism does this a lot for the case of unsigned types. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Repair Plans ----------------- I have to understand the best way to fix this, which involves thinking out what setHexTrigger really means in the case of a big number. For clases other than ErrorLog and ELtsErrorLog, fixes are straightforward. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Status of repair 10/22/01 ---------------- Walter Brown has rectified the problems other than in ErrorLog and ELtsErrorLog. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Problem Rectified 11/15/01 ----------------- Version 2.1.4 ================================================================== ErrorLogger 010: Defunct tests still in tbin Initial Report 10/18/01 ------------------ Version 2.1 M. Fischler whicle testing a new feature noted that some of the tbin files in the Tests area (e.g. ShortFrame) are outdated, and core dump if run. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Technical Points ----------------- There should be a check of each of these; malfunctioning tests should be rectified; if they are inidcating actual bugs in the code these must be repaired; and any tests which are no longer meaningful should be eliminated. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Repair Plans ----------------- Fix ASAP - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Status of repair 10/18/01 ---------------- The source of trouble has been traced to a bad C-string when one defaults the title of a statistics summary. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Problem Rectified 10/19/01 ----------------- Checked in. Fix released in V2.1.2. ================================================================== ErrorLogger 009: Lack of way to setTableLimit in ELdestControl Initial Report 10/16/01 ------------------ Version 2.1 G. Watts asked about placing a limit on the size of tables. Knowing that this was already supposedly supported, M. Fischler found setTableLimit as a protected method in ELdestination which should have had a forwarding method in ELDestDControl but does not. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Technical Points ----------------- Clearly the ability to limit the size of table also has not been tested! - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Repair Plans ----------------- This omission should be rectified. Adding this method will be safe wrt existing code, regargdless of whether the method behaves as intended or is useful. Problem Rectified 10/18/01 ----------------- Version 2.1.2 ======================================================================== ErrorLogger 008: Private copy ctor in ELdestination Initial Report 6/25/01 ------------------ Version 2.0.8 It was noticed by M. Fischler (in the course of repairing bug 005) that the current situation of how an ELoutput is copied -- which involves in-body explicit copying of base-class data members -- is flawed from the maintenance viewpoint. One consequence is that if ELdestination ever is modified to need new data members, the ELoutput ctor must be examined as well. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Technical Points ----------------- One could make the copy ctor of ELdestination proper and public, but this is more subtle than it looks. We have not really thought through the semantics of copying sinks like this. To fix this properly would require a few days of rethinking design issues. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Repair Plans ----------------- Since the current code works, and since changes in ELdestination should be few, it is not worth the days to fix the problem. We can live with this design flaw instead. ======================================================================== ErrorLogger 007: Extra space in << int output Initial Report 6/6/01 ------------------ Version 2.0.8 It was noticed by M. Fischler (in the course of implementing thread safe logging) that when an int is passed to the errlog as an item, two spaces are placed before it rather than 1. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Reproduced 6/6/01 -------------- This behavior has been shown in basicUsage.cc. It has been this way since the hex capabilities were added in v2.0.4 (3/16/01). - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Problem Rectified 6/7/01 ----------------- Fix is in v2.1. ======================================================================== ErrorLogger 006: ErrorLog (ErrorObj) won't ever abort Initial Report 6/6/01 ------------------ Version 2.0.8 It was noticed by M. Fischler (in the course of implementing thread safe logging) that in ErrorLog::operator()(ErrorObj&) the code for "shopping" to each sink and emiting its items is present but the remainder of code in the normal ELadministrator path, which tests the severity against discard threshold, is absent. Thus an error with severity level abort will still not cause an abort (even assuming the trigger is appropriate). Also, highest severity level bookkeeping is not done in that case; again it is done in the normal path. This does not apply to messages sent in the more common manner of streaming items to errlog rather than pre-forming an ErrorObj. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Reproduced -------------- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Repair Plans ------------ I will fix concurrent to fixing the same flaw in the ELtsErrorLog class. That should occur 6/7/01. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Problem Rectified 6/7/01 ----------------- Fixed in version 2.1 ======================================================================== ErrorLogger 005: Flaw in clone() for ELoutput Initial Report 5/29/01 ------------------ Version 2.0.6 It was reported by G. Watts that in ELoutput, when it does the clone, it uses ELoutput (original_el_output), which is fine, except that in that constructor, it does a ELdestination () -- which effectively means that if any ELdestination vars were set in the original ELoutput, they won't be copied over. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Reproduced -------------- Problem code noted by MF 6/8/01. However, there are a couple of tough spots in the fix. First off, I need to check the other classes derived from ELdestination as well (e.g. ELstatistics and ELcollected). More seriously, ELdestination does not at present have a copy constructor (because it was not meant to be used alone). I have to repair that flaw, giving it a protected (but proper) copy ctor. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Technical Points ----------------- The barring of copies of a raw ELdestination was done for a reason. I have no wish to risk over-ruling that decision without fully comprehending the design thought that went into it, and no real wish to reconstruct that design reasoning. It is strongly suspected that when WEB eliminated the pimpl idiom last June, the reason for the non-copyable ELdestination went away, but I don't want to bet much on that. Instead of making the cpy ctor public, I will do explicit copies of the necessary data members in the body of the ELoutput copy ctor. This is, I believe, a bit safer -- if there is a problem, it can only bite the very rare user that explicitly clones ELoutputs. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Repair Plans ------------ Fix will be incorporated concurrent with the ThreadSafeErrorLog feature. Status of repair ---------------- Repaired 6/19 -- after an embarrassing first goof! - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Problem Rectified ----------------- Fixed in version 2.1. ======================================================================== ErrorLogger 004: Instantiation of operator<< for each lenght of string Initial Report 4/19/01 ------------------ Version 2.0.3 It was noted by R. Kennedy that if a program passes quoted strings on N different lengths to the ErrorLog, then because each is treated as const char[len], N different instantiations of the templated operator<< are produced. For example if (original_version != 1) { errlog.setSubroutine("ToyBasicJet::Streamer") ; errlog(ELwarning,"EDM-StreamerRVersion") << "Unknown class version " << original_version << " cannot be read." << endmsg ; } led to nm output of T ToyBasicJet::Streamer(TBuffer &) t ErrorLog &operator <<(ErrorLog &, const T1 &) [with T1=const char [26]] t ErrorLog &operator <<(ErrorLog &, const T1 &) [with T1=const char [23]] t ErrorLog &operator <<(ErrorLog &, const T1 &) [with T1=const char [20]] t ErrorLog &operator <<(ErrorLog &, const T1 &) [with T1=const char [17]] Not really a bug, but why gratuitously increase the footprint? - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Reproduced 5/7/01 -------------- By enhancing the error_log_EMIT_TRACE code to also output sizeof(t), M. Fischler has been able to verify that this behavior is happening. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Repair Plans ------------ This can be fixed by providing operator<< (ErrorLogger &, const char[]). A similar fix should also be done for streaming to ErrorObj, though that is a much less popular mode of use. Status of repair ---------------- Repair started 5/7/01; a bug-fix release will be made when ready. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Problem Rectified 5/7/01 ----------------- Will be released as version 2.0.7 ======================================================================== ErrorLogger 003: Superior workaround available for no static init Initial Report 3/23/01 ------------------ Version 2.0.3 Around line 150 of ELdestination.h the following workaround appears: #ifndef DEFECT_NO_STATIC_CONST_INIT static const int defaultLineLength = 80; #else static const int defaultLineLength; #endif and in the .cc file, there is #ifdef DEFECT_NO_STATIC_CONST_INIT const int ELdestination::defaultLineLength = 80; #endif Walt Brown points out that the ISOcxx package provides a superior workaround: In the .h file, place MEMBER_CONST (int, defaultLineLength, 80); and remove the fix in the .cc file. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Reproduced 4/25/01 -------------- Problem re-understood by M. Fischler. One caveat: IF ErrorLogger currently can compile without USE_ISOCXX, then this improvement will destroy that capability. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Repair Plans ------------ Since there is potential for harming non-usual compiles that have been working, and since the improvement is only on the maintenance level, it is decided to forgo the improvement. As of 4/25/01 no plans to make this improvement. ======================================================================== ErrorLogger 002: ErrorLog(pkgname) ignores name Initial Report 3/14/01 ------------------ Version 2.0.3 The form of ErrorLog constructor taking a pkgname string does not initialize its private data. The consequence is that the module name comes out blank if this constructor form is used and nobody does setModule(). - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Reproduced 2/12/01 -------------- Problem was noticed by M. Fischler while investigating why discardThreshold (being implemented) completely blew away all error messages in R. Kennedy's code. (The same initialization lack was impacting the new feature a lot more severely!) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Repair Plans ------------ WB has added code to do the initializations. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Problem Rectified 3/14/01 ----------------- version 2.04 The above repair was made, and is in the 2.0.4 release. ======================================================================== ErrorLogger 001: Static init foils NT Initial Report 2/12/01 ------------------ Version 2.0 VC++ does not accept initializing a static const int. In ELdestination.h there is a line static const int ELdestination::defaultLineLength = 80; which is reported as an error in VC++ 6.0. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Reproduced 2/12/01 -------------- Problem was found by P. Canal while porting stuff to D0 environment. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Repair Plans ------------ There is already a defined DEFECT_NO_STATIC_CONST_INIT workaround. We will enclose the offending line in that ifndef, and substitute a line which just declares the variable. Then in ELdestination.cc we will insert (with same ifdef) static const int ELdestination::defaultLineLength = 80; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Problem Rectified 2/13/01 ----------------- version 2.02 The above repair was made, and when 2.0.2 was released it was checked in . ================================================================== Template for each bug: ================================================================== BugNumber: BugName Initial Bug Report ------------------ Version x.y * * * - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Bug Reproduced -------------- circumstances * * - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Repair Plans ------------ * * (or technical problems) * - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Status of repair ---------------- * * * - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Status of repair ---------------- * * (in long-running problems might need more than one) * - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Problem Rectified ----------------- version x.z - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Ongoing Caveats --------------- * * * ==================================================================