Debian Bug report logs -
#42622
libstdc++2.10-dev: stl_alloc.h: malloc_alloc out of memory handling abort()s instead of using exceptions
Reported by: inaky@peloncho.fis.ucm.es
Date: Sat, 7 Aug 1999 16:48:00 UTC
Severity: fixed
Found in version 1:2.95-2
Done: Matthias Klose <doko@cs.tu-berlin.de>
Bug is archived. No further changes may be made.
Forwarded to gcc-bugs@gcc.gnu.org
Toggle useless messages
Report forwarded to debian-bugs-dist@lists.debian.org, Debian GCC maintainers <gcc@packages.debian.org>:
Bug#42622; Package libstdc++2.10-dev.
(full text, mbox, link).
Acknowledgement sent to inaky@peloncho.fis.ucm.es:
New bug report received and forwarded. Copy sent to Debian GCC maintainers <gcc@packages.debian.org>.
(full text, mbox, link).
Message #5 received at submit@bugs.debian.org (full text, mbox, reply):
Package: libstdc++2.10-dev
Version: 1:2.95-2
Severity: important
Hi
While coding some proof-of-concepts I've come around using a
vector<> of a big lot of elements. Wanted to push the limits and try
to recover possible failures. No way. The program was aborting on the
library's own.
That should not do. You want exceptions to be able to dictate
how the program should behave on error situations. The thing is at
stl_alloc.h, instead of throwing an exception on OOM, it was printing
the message "out of memory" to stderr and aborting. It is also
prepared for doing it via exceptions, so I think it should be the
default way.
I think that behaviour should be made extensible to the whole
libstdc++ library, as as far as I know, exception support in GCC is
mature enough as to handle it [and I hope so :)]. That's the only way
to fully control a program's flow. Libraries should not dictate what
to do on error [I'm sure I'm not telling you anything new].
The changes to make stl_alloc work ok with exceptions are:
diff -uN /usr/include/g\+\+-3/stl_alloc.h\~ /usr/include/g\+\+-3/stl_alloc.h
--- /usr/include/g++-3/stl_alloc.h~ Fri May 7 12:13:28 1999
+++ /usr/include/g++-3/stl_alloc.h Sat Aug 7 04:16:22 1999
@@ -38,7 +38,7 @@
// The allocation primitives are intended to allocate individual objects,
// not larger arenas as with the original STL allocators.
-#if 0
+#if 1
# include <new>
# define __THROW_BAD_ALLOC throw bad_alloc()
#elif !defined(__THROW_BAD_ALLOC)
Thanks, anyway, for such nice packages for GCC & Co.
Your happy Debian user,
-- System Information
Debian Release: potato
Kernel Version: Linux jovian 2.2.7 #1 mar ago 3 02:24:40 CEST 1999 i586 unknown
Versions of the packages libstdc++2.10-dev depends on:
ii g++ 2.95-2 The GNU C++ compiler.
ii libc6-dev 2.1.2-0pre4 GNU C Library: Development libraries and hea
ii libstdc++2.10 2.95-2 The GNU stdc++ library
Reply sent to Matthias Klose <doko@cs.tu-berlin.de>:
You have marked bug as forwarded.
(full text, mbox, link).
Message #8 received at 42622-forwarded@bugs.debian.org (full text, mbox, reply):
[This bug/behaviour was reported to me as a co-maintainer of the
Debian GNU/Linux GCC packages. Please Cc: 42622@bugs.debian.org in
your response so it gets archived in the Debian bugtracking system
(http://www.debian.org/Bugs/db/42/42622.html).]
While coding some proof-of-concepts I've come around using a
vector<> of a big lot of elements. Wanted to push the limits and try
to recover possible failures. No way. The program was aborting on the
library's own.
That should not do. You want exceptions to be able to dictate
how the program should behave on error situations. The thing is at
stl_alloc.h, instead of throwing an exception on OOM, it was printing
the message "out of memory" to stderr and aborting. It is also
prepared for doing it via exceptions, so I think it should be the
default way.
I think that behaviour should be made extensible to the whole
libstdc++ library, as as far as I know, exception support in GCC is
mature enough as to handle it [and I hope so :)]. That's the only way
to fully control a program's flow. Libraries should not dictate what
to do on error [I'm sure I'm not telling you anything new].
The changes to make stl_alloc work ok with exceptions are:
diff -uN /usr/include/g\+\+-3/stl_alloc.h\~ /usr/include/g\+\+-3/stl_alloc.h
--- /usr/include/g++-3/stl_alloc.h~ Fri May 7 12:13:28 1999
+++ /usr/include/g++-3/stl_alloc.h Sat Aug 7 04:16:22 1999
@@ -38,7 +38,7 @@
// The allocation primitives are intended to allocate individual objects,
// not larger arenas as with the original STL allocators.
-#if 0
+#if 1
# include <new>
# define __THROW_BAD_ALLOC throw bad_alloc()
#elif !defined(__THROW_BAD_ALLOC)
Thanks, anyway, for such nice packages for GCC & Co.
Your happy Debian user,
Message #9 received at 42622-forwarded@bugs.debian.org (full text, mbox, reply):
That is really weird -- I thought the standard specified that it should be
throwing bad_alloc.
-Kip
On Sun, 8 Aug 1999, Matthias Klose wrote:
> [This bug/behaviour was reported to me as a co-maintainer of the
> Debian GNU/Linux GCC packages. Please Cc: 42622@bugs.debian.org in
> your response so it gets archived in the Debian bugtracking system
> (http://www.debian.org/Bugs/db/42/42622.html).]
>
>
> While coding some proof-of-concepts I've come around using a
> vector<> of a big lot of elements. Wanted to push the limits and try
> to recover possible failures. No way. The program was aborting on the
> library's own.
>
> That should not do. You want exceptions to be able to dictate
> how the program should behave on error situations. The thing is at
> stl_alloc.h, instead of throwing an exception on OOM, it was printing
> the message "out of memory" to stderr and aborting. It is also
> prepared for doing it via exceptions, so I think it should be the
> default way.
>
> I think that behaviour should be made extensible to the whole
> libstdc++ library, as as far as I know, exception support in GCC is
> mature enough as to handle it [and I hope so :)]. That's the only way
> to fully control a program's flow. Libraries should not dictate what
> to do on error [I'm sure I'm not telling you anything new].
>
> The changes to make stl_alloc work ok with exceptions are:
>
> diff -uN /usr/include/g\+\+-3/stl_alloc.h\~ /usr/include/g\+\+-3/stl_alloc.h
> --- /usr/include/g++-3/stl_alloc.h~ Fri May 7 12:13:28 1999
> +++ /usr/include/g++-3/stl_alloc.h Sat Aug 7 04:16:22 1999
> @@ -38,7 +38,7 @@
> // The allocation primitives are intended to allocate individual objects,
> // not larger arenas as with the original STL allocators.
>
> -#if 0
> +#if 1
> # include <new>
> # define __THROW_BAD_ALLOC throw bad_alloc()
> #elif !defined(__THROW_BAD_ALLOC)
>
> Thanks, anyway, for such nice packages for GCC & Co.
>
> Your happy Debian user,
>
>
Message #10 received at 42622-forwarded@bugs.debian.org (full text, mbox, reply):
Please correct me if I am wrong, I'm trying to remember back quite a way.
I believe this is because the exception mechanism needs to allocate memory
in order to throw an exception the way gcc handles exceptions. Since it
is already out of memory, trying to allocate more memory probably isn't
a good idea.
I seem to remember some mail in the past regarding this situation.
/Mike
>
> That is really weird -- I thought the standard specified that it should be
> throwing bad_alloc.
> -Kip
>
>
>
> On Sun, 8 Aug 1999, Matthias Klose wrote:
>
> > [This bug/behaviour was reported to me as a co-maintainer of the
> > Debian GNU/Linux GCC packages. Please Cc: 42622@bugs.debian.org in
> > your response so it gets archived in the Debian bugtracking system
> > (http://www.debian.org/Bugs/db/42/42622.html).]
> >
> >
> > While coding some proof-of-concepts I've come around using a
> > vector<> of a big lot of elements. Wanted to push the limits and try
> > to recover possible failures. No way. The program was aborting on the
> > library's own.
> >
> > That should not do. You want exceptions to be able to dictate
> > how the program should behave on error situations. The thing is at
> > stl_alloc.h, instead of throwing an exception on OOM, it was printing
> > the message "out of memory" to stderr and aborting. It is also
> > prepared for doing it via exceptions, so I think it should be the
> > default way.
> >
> > I think that behaviour should be made extensible to the whole
> > libstdc++ library, as as far as I know, exception support in GCC is
> > mature enough as to handle it [and I hope so :)]. That's the only way
> > to fully control a program's flow. Libraries should not dictate what
> > to do on error [I'm sure I'm not telling you anything new].
> >
> > The changes to make stl_alloc work ok with exceptions are:
> >
> > diff -uN /usr/include/g\+\+-3/stl_alloc.h\~ /usr/include/g\+\+-3/stl_alloc.h
> > --- /usr/include/g++-3/stl_alloc.h~ Fri May 7 12:13:28 1999
> > +++ /usr/include/g++-3/stl_alloc.h Sat Aug 7 04:16:22 1999
> > @@ -38,7 +38,7 @@
> > // The allocation primitives are intended to allocate individual objects,
> > // not larger arenas as with the original STL allocators.
> >
> > -#if 0
> > +#if 1
> > # include <new>
> > # define __THROW_BAD_ALLOC throw bad_alloc()
> > #elif !defined(__THROW_BAD_ALLOC)
> >
> > Thanks, anyway, for such nice packages for GCC & Co.
> >
> > Your happy Debian user,
> >
> >
>
>
>
Message #11 received at 42622-forwarded@bugs.debian.org (full text, mbox, reply):
That is always the conundrum of dealing with exceptions.
-Kip
On Sun, 8 Aug 1999, Mike Harrold wrote:
> Please correct me if I am wrong, I'm trying to remember back quite a way.
> I believe this is because the exception mechanism needs to allocate memory
> in order to throw an exception the way gcc handles exceptions. Since it
> is already out of memory, trying to allocate more memory probably isn't
> a good idea.
>
> I seem to remember some mail in the past regarding this situation.
>
> /Mike
>
> >
> > That is really weird -- I thought the standard specified that it should be
> > throwing bad_alloc.
> > -Kip
> >
> >
> >
> > On Sun, 8 Aug 1999, Matthias Klose wrote:
> >
> > > [This bug/behaviour was reported to me as a co-maintainer of the
> > > Debian GNU/Linux GCC packages. Please Cc: 42622@bugs.debian.org in
> > > your response so it gets archived in the Debian bugtracking system
> > > (http://www.debian.org/Bugs/db/42/42622.html).]
> > >
> > >
> > > While coding some proof-of-concepts I've come around using a
> > > vector<> of a big lot of elements. Wanted to push the limits and try
> > > to recover possible failures. No way. The program was aborting on the
> > > library's own.
> > >
> > > That should not do. You want exceptions to be able to dictate
> > > how the program should behave on error situations. The thing is at
> > > stl_alloc.h, instead of throwing an exception on OOM, it was printing
> > > the message "out of memory" to stderr and aborting. It is also
> > > prepared for doing it via exceptions, so I think it should be the
> > > default way.
> > >
> > > I think that behaviour should be made extensible to the whole
> > > libstdc++ library, as as far as I know, exception support in GCC is
> > > mature enough as to handle it [and I hope so :)]. That's the only way
> > > to fully control a program's flow. Libraries should not dictate what
> > > to do on error [I'm sure I'm not telling you anything new].
> > >
> > > The changes to make stl_alloc work ok with exceptions are:
> > >
> > > diff -uN /usr/include/g\+\+-3/stl_alloc.h\~ /usr/include/g\+\+-3/stl_alloc.h
> > > --- /usr/include/g++-3/stl_alloc.h~ Fri May 7 12:13:28 1999
> > > +++ /usr/include/g++-3/stl_alloc.h Sat Aug 7 04:16:22 1999
> > > @@ -38,7 +38,7 @@
> > > // The allocation primitives are intended to allocate individual objects,
> > > // not larger arenas as with the original STL allocators.
> > >
> > > -#if 0
> > > +#if 1
> > > # include <new>
> > > # define __THROW_BAD_ALLOC throw bad_alloc()
> > > #elif !defined(__THROW_BAD_ALLOC)
> > >
> > > Thanks, anyway, for such nice packages for GCC & Co.
> > >
> > > Your happy Debian user,
> > >
> > >
> >
> >
> >
>
>
>
Message #12 received at 42622-forwarded@bugs.debian.org (full text, mbox, reply):
> Please correct me if I am wrong, I'm trying to remember back quite a way.
> I believe this is because the exception mechanism needs to allocate memory
> in order to throw an exception the way gcc handles exceptions. Since it
> is already out of memory, trying to allocate more memory probably isn't
> a good idea.
>
> I seem to remember some mail in the past regarding this situation.
What you remember might have been a slightly different situation:
Whether ::operator new would properly throw an exception or not. There
was indeed the problem whether it could throw, and I believe with gcc
2.95, it can.
Section 20.4.1 clearly states that the default allocator must throw
bad_alloc. The #if 0 around BAD_ALLOC appears in the originial sources
of SGI STL 3.11, most likely because not all compilers have a
conforming <new>. In STL 3.2, this is a configurable option.
Regards,
Martin
Message #13 received at 42622-forwarded@bugs.debian.org (full text, mbox, reply):
> From: Matthias Klose <doko@cs.tu-berlin.de>
> Date: Sun, 8 Aug 1999 20:46:33 +0200 (MET DST)
> To: gcc-bugs@gcc.gnu.org
> CC: inaky@peloncho.fis.ucm.es, 42622-forwarded@bugs.debian.org
> The changes to make stl_alloc work ok with exceptions are:
> diff -uN /usr/include/g\+\+-3/stl_alloc.h\~ /usr/include/g\+\+-3/stl_alloc.h
> --- /usr/include/g++-3/stl_alloc.h~ Fri May 7 12:13:28 1999
> +++ /usr/include/g++-3/stl_alloc.h Sat Aug 7 04:16:22 1999
> @@ -38,7 +38,7 @@
> // The allocation primitives are intended to allocate individual objects,
> // not larger arenas as with the original STL allocators.
>
> -#if 0
> +#if 1
> # include <new>
> # define __THROW_BAD_ALLOC throw bad_alloc()
> #elif !defined(__THROW_BAD_ALLOC)
We do this here... We did it for our last release as I recall.
Severity set to `fixed'.
Request was from Matthias Klose <doko@debian.org>
to control@bugs.debian.org.
(full text, mbox, link).
Reply sent to Matthias Klose <doko@cs.tu-berlin.de>:
You have taken responsibility.
(full text, mbox, link).
Notification sent to inaky@peloncho.fis.ucm.es:
Bug acknowledged by developer.
(full text, mbox, link).
Message #20 received at 42622-done@bugs.debian.org (full text, mbox, reply):
These bugs are fixed in the gcc-2.95.1-0pre1 and related g++,
libstdc++, cpp packages. Binary packages are currently uploaded for
the i386-hurd architecture.
Send a report that this bug log contains spam.
Debian bug tracking system administrator <owner@bugs.debian.org>.
Last modified:
Mon May 6 03:27:45 2024;
Machine Name:
buxtehude
Debian Bug tracking system
Debbugs is free software and licensed under the terms of the GNU
Public License version 2. The current version can be obtained
from https://bugs.debian.org/debbugs-source/.
Copyright © 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson,
2005-2017 Don Armstrong, and many other contributors.