Re: Debugging segfaults in commercial software on Jessie
Hi
On Tue, Nov 19, 2013 at 10:14:22AM +0000, Bernhard Schmidt wrote:
> Hi,
>
> I'm a bit at a loss here, maybe someone has an idea how to look.
>
> We run a commercial software called IBM Tivoli Storage Manager (TSM) for
> Backup purposes. It is quite an ugly beast, but it works just fine on
> Wheezy.
Oh. You have my condolences. Anything starting with "IBM Tivoli"
is... bad.
> When upgrading to Jessie, it produces a segfault on most systems
>
> root@lxmhs70:~# dsmc q fi
> IBM Tivoli Storage Manager
> Command Line Backup-Archive Client Interface
> Client Version 6, Release 4, Level 0.7
> Client date/time: 11/19/2013 10:57:01
> (c) Copyright by IBM Corporation and other(s) 1990, 2013. All Rights
> Reserved.
>
> Node Name: LXMHS70
> Aborted
You may be able to make some headway by using strace, to see which
systems calls it uses:
root@lxmhs70:~# strace dsmc q fi
But it is bound to be a long slog....
(nice hostname by the way...)
> 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.
>
> My colleague "fixed" it by using an older libc, using this method
> (http://www.debian-administration.org/users/lee/weblog/30) and the
> following packages
>
> libc6_2.13-38_amd64.deb
> libgcc1_4.7.2-5_amd64.deb
> libstdc++6_4.7.2-5_amd64.deb
> libtinfo5_5.9-10_amd64.deb
>
> but as I said, it works for me just fine.
When running such software, I find it handy to relegate it to a chroot
environment: commercial software tends to be very fickle with
dependencies - many of which are undeclared. So to avoid too many
distracting discussions, I'd be sorely tempted to set up a debian
stable chroot to do stuff in. Or go the whole hog and use a LxC
instance...
> Does anyone have an idea how to debug this? I don't want to open a bug
> report right now on either side because its commercial software on a
> non-stable distribution version.
Well - if the developers are worth their salt, they probably *want* to
know about this not working on the next version of Debian. I know
that I would....
Best bet would probably be to look at migrating away from it... But I
suspect that the golden rule[1] applies and you're stuck with it
because that's what the PHB wanted...
[1] The golden rule: Those with the gold make the rules.
--
Karl E. Jorgensen
Reply to: