Bug#531419: mpicc segfaults when called by fakeroot
These patches were accepted into OMPI v1.3.3: https://svn.open-mpi.org/trac/ompi/changeset/21493 Exact release date is unknown, but hopefully soon. On Jun 20, 2009, at 7:23 AM, Jeff Squyres wrote: Done. The two patches you need are here: https://svn.open-mpi.org/trac/ompi/changeset/21479 https://svn.open-mpi.org/trac/ompi/changeset/21489 I'll push these upstream; they might make it into OMPI v1.3.3. On Jun 20, 2009, at 12:58 AM, Steve M. Robbins wrote: On Fri, Jun 19, 2009 at 06:52:03AM -0400, Jeff Squyres wrote: 2. If you want a more general env variable name, like checking for the presence of $FAKEROOTKEY (or whatever), let me know and we can also add a check for that upstream. To be clear, I think I'm going to do #1 anyway -- it's a nice way for our users to disable this stuff. But I'm notopposed to having a fakeroot-specific environment variable check as well. OK, that sounds like a good idea. Could you add a check for $FAKEROOTKEY, please. Just check whether it exists in the environment. Thanks, -Steve -- Jeff Squyres Cisco Systems -- Jeff Squyres Cisco Systems -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#531419: mpicc segfaults when called by fakeroot
On Jun 18, 2009, at 10:24 PM, Steve M. Robbins wrote: I uploaded this change to Debian's openmpi packages yesterday, patch below. Jeff: will you commit this upstream? Fakeroot maintainer: will you set OMPI_MCA_disable_memory_allocator to 1 in the fakeroot environment? Perhaps it would be better if you had debian/rules check to see if $FAKEROOTKEY is set and then export OMPI_MCA_disable_memory_allocator in that case. Perhaps, though I don't see any benefit to this approach rather than always setting the variable. Can you elaborate? Two things: 1. Doh; I suggested a poorly-named environment variable. For reasons you don't care about, OMPI_MCA_memory_ptmalloc2_disable would be a better name for us (vs. OMPI_MCA_disable_memory_allocator). Sorry about that! I just committed the check for OMCA_MCA_memory_ptmalloc2_disable upstream: https://svn.open-mpi.org/trac/ompi/changeset/21479 2. If you want a more general env variable name, like checking for the presence of $FAKEROOTKEY (or whatever), let me know and we can also add a check for that upstream. To be clear, I think I'm going to do #1 anyway -- it's a nice way for our users to disable this stuff. But I'm not opposed to having a fakeroot-specific environment variable check as well. -- Jeff Squyres Cisco Systems -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#531419: mpicc segfaults when called by fakeroot
Hi all, On Mon, Jun 08, 2009 at 08:09:43AM -0400, Jeff Squyres wrote: In short: perhaps you could setenv OMPI_MCA_disable_memory_allocator to 1, or somesuch. I can easily provide you with a patch (that we'd then also commit upstream, but you'll need the patch until we include this feature in a release) for such a fix. I uploaded this change to Debian's openmpi packages yesterday, patch below. Jeff: will you commit this upstream? Fakeroot maintainer: will you set OMPI_MCA_disable_memory_allocator to 1 in the fakeroot environment? Thanks, -Steve diff -u -r openmpi-1.3.2/opal/mca/memory/ptmalloc2/hooks.c ../openmpi-1.3.2/opal/mca/memory/ptmalloc2/hooks.c --- openmpi-1.3.2/opal/mca/memory/ptmalloc2/hooks.c 2009-04-21 22:51:03.0 -0500 +++ ../openmpi-1.3.2/opal/mca/memory/ptmalloc2/hooks.c 2009-06-17 21:55:54.0 -0500 @@ -725,6 +725,14 @@ check_result_t lpp = check(OMPI_MCA_mpi_leave_pinned_pipeline); bool want_rcache = false, found_driver = false; +/* Allow user to disable memory allocators. We check this and + * exit early because in some environments (e.g. Debian fakeroot + * the stat() calls below will cause a memory allocation, which + * is deadly. See http://bugs.debian.org/531522 + */ +if ( RESULT_YES == check(OMPI_MCA_disable_memory_allocator) ) + return; + /* Look for sentinel files (directories) to see if various network drivers are loaded (yes, I know, further abstraction violations...). signature.asc Description: Digital signature
Bug#531419: mpicc segfaults when called by fakeroot
On Thu, Jun 18, 2009 at 08:59:29PM -0500, Steve M. Robbins wrote: I uploaded this change to Debian's openmpi packages yesterday, patch below. Jeff: will you commit this upstream? Fakeroot maintainer: will you set OMPI_MCA_disable_memory_allocator to 1 in the fakeroot environment? Perhaps it would be better if you had debian/rules check to see if $FAKEROOTKEY is set and then export OMPI_MCA_disable_memory_allocator in that case. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#531522: [Pkg-openmpi-maintainers] Bug#531522: Bug#531419: mpicc segfaults when called by fakeroot
Hello guys, Le dimanche 14 juin 2009 à 11:19 -0500, Steve M. Robbins a écrit : On Sun, Jun 14, 2009 at 05:10:46PM +0200, Manuel Prinz wrote: Hi everyone! On Fri, June 12, 2009 11:10 pm, Jeff Squyres wrote: Agreed. We thought that stat() was safe to call in the malloc init hook -- it seems to be in most other places, at least. Jeff, I agree that one would expect stat() to be safe; my comment about crafty things wasn't intended as a judgement call on this approach. I think the code is pretty clever, but it's a hard problem when you are operating with no clear rules about what is permitted in the init hook. :-) Unfortunately, I will not be able to use the internet for a week from now. This means that I can't help fixing the issue. I'm very sorry about that! I hope Sylvestre can take over. If one wants to (or can) work out a fix, feel free to NMU. If Sylvestre wants to upload a fix, that's perfect. Otherwise, I can easily convert my #if 0 hack into a patch that checks for an environment variable. Jeff previously suggested setting OMPI_MCA_disable_memory_allocator; is that the variable we want to use? I am only following the bug report. I haven't dig enough to be able to fix it right now. Therefor, if someone provides a patch, I will be happy to upload OpenMPI with the fix/workaround. Otherwise, I will try to find some time to fix it. Sylvestre -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#531522: [Pkg-openmpi-maintainers] Bug#531522: Bug#531419: mpicc segfaults when called by fakeroot
Hi everyone! On Fri, June 12, 2009 11:10 pm, Jeff Squyres wrote: Agreed. We thought that stat() was safe to call in the malloc init hook -- it seems to be in most other places, at least. If there's some other safe way to check that stat() is *not* safe, that would be great. Unfortunately, I will not be able to use the internet for a week from now. This means that I can't help fixing the issue. I'm very sorry about that! I hope Sylvestre can take over. If one wants to (or can) work out a fix, feel free to NMU. I'm OK with 0-day NMUs for this case. The release team also needs to be informed about the upload to schedule rebuilds again. Sylvestre should be able to upload, though he is not a DD yet. But I guess you guys can work it out. I'm sorry for the situation and the delay it may cause! I will get back to it as soon as I am back again. Best regards Manuel -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#531522: [Pkg-openmpi-maintainers] Bug#531522: Bug#531419: mpicc segfaults when called by fakeroot
On Sun, Jun 14, 2009 at 05:10:46PM +0200, Manuel Prinz wrote: Hi everyone! On Fri, June 12, 2009 11:10 pm, Jeff Squyres wrote: Agreed. We thought that stat() was safe to call in the malloc init hook -- it seems to be in most other places, at least. Jeff, I agree that one would expect stat() to be safe; my comment about crafty things wasn't intended as a judgement call on this approach. I think the code is pretty clever, but it's a hard problem when you are operating with no clear rules about what is permitted in the init hook. :-) Unfortunately, I will not be able to use the internet for a week from now. This means that I can't help fixing the issue. I'm very sorry about that! I hope Sylvestre can take over. If one wants to (or can) work out a fix, feel free to NMU. If Sylvestre wants to upload a fix, that's perfect. Otherwise, I can easily convert my #if 0 hack into a patch that checks for an environment variable. Jeff previously suggested setting OMPI_MCA_disable_memory_allocator; is that the variable we want to use? Regards, -Steve signature.asc Description: Digital signature
Bug#531522: Bug#531419: mpicc segfaults when called by fakeroot
On Wed, Jun 10, 2009 at 01:59:41PM +0200, Manuel Prinz wrote: Checked again, the bug is somewhere in Open MPI. While testing on Lenny, I had some cruft left over. A fresh 1.3.2 installation shows the same behaviour. OK, so where do we go from here? It seems to me that OpenMPI is at fault for doing crafty things like stat() in the __malloc_initialize_hook(). If that is the accepted view, then having a way to suppress this behaviour, say with an environment variable as suggested by Jeff Squyres, seems appropriate. That would let me solve my problem by setting the variable in debian/rules. Or we could solve it Debian-wide by having the variable set by fakeroot. Thoughts? -Steve signature.asc Description: Digital signature
Bug#531419: Bug#531522: Bug#531419: mpicc segfaults when called by fakeroot
Agreed. We thought that stat() was safe to call in the malloc init hook -- it seems to be in most other places, at least. If there's some other safe way to check that stat() is *not* safe, that would be great. On Jun 12, 2009, at 1:44 AM, Steve M. Robbins wrote: On Wed, Jun 10, 2009 at 01:59:41PM +0200, Manuel Prinz wrote: Checked again, the bug is somewhere in Open MPI. While testing on Lenny, I had some cruft left over. A fresh 1.3.2 installation shows the same behaviour. OK, so where do we go from here? It seems to me that OpenMPI is at fault for doing crafty things like stat() in the __malloc_initialize_hook(). If that is the accepted view, then having a way to suppress this behaviour, say with an environment variable as suggested by Jeff Squyres, seems appropriate. That would let me solve my problem by setting the variable in debian/rules. Or we could solve it Debian-wide by having the variable set by fakeroot. Thoughts? -Steve -- Jeff Squyres Cisco Systems -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#531419: mpicc segfaults when called by fakeroot
Checked again, the bug is somewhere in Open MPI. While testing on Lenny, I had some cruft left over. A fresh 1.3.2 installation shows the same behaviour. Best regards Manuel -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#531419: mpicc segfaults when called by fakeroot
Hi Jeff! Am Montag, den 08.06.2009, 21:08 -0700 schrieb Jeff Squyres: Agreed; fixing the root problem is a better bet. Manuel -- can you ping the fakeroot people? It would be preferable to the method described in that URL. The fakeroot maintainers are in CC, they should have gotten the last message of yours. As for the root cause, I'm still puzzled. I tested it today with the most recent eglic (2.9-13) and an older glibc (2.9-10) provided by Aurelien Jarno against almost all versions of fakeroot available on snapshort.debian.net. Segfaults with all combinations. On the other hand, as I wrote in message #45, it seems to work fine on my Lenny box which has glibc 2.7-18. I will test this version on my unstable box tomorrow. For some reason, fakeroot and Open MPI 1.3.2 don't show issues in the versions in Lenny. I'll also test the fakeroot version in unstable on my Lenny box tomorrow. Not sure if this brings any insight, though. Best regards Manuel signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Bug#531419: mpicc segfaults when called by fakeroot
On Mon, Jun 08, 2009 at 06:13:56AM -0400, Jeff Squyres (jsquyres) wrote: Is there a run-time way to tell if we're running under fakeroot? We can certainly just disable the malloc init hook if it detects that its under fakeroot. You can use an undocumented API feature to detect/disable fakeroot temporarily (see the bottom of this message: http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=15;att=0;bug=224030 ) or you can look for environmental variables being set. Fixing the root cause is probably preferable, though I don't have much time to look at it myself. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#531419: mpicc segfaults when called by fakeroot
Further thought: if it's not possible to run-time detect that we're running in fakeroot, perhaps an environment variable could be set before OMPI's mpicc is launched in the fakeroot so that we can see in the malloc hook init that that variable exists and therefore dump out before the stat's...? (i.e., effectively provide our own way to know that we're running in fakeroot, and therefore disable all of ompi's malloc init/openfabrics/etc. infrastructure, because OpenFabrics support is *not* required in fakeroot). In short: perhaps you could setenv OMPI_MCA_disable_memory_allocator to 1, or somesuch. I can easily provide you with a patch (that we'd then also commit upstream, but you'll need the patch until we include this feature in a release) for such a fix. Is that too ugly? On Jun 7, 2009, at 5:51 PM, Manuel Prinz wrote: 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 -- Jeff Squyres Cisco Systems -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#531419: mpicc segfaults when called by fakeroot
On Jun 2, 2009, at 4:25 PM, Manuel Prinz wrote:
I'm putting you in the loop since I'm quite lost here... It would be
great if you could throw in your thoughts!
Sorry for the delay in replying; this week has been crazier than most.
mpicc segfaults when it's called via fakeroot.
What is fakeroot?
Since this tool is needed
in the build process of Debian packages, packages depending on Open
MPI
fail to build. This blocks our transition to 1.3.2. Nicholas was so
kind
to investigate the issue; his results are quoted below.
As far as I can say, the problem appeared somewhere between Open MPI
1.3
and 1.3.2. I also successfully used mpicc with fakeroot before Debian
switched to eglibc, so this might be the cause. (Though it should be
fully compatible to glibc. At least they claim to be.)
Do you have some idea what might go wrong?
Based on the call stack, yes. Uccckkk!! More below...
FWIW, debugging OMPI is easier if you tell OMPI to slurp all the
plugins into its libraries -- so there's no dlopen's and all the
plugins are physically located in libmpi.so (and friends). You can
get better call stacks this way from corefiles, etc.
Although I think a lot of those missing symbols are in glibc, not ompi.
Okay, it looks like the root cause is something that's appeared
recently in
openmpi - it fails under 1.3.2-2, but works under 1.3-2. Manuel,
I'm cloning
the bug for tracking purposes, but I'm certainly not sure that it's
actually an
OpenMPI bug at heart. Have you seen anything else like this?
% echo int main(void) { return 0; } test.c
% mpicc.openmpi test.c ; echo $?
0
% fakeroot mpicc.openmpi test.c ; echo $?
Segmentation fault
139
No failures with the other MPI implementations, nor with OpenMPI
1.3. I can
put it under gdb but am missing some debugging libraries in the
middle:
% fakeroot gdb mpicc.openmpi
[...]
(gdb) run test.c
Starting program: /usr/bin/mpicc.openmpi conftest.c
[Thread debugging using libthread_db enabled]
[New Thread 0xb7dc46c0 (LWP 6958)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb7dc46c0 (LWP 6958)]
__libc_calloc (n=1, elem_size=20) at malloc.c:3932
3932malloc.c: No such file or directory.
in malloc.c
(gdb) bt
#0 __libc_calloc (n=1, elem_size=20) at malloc.c:3932
#1 0xb7f83086 in _dlerror_run (operate=0xb7f82d90 dlsym_doit,
args=0xbfd3002c) at dlerror.c:142
#2 0xb7f82d43 in __dlsym (handle=0x, name=0xb800f16a
open) at dlsym.c:71
#3 0xb800db73 in load_library_symbols () from /usr/lib/libfakeroot/
libfakeroot-sysv.so
#4 0xb800e687 in tmp___xstat () from /usr/lib/libfakeroot/
libfakeroot-sysv.so
#5 0xb800daa3 in __xstat () from /usr/lib/libfakeroot/libfakeroot-
sysv.so
#6 0xb7fbcefc in ?? () from /usr/lib/libopen-pal.so.0
#7 0x0003 in ?? ()
#8 0xb7fc948e in ?? () from /usr/lib/libopen-pal.so.0
#9 0xbfd300e4 in ?? ()
#10 0x1b2e in ?? ()
#11 0xbfd300e4 in ?? ()
#12 0x0003 in ?? ()
#13 0x0003 in ?? ()
#14 0xbfd30164 in ?? ()
#15 0xb7f20ff4 in ?? () from /lib/i686/cmov/libc.so.6
#16 0x0001 in ?? ()
#17 0xb7dc8d0c in ?? () from /lib/i686/cmov/libc.so.6
#18 0xbfd30148 in ?? ()
#19 0xb7ee4429 in *__GI__dl_addr (address=0xb7e34e70,
info=0xbfd30184, mapp=0xbfd30194,
symbolp=0xb7f2260c) at dl-addr.c:146
#20 0xb7e35096 in ptmalloc_init () at arena.c:571
#21 0xb7e386bc in malloc_hook_ini (sz=12, caller=0xb7f939ab) at
hooks.c:37
#22 0xb7e38535 in *__GI___libc_malloc (bytes=12) at malloc.c:3546
#23 0xb7f939ab in opal_class_initialize () from /usr/lib/libopen-
pal.so.0
#24 0xb7fb3227 in opal_output_init () from /usr/lib/libopen-pal.so.0
#25 0xb7f96205 in opal_init_util () from /usr/lib/libopen-pal.so.0
#26 0x08049b62 in main (argc=2, argv=0xbfd30404) at ../../../../../
opal/tools/wrappers/opal_wrapper.c:480
Ick... I have zero experience with eglibc; this *could* be a
compatibility issue...?
In OMPI 1.3.2, we started using the __malloc_initialize_hook
functionality to get a function of ours called at the first time the
memory allocation subsystem is invoked in a process. Specifically, we
do this:
void (*__malloc_initialize_hook) (void) =
opal_memory_ptmalloc2_malloc_init_hook;
which sets up opal_memory_ptmalloc_malloc_init_hook() to be invoked
during the memory subsystem's init (sometimes even pre-main). This
function is in opal/mca/memory/ptmalloc2/hooks.c. Note that this is a
*different* hooks.c than is listed at #21 in the stack trace above.
It looks like that is the ptmalloc2 hooks.c that is in elibc, and it
is calling the elibc ptmalloc_init() which should then be calling our
init hook function (opal_memory_ptmalloc2_malloc_init_hook). Can you
step throught and see what is happening there?
I wonder if there's a bug in elibc such that when it's looking up this
symbol, it's trying to open libopen-pal.so to find that symbol, and
something is going bad in there...?
It's weird that the gdb #2 is a dlsym of -1 (self)
Bug#531419: mpicc segfaults when called by fakeroot
On Jun 5, 2009, at 2:39 PM, Jeff Squyres wrote: FWIW, debugging OMPI is easier if you tell OMPI to slurp all the plugins into its libraries -- so there's no dlopen's and all the plugins are physically located in libmpi.so (and friends). You can get better call stacks this way from corefiles, etc. Oops! I neglected to say that you can effect this behavior by specifying the --disable-dlopen flag to OMPI's configure. This turns off our internal libltdl entirely (i.e., it doesn't even build) and simultaneously slurps all of our plugins up into their relevant libraries (e.g., libmpi.so, libopen-pal.so, etc.). -- Jeff Squyres Cisco Systems -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#531419: mpicc segfaults when called by fakeroot
tags 531419 + confirmed
thanks
Hi Jeff,
I'm putting you in the loop since I'm quite lost here... It would be
great if you could throw in your thoughts!
mpicc segfaults when it's called via fakeroot. Since this tool is needed
in the build process of Debian packages, packages depending on Open MPI
fail to build. This blocks our transition to 1.3.2. Nicholas was so kind
to investigate the issue; his results are quoted below.
As far as I can say, the problem appeared somewhere between Open MPI 1.3
and 1.3.2. I also successfully used mpicc with fakeroot before Debian
switched to eglibc, so this might be the cause. (Though it should be
fully compatible to glibc. At least they claim to be.)
Do you have some idea what might go wrong?
Best regards
Manuel
Am Montag, den 01.06.2009, 19:15 -0700 schrieb Nicholas Breen:
Okay, it looks like the root cause is something that's appeared recently in
openmpi - it fails under 1.3.2-2, but works under 1.3-2. Manuel, I'm cloning
the bug for tracking purposes, but I'm certainly not sure that it's actually
an
OpenMPI bug at heart. Have you seen anything else like this?
% echo int main(void) { return 0; } test.c
% mpicc.openmpi test.c ; echo $?
0
% fakeroot mpicc.openmpi test.c ; echo $?
Segmentation fault
139
No failures with the other MPI implementations, nor with OpenMPI 1.3. I can
put it under gdb but am missing some debugging libraries in the middle:
% fakeroot gdb mpicc.openmpi
[...]
(gdb) run test.c
Starting program: /usr/bin/mpicc.openmpi conftest.c
[Thread debugging using libthread_db enabled]
[New Thread 0xb7dc46c0 (LWP 6958)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb7dc46c0 (LWP 6958)]
__libc_calloc (n=1, elem_size=20) at malloc.c:3932
3932malloc.c: No such file or directory.
in malloc.c
(gdb) bt
#0 __libc_calloc (n=1, elem_size=20) at malloc.c:3932
#1 0xb7f83086 in _dlerror_run (operate=0xb7f82d90 dlsym_doit,
args=0xbfd3002c) at dlerror.c:142
#2 0xb7f82d43 in __dlsym (handle=0x, name=0xb800f16a open) at
dlsym.c:71
#3 0xb800db73 in load_library_symbols () from
/usr/lib/libfakeroot/libfakeroot-sysv.so
#4 0xb800e687 in tmp___xstat () from /usr/lib/libfakeroot/libfakeroot-sysv.so
#5 0xb800daa3 in __xstat () from /usr/lib/libfakeroot/libfakeroot-sysv.so
#6 0xb7fbcefc in ?? () from /usr/lib/libopen-pal.so.0
#7 0x0003 in ?? ()
#8 0xb7fc948e in ?? () from /usr/lib/libopen-pal.so.0
#9 0xbfd300e4 in ?? ()
#10 0x1b2e in ?? ()
#11 0xbfd300e4 in ?? ()
#12 0x0003 in ?? ()
#13 0x0003 in ?? ()
#14 0xbfd30164 in ?? ()
#15 0xb7f20ff4 in ?? () from /lib/i686/cmov/libc.so.6
#16 0x0001 in ?? ()
#17 0xb7dc8d0c in ?? () from /lib/i686/cmov/libc.so.6
#18 0xbfd30148 in ?? ()
#19 0xb7ee4429 in *__GI__dl_addr (address=0xb7e34e70, info=0xbfd30184,
mapp=0xbfd30194,
symbolp=0xb7f2260c) at dl-addr.c:146
#20 0xb7e35096 in ptmalloc_init () at arena.c:571
#21 0xb7e386bc in malloc_hook_ini (sz=12, caller=0xb7f939ab) at hooks.c:37
#22 0xb7e38535 in *__GI___libc_malloc (bytes=12) at malloc.c:3546
#23 0xb7f939ab in opal_class_initialize () from /usr/lib/libopen-pal.so.0
#24 0xb7fb3227 in opal_output_init () from /usr/lib/libopen-pal.so.0
#25 0xb7f96205 in opal_init_util () from /usr/lib/libopen-pal.so.0
#26 0x08049b62 in main (argc=2, argv=0xbfd30404) at
../../../../../opal/tools/wrappers/opal_wrapper.c:480
I confess that the peculiar interactions of compilers, fakeroot, and (e)glibc
put me well out of my depth.
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
