[Debichem-devel] Bug#531419: mpicc segfaults when called by fakeroot

Manuel Prinz debian at pinguinkiste.de
Sun Jun 7 21:51:14 UTC 2009


Hi Jeff and Steve,

thanks a lot for diving into it! It's very appreciated! (I was not able
to access a computer during the last two days, so sorry for being
unresponsive!)

Am Sonntag, den 07.06.2009, 11:04 -0500 schrieb Steve M. Robbins:
> I was able to avoid the segfault simply by ifdef'ing out this section
> (patch attached).  This should suffice in the short term for Debian on
> the theory that OpenMPI compatibility with fakeroot is more important
> than OpenMPI compatibility with OpenFabrics.

This is very hard to decide. Of course, we need Open MPI to work with
fakeroot, since our build system relies on that. There's no way around
that. As for OpenFabrics, probably most users will use MPI over fast
interconnects, so we really do need InfiniBand support as well. With the
transition in mind, I would consider disabling InfiniBand as a
short-term and temporary option.

Nevertheless, I will do some more tests tomorrow, hoping to find a less
drastic solution. Jeff's suggestion to disable libltdl sounds like a
reasonable thing. As it seems, we should probably disable it anyway
since Open MPI brings it's own copy and does not allow to build against
a version already installed on the system. Jeff, can you confirm that?

(Currently, the versions of libltdl of Open MPI and Debian seem to
differ. Though might not be the reason, it might mean some extra work
for the release and/or security team.)

> However, there is clearly a bad interaction between this code, eglibc,
> and fakeroot.  Hence the cc's to the various packages.

Thanks for putting them in the loop! I already sent a mail to the libc
maintainers a view days ago but did not test with a downgraded libc.

> I'm speculating that memory allocation while in the
> __malloc_initialize_hook is a bad thing.  Perhaps the stat() in
> fakeroot caused a memory allocation, whereas the regular stat() does
> not, as this code doesn't segfault in normal use.

This is what I had in mind as well.

Thanks for your work so far! I'm quite confident that we can sort it out
soon! :)

Best regards
Manuel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
URL: <http://lists.alioth.debian.org/pipermail/debichem-devel/attachments/20090607/f89429ed/attachment.pgp>


More information about the Debichem-devel mailing list