public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
* RE: Problem with allocator in a multithreaded application.
@ 2004-05-25  0:12 lrtaylor
  2004-05-25  0:41 ` Nathan Zorn
  0 siblings, 1 reply; 4+ messages in thread
From: lrtaylor @ 2004-05-25  0:12 UTC (permalink / raw)
  To: nzorn, gcc-help

Just a shot in the dark, but did you build it with the -pthread option
(for both compiling and linking)?

Thanks,
Lyle

-----Original Message-----
From: gcc-help-owner@gcc.gnu.org [mailto:gcc-help-owner@gcc.gnu.org] On
Behalf Of Nathan Zorn
Sent: Monday, May 24, 2004 5:58 PM
To: gcc-help@gcc.gnu.org
Subject: Problem with allocator in a multithreaded application.

Maybe this should go to libstdc++, but I will try this list first.   I 
am developing a multithreaded
application that uses a lot of the std containers and streams.  Since 
the platform  I am developing
for is redhat 7.2 , I initially used the compiler that is shipped with 
that distribution (2.96).  This
version had its problems, so I decided to start using gcc version 3.3.2 
(the latest at the time).  I
built this version with only the --enable-threads configure switch.   I 
released a stable version of
my application with this build.   Recently I switched development 
machines and attempted
to rebuild the gcc compiler (again only with --enable-threads configure 
option).  Ever since this rebuild my application has had strange memory 
leak problems.  It will run for awhile then consume all
the machines memory resources.  This is the same version of my code that

ran fine before and
the same version of gcc (only rebuilt on the new machine).  Since this 
version of gcc didn't work
I also tried gcc 3.4.0 with the same result.  I have ran this 
application through valgrind with
no reports of problems except in the std::allocator code.  I found this 
in the FAQ which explains that it isn't a leak but just the behavior of 
the basic allocator.  So, I created a small application [1] that when it

is run through valgrind single threaded its fine, but multithreaded it 
definitely
seems to leak memory.  Also in order to elliminate that it is my code, I

built my application
with the Intel compiler and the memory leak didn't occur, even after 
three days of running.


Any suggestions and help is appreciated.  I really don't want to start 
using the intel compiler instead of gcc.

Thanks

[1] http://bfs.itlab.musc.edu/~nathan/stl_vector.C

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Problem with allocator in a multithreaded application.
  2004-05-25  0:12 Problem with allocator in a multithreaded application lrtaylor
@ 2004-05-25  0:41 ` Nathan Zorn
  0 siblings, 0 replies; 4+ messages in thread
From: Nathan Zorn @ 2004-05-25  0:41 UTC (permalink / raw)
  To: lrtaylor; +Cc: gcc-help

Yes, I built it with the -pthread option for both linking and compiling.

I built the test application with g++ -pthread stl_vector.C -o stl_vector.

The only other switched I used with compiling and linking my larger 
application
was the -O3 option to turn on all the optimizations.  I also tried 
different levels
down to no optimization, but they all have the same memory issue.

lrtaylor@micron.com wrote:

>Just a shot in the dark, but did you build it with the -pthread option
>(for both compiling and linking)?
>
>Thanks,
>Lyle
>
>-----Original Message-----
>From: gcc-help-owner@gcc.gnu.org [mailto:gcc-help-owner@gcc.gnu.org] On
>Behalf Of Nathan Zorn
>Sent: Monday, May 24, 2004 5:58 PM
>To: gcc-help@gcc.gnu.org
>Subject: Problem with allocator in a multithreaded application.
>
>Maybe this should go to libstdc++, but I will try this list first.   I 
>am developing a multithreaded
>application that uses a lot of the std containers and streams.  Since 
>the platform  I am developing
>for is redhat 7.2 , I initially used the compiler that is shipped with 
>that distribution (2.96).  This
>version had its problems, so I decided to start using gcc version 3.3.2 
>(the latest at the time).  I
>built this version with only the --enable-threads configure switch.   I 
>released a stable version of
>my application with this build.   Recently I switched development 
>machines and attempted
>to rebuild the gcc compiler (again only with --enable-threads configure 
>option).  Ever since this rebuild my application has had strange memory 
>leak problems.  It will run for awhile then consume all
>the machines memory resources.  This is the same version of my code that
>
>ran fine before and
>the same version of gcc (only rebuilt on the new machine).  Since this 
>version of gcc didn't work
>I also tried gcc 3.4.0 with the same result.  I have ran this 
>application through valgrind with
>no reports of problems except in the std::allocator code.  I found this 
>in the FAQ which explains that it isn't a leak but just the behavior of 
>the basic allocator.  So, I created a small application [1] that when it
>
>is run through valgrind single threaded its fine, but multithreaded it 
>definitely
>seems to leak memory.  Also in order to elliminate that it is my code, I
>
>built my application
>with the Intel compiler and the memory leak didn't occur, even after 
>three days of running.
>
>
>Any suggestions and help is appreciated.  I really don't want to start 
>using the intel compiler instead of gcc.
>
>Thanks
>
>[1] http://bfs.itlab.musc.edu/~nathan/stl_vector.C
>
>
>  
>

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Problem with allocator in a multithreaded application.
  2004-05-24 23:58 Nathan Zorn
@ 2004-05-27 21:13 ` llewelly
  0 siblings, 0 replies; 4+ messages in thread
From: llewelly @ 2004-05-27 21:13 UTC (permalink / raw)
  To: Nathan Zorn; +Cc: gcc-help

Nathan Zorn <nzorn@d2.com> writes:

> Maybe this should go to libstdc++, but I will try this list first.
> I

It has been a few days. Try libstdc++ or bugzilla.

> am developing a multithreaded
> application that uses a lot of the std containers and streams.  Since
> the platform  I am developing
> for is redhat 7.2 , I initially used the compiler that is shipped with
> that distribution (2.96).  This
> version had its problems, so I decided to start using gcc version
> 3.3.2 (the latest at the time).  I
> built this version with only the --enable-threads configure switch.
> I released a stable version of
> my application with this build.   Recently I switched development
> machines and attempted
> to rebuild the gcc compiler (again only with --enable-threads
> configure option).  Ever since this rebuild my application has had
> strange memory leak problems.  It will run for awhile then consume all
> the machines memory resources.  This is the same version of my code
> that ran fine before and
> the same version of gcc (only rebuilt on the new machine).  Since this
> version of gcc didn't work
> I also tried gcc 3.4.0 with the same result.  I have ran this
> application through valgrind with
> no reports of problems except in the std::allocator code.  I found
> this in the FAQ which explains that it isn't a leak but just the
> behavior of the basic allocator.  So, I created a small application
> [1] that when it is run through valgrind single threaded its fine, but
> multithreaded it definitely
> seems to leak memory.  Also in order to elliminate that it is my code,
> I built my application
> with the Intel compiler and the memory leak didn't occur, even after
> three days of running.
> 
> 
> Any suggestions and help is appreciated.  I really don't want to start
> using the intel compiler instead of gcc.
> 
> Thanks
> 
> [1] http://bfs.itlab.musc.edu/~nathan/stl_vector.C

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Problem with allocator in a multithreaded application.
@ 2004-05-24 23:58 Nathan Zorn
  2004-05-27 21:13 ` llewelly
  0 siblings, 1 reply; 4+ messages in thread
From: Nathan Zorn @ 2004-05-24 23:58 UTC (permalink / raw)
  To: gcc-help

Maybe this should go to libstdc++, but I will try this list first.   I 
am developing a multithreaded
application that uses a lot of the std containers and streams.  Since 
the platform  I am developing
for is redhat 7.2 , I initially used the compiler that is shipped with 
that distribution (2.96).  This
version had its problems, so I decided to start using gcc version 3.3.2 
(the latest at the time).  I
built this version with only the --enable-threads configure switch.   I 
released a stable version of
my application with this build.   Recently I switched development 
machines and attempted
to rebuild the gcc compiler (again only with --enable-threads configure 
option).  Ever since this rebuild my application has had strange memory 
leak problems.  It will run for awhile then consume all
the machines memory resources.  This is the same version of my code that 
ran fine before and
the same version of gcc (only rebuilt on the new machine).  Since this 
version of gcc didn't work
I also tried gcc 3.4.0 with the same result.  I have ran this 
application through valgrind with
no reports of problems except in the std::allocator code.  I found this 
in the FAQ which explains that it isn't a leak but just the behavior of 
the basic allocator.  So, I created a small application [1] that when it 
is run through valgrind single threaded its fine, but multithreaded it 
definitely
seems to leak memory.  Also in order to elliminate that it is my code, I 
built my application
with the Intel compiler and the memory leak didn't occur, even after 
three days of running.


Any suggestions and help is appreciated.  I really don't want to start 
using the intel compiler instead of gcc.

Thanks

[1] http://bfs.itlab.musc.edu/~nathan/stl_vector.C

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2004-05-27 21:13 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-05-25  0:12 Problem with allocator in a multithreaded application lrtaylor
2004-05-25  0:41 ` Nathan Zorn
  -- strict thread matches above, loose matches on Subject: below --
2004-05-24 23:58 Nathan Zorn
2004-05-27 21:13 ` llewelly

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).