Re: [Buildd-tools-devel] Processed: Clone and reassign to libstdc++
On Mon, Mar 23, 2009 at 10:36:10AM +0000, Debian Bug Tracking System wrote:
> Processing commands for control@bugs.debian.org:
>
> > clone 520713 -1
> Bug#520713: init script start hangs
> Bug 520713 cloned as bug 520889.
>
> > reassign -1 libstdc++6
> Bug#520889: init script start hangs
> Bug reassigned from package `schroot' to `libstdc++6'.
>
> > retitle -1 std::tr1::shared_ptr is broken on alpha unless code is compiled with -pthread
> Bug#520889: init script start hangs
> Changed Bug title to `std::tr1::shared_ptr is broken on alpha unless code is compiled with -pthread' from `init script start hangs'.
Hi Debian GCC people,
I cloned and reassigned this to you because while I worked around this
bug in schroot, I do feel that this is fundamentally an issue in
libstdc++.
It appears from the bug investigation that the std::tr1::shared_ptr
type is using a pthread mutex for locking (which is using futexes
on the kernel side). I'm surprised about this because I thought it
would just be using atomic increment/decrement (unless this is an
alpha-specific implementation detail), but this is not in itself
a problem.
What did surprise me is that
- my program is single threaded; it does not directly use any pthread-
related stuff, just types from the ISO C++ Standard, and its TR1
addendum.
- I did therefore not expect there would be a requirement to compile
with -pthread in order to get a functional program.
- On all architectures I'm aware of other than alpha, the code works
correctly.
- On alpha it crashes with a failed libc/libstdc++ assertion during
object construction (where I am creating a new type instance which
is returned contained within a shared_ptr). The stack trace showed
it failing in my object constructor called from my clone() method
which returns a shared_ptr (the actual ctor is private), but the
pthread failure subsequently points the blame at shared_ptr, since
I'm not using any pthread stuff myself.
- One of the traces attached to the bug report shows a failure
inside a Boost header; it's possible that it's an interaction
between the boost and libstdc++ headers, but I can't be sure of
that.
I have Cc'd weasel, who originally found this bug on alpha.
I don't have any alpha hardware myself, so you would probably need
to ask weasel or one of the alpha porters if you need any alpha-
specific expertise.
Regards,
Roger
--
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/
`- GPG Public Key: 0x25BFB848 Please GPG sign your mail.
Reply to: