tier4.cl

check and update program

175777|TUX8.0%2FWS%3A LIBWSC_CAT%3A1512%3A ERROR%3A Unable to generate first diffie-hellman packet|ws|8.0|274|Leon Zhang|Maggie Li|NSP|279|closed|None|The CR reports that the customer is using 8.0 client connecting to 6.5 serer.%0D%0AHowever%2C when the customer is working on it%2C he is using 7.1 on the server%0D%0Aside. Since 6.5 and 7.1 talks different protocols%2C the fix patch was targeting%0D%0Awrong server. RP274 was rejected by Tier3 and RP279 solved the problem.|11%2F5%2F2004
187756|Tuxedo 6.5 %2FAIX 5.1 - FML%3Acustomer want to keep the evaluation behavior as before RP424%0D%0A|build script|6.5|460|Kelly Hu|Maggie Li|NSP|460 %28replace the old one%29|closed|188303%2F188458|When the first RP460 is delivered%2C the build was not finished successfully.%0D%0AHowever%2C both the build script and the engineer didn%27t noticed the failure. So%0D%0Athe patch was rejected by Tier3 with high priority.%0D%0A%0D%0AIn CR188303%2C Hunter managed to build a good RP. In CR188458%2C Kelly fixed the%0D%0Abug in build script so that it could catch such failure automatically.%0D%0A|11%2F5%2F2004
191809|TUX8.1%3A CR108355 need to be propagated to TUX8.1|core|8.1|123|Hunter Su|Maggie Li|NSP|125|closed|None|In CR191809%2C the customer wants patch on Tru64. Since this is a propagation%2C%0D%0Athe engineer just copy the code to 8.1 and released the patch. However%2C the%0D%0Aoriginal fix was platform dependent and didn%27t include Tru64. So RP123 didn%27t%0D%0Asolve customer%27s problem. This was discovered and rejected by Tier3 guys.%0D%0AHunter solved the problem in RP125 via the same CR.%0D%0A|11%2F5%2F2004
47998|Error code GP_CAT%3A1345|libgp|7.1|060|Gary Watson|Norris Meng|IB|8.1%2F118|open%28partly%29|187751|When working on CR187751%2C Norris found the following buggy code was introduced%0D%0Ain CR047998%3A%0D%0Agp%2Flibgp%2Fdynload.c%0D%0A    %2F* CR047998%3A if that failed%2C and%0D%0A     * real user %28or group%29 id %21%3D effective user %28or group%29 id *%2F%0D%0A    if%28 %21 %28*lh%29-%3Em_handle %26%26 %0D%0A        %28getuid%28%29 %21%3D geteuid%28%29 %7C%7C getgid%28%29 %21%3D getegid%28%29%29%29%0D%0A    %7B%0D%0A        %2F* try using the full path *%2F%0D%0A        char tuxdir%2Cfull_libpath%5B_POSIX_PATH_MAX%2B1%5D%3B%0D%0A%0D%0A        _e_fs_dirjoin%28_TCARG%2CJOIN_DIR%2C%26tuxdir%2Ctuxgetenv%28%22TUXDIR%22%29%2C%22lib%22%29%3B%0D%0A        _e_fs_dirjoin%28_TCARG%2CJOIN_FILE%2Cfull_libpath%2Ctuxdir%2C%28char *%29libpath%29%3B%0D%0A%0D%0A        %28*lh%29-%3Em_handle %3D dlopen%28full_libpath%2C RTLD_NOW%29%3B%0D%0A    %7D%0D%0A%0D%0ASince the purpose of variable %27tuxdir%27 is to hold the path%2C which is obviously%0D%0Alonger than one character%2C the above code is obviouly buggy. One thing I don%27t%0D%0Aunderstand is that how did the original fix passed the test.%0D%0A%0D%0ASince solution to CR047998 exists in 7.1%2F8.0%2F8.1 while Norris only fixed 8.1.%0D%0ARelease 7.1 and 8.0 is still open to this bug.%0D%0A|11%2F5%2F2004
122830|Jolt 8.0 %2F Jolt 1.2 - Euro symbols are not displayed correctly%0D%0A|Jolt client|8.0|239|Liang Luo|Steven Liu|IB|N%2FA %28A few bugs has been reported by customer and no whole fix|open%28partly%29|175138%2F185028%2F188117|CR122830 introduced %22double-encode%2Fdecode%22 algorithm to handle unicode string%0D%0Ainput correctly. But it does%27t check the buffer%27s boundary%2C so it introduced%0D%0ACR175138 and CR188117. CR175138 introduced an extra condition to check the%0D%0Acurrent decoded value to see if it belongs to wide character%2C but in some%0D%0Acases this check will treate non-wide character as wide character and it will%0D%0Adouble-decode this value wrongly. So CR175138 introduced CR185028.%0D%0A%0D%0AActually there are flaws in the basic idea of the double-encode%2Fdecode%0D%0Aalgorithm. See Shailesh%27s note in CR122830.%0D%0A|11%2F5%2F2004
69576|WLE51 - Compatibility Mode RP for Solaris 8.0 operating system%0D%0A|core%2Fcmdtux|WLE5.1|110|Liang Luo|Hunter Su|IB|WLE5.1%2F158|closed|189134|When working on CR189134%2C Hunter found the problem was introduced by fix to%0D%0ACR069576.%0D%0A%0D%0AIn file tuxedo%2Fcmdtux%2Funix%2Fsrvrcc.c%2C variable %27cc%27 and %27cflags%27 was originally%0D%0Adeclared as pointers to char and malloced dynamically. By fixing CR069576%2C%0D%0ALiang change them into arrays like following%3A%0D%0Astatic char cc%5B1024%5D %3D %22%22%3B%0D%0Astatic char cflags%5B1024%5D %3D %22%22%3B%0D%0AWe don%27t know the motivitation of the change but it%27s obvious that the fixer%0D%0Adidn%27t consider the situation that cflags environment variable could exceed%0D%0A1024 byte long. Hunter solved the problem by changing them back to pointers in%0D%0ACR189134.%0D%0A|11%2F12%2F2004
87819|TUX 8.0%3A Memory leak in a CORBA C%2B%2B DII client|corba%2Fdii|8.0|104|Jeff Michaud|Steven Liu|CB|N%2FA|open|92176%2F100854%2F188368|The RequestImpl is required to take ownership of the return values of results%0D%0Ain C%2B%2B Language Mapping spec%2C but before the fix for CR087819 it doesn%27t do it%0D%0Alike this%2C then this will lead memory leak. But because some regression%0D%0Atestcase%28oriDualClient--CR188368%2C m3diimem%2C oriDiiClient--CR092176%29 and%0D%0Asamples%28simpapp_mt%2C CR100854%29 uses the defect of DII%2C  these testcases will be%0D%0Abroken after the fix for CR087819. The fix for CR087819 doesn%27t include all%0D%0Athe execute path%2C so the  fix doesn%27t apply with some cases %28for example%2C the%0D%0Aclient uses CORBA%3A%3AORB%3A%3Aget_next_response%28%29 to get the result%29%2C CR100854 has%0D%0Afixed this. CR092176 just reverted the fix for CR087819 on hp-ux and linux%2C so%0D%0Athe memory leak problem will still exist on these platform.%0D%0A%0D%0AThis is not a typical regression because current behavior is more compliant to%0D%0Acorba specification. However%2C I include this case here to keep a record for%0D%0Athe following issues%3A%0D%0A* Fix to CR087819 is not release-noted even though it broke application code.%0D%0A* Fix to CR087819 is not completely corba-spec-compliant. It just fix the%0D%0A  string return value case. See Jeff%27s note in CR087819.%0D%0A* In CR092176%2C the port engineer reverted the CR087819%27s fix for HPUX%2FLinux%0D%0A  platforms. This leads to different behavior on different platforms.%0D%0A* Maybe the document should be changed to refect this new behavior.%0D%0A%0D%0A|11%2F12%2F2004
53118|TUX7.1 - CR - GWTDOMAIN fails to advertise a remote service dynamically%0D%0A|domain|7.1|101|Mahesh Jagannathan|Jian Dong|IB|306|closed|179797|CR053118 reordered the DMIB opeartion so that the unadvertise operation is%0D%0Aexecuted first. However%2C it also introduced a bug because it forgot to remove%0D%0Ait from GWADM SHM. That%27s the cause of CR089788. However%2C the fix to CR089788%0D%0Ajust revert the execution order of the above steps and caused CR179797. Jian%0D%0Afixed both situations in CR179797.%0D%0A|11%2F12%2F2004
89788|Remote service not advertized after *DM_IMPORT entry deleted%2Badded|dmib|7.1|219|Liang Luo|Jian Dong|IB|306|closed|179797|When handling DMIB operation with removes a remote service%2C two operations are%0D%0Ato be done%3A%0D%0A* Remove the service entry from GWADM SHM.%0D%0A* Unadvertise it from Bulletin Board.%0D%0A%0D%0ACR053118 reordered the DMIB opeartion so that the unadvertise operation is%0D%0Aexecuted first. However%2C it also introduced a bug because it forgot to remove%0D%0Ait from GWADM SHM. That%27s the cause of CR089788. However%2C the fix to CR089788%0D%0Ajust revert the execution order of the above steps and caused CR179797. Jian%0D%0Afixed both situations in CR179797.%0D%0A|11%2F12%2F2004