Bernhard Schmidt <be...@birkenwald.de> wrote: Hi,
[ IBM TSM client segfaults on some Jessie boxes ] >>>> The weird thing is, my colleague running sid on his desktop has the same >>>> problem. My desktop, running Jessie, does _not_ have the same problem. >>>> The VM in question, also running Jessie, does have this problem. >>> >>> Interesting... Perhaps there are differences in the package versions? >>> Subtle ones? I'd say run a "dpkg -l | grep '^ii'" on both (or all 3) >>> systems and diff the output... It's bound to flag *something* up, >>> unfortunately most of it is probably insignificant. But there could be >>> a gold nugget in there. >>> >>>> >>>> I compared strace on both sides and there is no notable difference (more >>>> filesystems on my desktop, but nothing extraordinary). Library versions >>>> are the same. I adjusted environment variables to be the same, no >>>> difference. >>> >>> Ah. You've been there already. >> >> Just to report back, so far my attempts have been unsuccessful. I've >> compared the package lists on all three systems. It was quite messy >> since two of them are vastly differently managed work desktops, and I >> could not find any clues in there. I also fiddled some more with >> environment variables, but no go. >> >> I'll keep trying. > > Found something. Backtrace: > > (gdb) bt > #0 0x0000000000685ad6 in psCreateCryptoKey(unsigned char*, char*) () > #1 0x00000000008f58fb in psPasswordFile::readPassword(unsigned char, > char*, char*, char const*, unsigned char*, bool) () > #2 0x00000000006bbcc8 in PasswordFile::getPassword(unsigned char, > char*&, unsigned int*, char*, char const*, unsigned char*, bool) () > #3 0x00000000006b3261 in pswdFGetPassword(Sess_o*) () > #4 0x00000000005ede47 in scPswdEncrypt(Sess_o*, unsigned char*, > unsigned int, unsigned char*, unsigned int*, unsigned char) () > > More googling revealed https://bugzilla.redhat.com/show_bug.cgi?id=1030142 > > I'll try to open a case with IBM. Our TSM guy found the bugreport. http://www-01.ibm.com/support/docview.wss?uid=swg1IC92662&myns=apar&mynp=DO IC92662: TSM CLIENT CAN CRASH WITH CERTAIN NODENAMES ON LINUX DISTRIBUTIONS IF USING GLIBC 2.16 OR HIGHER IN THE FUTURE APAR status Closed as program error. Error description A code defect has been detected in the TSM Linux x86 client. While it does not manifest today in any currently-supported Linux distributions, here would be the symptom: When PASSWORDACCESS is set to GENERATE, TSM Linux client could crash when trying to read or write the password file. This will happen when installed glibc is version 2.16 or higher, and only with certain node names. It is not possible to identify the node name pattern triggering the issue. The crash can occur on short and long names, with and without non-alpha characters. However, when the failing combination of characters is used as the node name, the problem is consistently recreatable. One class of node names known to trigger the issue are the names of 3 symbols or less. For example, ABC, F35, R2 etc. An example of a longer node name is LINUX-123456 Since currently-supported RedHet and SuSE distributions do not yet support this Glibc level, there is no current error. However, this APAR is being opened to address the potential future issue when that Glibc level is supported. Local fix One of the following workarounds can be used: 1. Downgrade glibc to version 2.15 or lower, if possible. 2. Change the node name. In most cases, adding, deleting or modifying a single character is sufficient. 3. Set PASSWORDACCESS to PROMPT and add PASSWORD option to your dsm.sys options file. Make sure to restrict file system access to dsm.sys so non-authorized users can't see the node password. Problem summary **************************************************************** * USERS AFFECTED: All clients versions 6.3 and 6.4 running * * on Linux platforms with glibc version 2.16 * * or higher. * **************************************************************** * PROBLEM DESCRIPTION: See ERROR DESCRIPTION. * **************************************************************** * RECOMMENDATION: Apply fixing level when available. This * * problem is currently projected to be fixed * * in levels 6.3.2 and 6.4.2. Note that until * * these levels are available, this * * information is subject to change at the * * discretion of IBM. * **************************************************************** * Problem conclusion The problem has been fixed so that it no longer occurs. Best Regards, Bernhard -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/l6vgu7$9tn$1...@ger.gmane.org