Q. about threads and the STL

Philip Charlton charlton@ligo.caltech.edu
Mon Aug 20 14:44:00 GMT 2001


> Philip Charlton <charlton@ligo.caltech.edu> writes:
>
> [...]
>
> | The problem seems
> | to go away when I remove the declaration of the Sequence<float>, which
> | makes me wonder if there is a problem with the way memory is allocated for
> | it by the STL allocator, although we have definitely configured our gcc
> | with --enable-threads=posix and even defined __USE_MALLOC in libstdc++-v3.
>
> For valarray<>, I don't use an STL-like allocator; I just call
> operator new/operator delelte.

Hi - thanks for the prompt reply!
I saw that valarray uses new/delete but wasn't sure if it still used some
underlying non-threadsafe allocator replacing malloc() to do those.
I have know clue as to what's really going on - I would be totally
convinced it was a problem with my code rather than a compiler, kernel or
library problem, except for the fact that the segfault occurs after the
threads have completed and no core file gets generated.

It is also the case that changing my Sequence<float> to a mere
valarray<float> also seems to make the problem go away, but looking at the
additional stuff that my Sequence has over valarray it's hard to
understand why this would make a difference, although for a coding
error this is a likely candidate. I've also noticed that
removing some other functions and/or code (some that's not even exercised
by the test anymore) makes the problem go away - it's mysterious. The fact
that it only occurs on multi-cpu platforms has me thinking that it could
be a problem with the SMP kernel - we have seen it happen on 2 machines so
far, a 2.2.19 and the 2.4.6, both with 4 CPU's.

> | The system I'm running it on has 4 CPU's and Linux 2.4.6 #1 SMP kernel.
> | I'm compiling with gcc version 2.95.3 20010315 (release)
>
> I don't have access to multi-processor machines, but if you could give
> a try to current release, that would be very helpful.  There are some
> differences between the versions in GCC-2.95.3 and GCC-3.0.1.  But I
> can't tell whether they affect in some way your problem.
> I can't tell from scratch whether it is an internal OS-specific memory
> management problem.

We are working towards porting everything to gcc-3.x right now ie. putting
in all the namespace stuff, so maybe this will fix it. Sorry I can't give
you a simple piece of code that exhibits the problem yet - I'm working on
it but everytime I change something it goes away! The main reason for
posting to the list was to see if anyone else has experienced a similar
problem or can recognise the symptoms. I'd especially like to know what
causes a corefile not to be dumped...

Regards
Philip




More information about the Libstdc++ mailing list