[Bug libstdc++/64535] New: Emergency buffer for exception allocation too small

[Bug libstdc++/64535] New: Emergency buffer for exception allocation too small

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64535

            Bug ID: 64535
           Summary: Emergency buffer for exception allocation too small
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: rguenth at gcc dot gnu.org

It was reported to us that in a heavily threaded environment the number of
emergency EH objects in libsubc++ eh_alloc.cc is too small (64).  To mitigate
this it looks like we could use a TLS variable for the buffer instead
(libstdc++ already contains TLS variables for __once_call at least), which
also would get rid of the scoped lock (which hopefully will never allocate
memory...?).

If you use exceptions to catch and recover from low-memory situations
__cxa_allocate_exception calling std::terminate () becomes a correctness
issue (not sure what the C++ standard says about throwing exceptions
in low-memory situations).

[Bug libstdc++/64535] Emergency buffer for exception allocation too small

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64535

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
It was pointed out that the pool is very large (even if reduced to 4 entries)
and thus undesirable for TLS (would be 4k then).

An alternative is to use a free list with variable size objects, initialized
to just a single one of the emergency buffer size.  You'd split the entry
you pop off and only use a small portion of it (freeing would need to support
merging and keeping the list sorted).

Fragmentation might be an issue then, but for the case in question which
is throwing std::bad_alloc (much smaller than 1024 bytes) it might increase
the effective number of available objects enough.

[Bug libstdc++/64535] Emergency buffer for exception allocation too small

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64535

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
Also exceptions larger than std::bad_alloc should not eat from the emergency
buffer but instead cause std::bad_alloc to be thrown?  Thus EMERGENCY_OBJ_SIZE
could be very much smaller.

[Bug libstdc++/64535] Emergency buffer for exception allocation too small

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64535

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
Seeing that we have EH reference counted makes me think we should simply have
a single global std::bad_alloc EH to re-use?

[Bug libstdc++/64535] Emergency buffer for exception allocation too small

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64535

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
Is the following required to work?

#include <exception>
#include <new>
#include <sys/resource.h>

struct large
{
  char s[1024*1024*1024];
};

int main()
{
  rlimit lim;
  lim.rlim_cur = 1024*1024*1024;
  lim.rlim_max = 1024*1024*1024;
  setrlimit (RLIMIT_AS, &lim);
  try {
      throw large ();
  } catch (large&) {
  } catch (std::bad_alloc) {
  }
}

I get

> ./a.out 
terminate called without an active exception
Aborted

[Bug libstdc++/64535] Emergency buffer for exception allocation too small

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64535

--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
Created attachment 34399
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34399&action=edit
patch fixing comment #4

This fixes the issue in comment #4 (it also decreases the emergency EH object
size).

[Bug libstdc++/64535] Emergency buffer for exception allocation too small

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64535

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Note that the emergency buffer should not be in TLS, because if some thread
throws, that exception is saved using std::exception_ptr to be rethrown to
another thread, then the original thread exits, the exception would be gone.

[Bug libstdc++/64535] Emergency buffer for exception allocation too small

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64535

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jason at gcc dot gnu.org

--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #5)
> Created attachment 34399 [details]
> patch fixing comment #4
> 
> This fixes the issue in comment #4 (it also decreases the emergency EH
> object size).

Note that raising std::bad_alloc from __cxa_allocate_exception looks like
an ABI change as that function is declared throw().  Which means that
shrinking the exceptional object size makes more cases non-conforming
(if the testcase in comment #4 is supposed to work).  Not shrinking the
exceptional object size makes increasing the number of exceptional objects
less of a non-brainer :/  The C++ FE declares the functions ECF_NOTHROW,
so I wonder how my patch ended up fixing the testcase...

[Bug libstdc++/64535] Emergency buffer for exception allocation too small

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64535

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #34399|0                           |1
        is obsolete|                            |
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2015-01-12
           Assignee|unassigned at gcc dot gnu.org      |rguenth at gcc dot gnu.org
     Ever confirmed|0                           |1

--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> ---
Created attachment 34418
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34418&action=edit
prototype of a variable-size emergency allocator

The attached patch implements a new fixed-size arena, variable size object
allocator and uses it for the emergency pool (not yet for the dependent
exception allocations, but trivial to change those).

I welcome libstdc++ coding style issues pointed out and general comments
on whether this approach is fine (also unifying the dependent allocations
in here).

TODO: implement free-list sorting and merging of free-list entries

Sofar tested by forcing the use of the emergency allocator (as in the patch,
see #if 1) by bootstrapping and testing C++ (hopefully sorted out a last issue,
test re-running).

[Bug libstdc++/64535] Emergency buffer for exception allocation too small

[rguenther at suse dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64535

--- Comment #10 from rguenther at suse dot de <rguenther at suse dot de> ---
On Mon, 12 Jan 2015, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64535
> 
> --- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
> If all allocations from the emergency pool are at least
> sizeof(__cxa_refcounted_exception) long (or what is the minimum), then trying
> to split the memory into smaller chunks (down to sizeof(free_entry)) might be
> counter-productive.

Maybe, it's not 100% clear to me as the small remains could be merged with
a released entry to an even larger one.  That said, I tried to make
the allocation class generic enough for re-use, but adding a
min_free_size const is certainly possible (template parameters for
arena size and minimum free list element size).

If re-testing finishes successfully I'll give the sorting and merging
a stab, shouldn't be too difficult.

[Bug libstdc++/64535] Emergency buffer for exception allocation too small

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64535

--- Comment #11 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #4)
> Is the following required to work?
> 
> #include <exception>
> #include <new>
> #include <sys/resource.h>
> 
> struct large
> {
>   char s[1024*1024*1024];
> };
> 
> int main()
> {
>   rlimit lim;
>   lim.rlim_cur = 1024*1024*1024;
>   lim.rlim_max = 1024*1024*1024;
>   setrlimit (RLIMIT_AS, &lim);
>   try {
>       throw large ();
>   } catch (large&) {
>   } catch (std::bad_alloc) {
>   }
> }
> 
> I get
> 
> > ./a.out 
> terminate called without an active exception
> Aborted

If reading 15.1.4 (Exception Handling / Throwing an exception) correctly
then allocation happens in an unspecified way but according to 3.7.3.1
which specifies that if "the allocation function" that fails to allocate
storage shall throw std::bad_alloc (if not marked with throw ()).  But
it isn't specified if the "unspecified" EH allocation "function" is
marked with throw ().

In particular 15.5.1 (The std::terminate function) doesn't list OOM
in allocating an exception as cause of abandoning exception handling.

It would be nice to get clarification from the standards body on what
shall happen if EH allocation runs into OOM situations.

[Bug libstdc++/64535] Emergency buffer for exception allocation too small

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64535

--- Comment #12 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #11)
> If reading 15.1.4 (Exception Handling / Throwing an exception) correctly
> then allocation happens in an unspecified way but according to 3.7.3.1
> which specifies that if "the allocation function" that fails to allocate
> storage shall throw std::bad_alloc (if not marked with throw ()).  But
> it isn't specified if the "unspecified" EH allocation "function" is
> marked with throw ().

An "allocation function" specifically refers to an overload of operator new.

The reference from 15.1.4 [except.throw] to [basic.stc.dynamic.allocation] is
apparently meant to refer to the final paragraph, which says: "[ Note: In
particular, a global allocation function is not called to allocate storage for
[...] an exception object (15.1). — end note ]" so it's saying that operator
new must not be used to allocate memory for exceptions (but it's OK to use
malloc or a static buffer or both). That means the rules for how operator new
indicates OOM are not relevant for exception handling.

> In particular 15.5.1 (The std::terminate function) doesn't list OOM
> in allocating an exception as cause of abandoning exception handling.
> 
> It would be nice to get clarification from the standards body on what
> shall happen if EH allocation runs into OOM situations.

Undefined behaviour.
>From gcc-bugs-return-474196-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Jan 21 11:20:37 2015
Return-Path: <gcc-bugs-return-474196-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 9306 invoked by alias); 21 Jan 2015 11:20:36 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 9234 invoked by uid 48); 21 Jan 2015 11:20:29 -0000
From: "vries at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libgomp/64707] New: FAIL: libgomp.c/target-9.c with -ftree-parallelize-loops=0
Date: Wed, 21 Jan 2015 11:20:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: libgomp
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: vries at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter cc
Message-ID: <bug-64707-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-01/txt/msg02190.txt.bz2
Content-length: 2909

https://gcc.gnu.org/bugzilla/show_bug.cgi?idd707

            Bug ID: 64707
           Summary: FAIL: libgomp.c/target-9.c with
                    -ftree-parallelize-loops=0
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libgomp
          Assignee: unassigned at gcc dot gnu.org
          Reporter: vries at gcc dot gnu.org
                CC: jakub at gcc dot gnu.org

When running libgomp testsuite with
--target_board=unix/-ftree-parallelize-loops=0, we run into this failure:
...
FAIL: libgomp.c/target-9.c (internal compiler error)
FAIL: libgomp.c/target-9.c (test for excess errors)
UNRESOLVED: libgomp.c/target-9.c compilation failed to produce executable
...

More specifically:
...
lto1: internal compiler error: in streamer_get_builtin_tree, at
tree-streamer-in.c:1151^M
0xfea939 streamer_get_builtin_tree(lto_input_block*, data_in*)^M
        /home/vries/gcc_versions/devel/master/src/gcc/tree-streamer-in.c:1151^M
0xb579f3 lto_input_tree_1(lto_input_block*, data_in*, LTO_tags, unsigned int)^M
        /home/vries/gcc_versions/devel/master/src/gcc/lto-streamer-in.c:1320^M
0xb577ba lto_input_scc(lto_input_block*, data_in*, unsigned int*, unsigned
int*)^M
        /home/vries/gcc_versions/devel/master/src/gcc/lto-streamer-in.c:1248^M
0x6a8238 lto_read_decls^M
        /home/vries/gcc_versions/devel/master/src/gcc/lto/lto.c:1900^M
0x6a8efa lto_file_finalize^M
        /home/vries/gcc_versions/devel/master/src/gcc/lto/lto.c:2229^M
0x6a8f47 lto_create_files_from_ids^M
        /home/vries/gcc_versions/devel/master/src/gcc/lto/lto.c:2239^M
0x6a906e lto_file_read^M
        /home/vries/gcc_versions/devel/master/src/gcc/lto/lto.c:2280^M
0x6ac807 read_cgraph_and_symbols^M
        /home/vries/gcc_versions/devel/master/src/gcc/lto/lto.c:2981^M
0x6ad803 lto_main()^M
        /home/vries/gcc_versions/devel/master/src/gcc/lto/lto.c:3436^M
Please submit a full bug report,^M
...

Investigating the ICE site:
...
(gdb)
#5  0x0000000000fea93a in streamer_get_builtin_tree (ib=0x7fffffffd860,
data_in=0x2ea2390)
    at /home/vries/gcc_versions/devel/master/src/gcc/tree-streamer-in.c:1151
1151          gcc_assert (result);
(gdb) l
1146        {
1147          fcode = (enum built_in_function) (fcode - BEGIN_CHKP_BUILTINS -
1);
1148          result = builtin_decl_explicit (fcode);
1149          result = chkp_maybe_clone_builtin_fndecl (result);
1150        }
1151          gcc_assert (result);
1152        }
1153      else if (fclass == BUILT_IN_MD)
1154        {
1155          result = targetm.builtin_decl (fcode, true);
(gdb) p fcode
$1 = BUILT_IN_GOMP_TARGET
(gdb) p builtin_info
builtin_info       builtin_info_type
(gdb) p builtin_info.decl[BUILT_IN_GOMP_TARGET]
$3 = (tree_node *) 0x0
...

The omp builtin is not enabled in lto1 (consistent with the observation in PR
64672 comment 9).

[Bug libstdc++/64535] Emergency buffer for exception allocation too small

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64535

--- Comment #13 from Richard Biener <rguenth at gcc dot gnu.org> ---
Author: rguenth
Date: Thu Jan 22 09:21:48 2015
New Revision: 219988

URL: https://gcc.gnu.org/viewcvs?rev=219988&root=gcc&view=rev
Log:
2015-01-22  Richard Biener  <rguenther@suse.de>

    PR libstdc++/64535
    * libsupc++/eh_alloc.cc: Include new.
    (bitmask_type): Remove.
    (one_buffer): Likewise.
    (emergency_buffer): Likewise.
    (emergency_used): Likewise.
    (dependents_buffer): Likewise.
    (dependents_used): Likewise.
    (class pool): New custom fixed-size arena, variable size object
    allocator.
    (emergency_pool): New global.
    (__cxxabiv1::__cxa_allocate_exception): Use new emergency_pool.
    (__cxxabiv1::__cxa_free_exception): Likewise.
    (__cxxabiv1::__cxa_allocate_dependent_exception): Likewise.
    (__cxxabiv1::__cxa_free_dependent_exception): Likewise.

    * g++.old-deja/g++.eh/badalloc1.C: Adjust.

Modified:
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/g++.old-deja/g++.eh/badalloc1.C
    trunk/libstdc++-v3/ChangeLog
    trunk/libstdc++-v3/libsupc++/eh_alloc.cc

[Bug libstdc++/64535] Emergency buffer for exception allocation too small

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64535

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
      Known to work|                            |5.0
         Resolution|---                         |FIXED

--- Comment #14 from Richard Biener <rguenth at gcc dot gnu.org> ---
Ok, somewhat mitigated by the new allocator in GCC 5.

[Bug libstdc++/64535] Emergency buffer for exception allocation too small

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64535

--- Comment #15 from Jonathan Wakely <redi at gcc dot gnu.org> ---
I think we need to get a suppression into valgrind:

==21268== Memcheck, a memory error detector
==21268== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==21268== Using Valgrind-3.9.0 and LibVEX; rerun with -h for copyright info
==21268== Command: ./a.out
==21268== 
==21268== 
==21268== HEAP SUMMARY:
==21268==     in use at exit: 72,704 bytes in 1 blocks
==21268==   total heap usage: 5,747 allocs, 5,746 frees, 822,784 bytes
allocated
==21268== 
==21268== 72,704 bytes in 1 blocks are still reachable in loss record 1 of 1
==21268==    at 0x4A0645D: malloc (vg_replace_malloc.c:291)
==21268==    by 0x4C990FF: _GLOBAL__sub_I_eh_alloc.cc (eh_alloc.cc:117)
==21268==    by 0x394940F2D9: call_init.part.0 (dl-init.c:82)
==21268==    by 0x394940F3C2: _dl_init (dl-init.c:34)
==21268==    by 0x3949401229: ??? (in /usr/lib64/ld-2.18.so)
==21268== 
==21268== LEAK SUMMARY:
==21268==    definitely lost: 0 bytes in 0 blocks
==21268==    indirectly lost: 0 bytes in 0 blocks
==21268==      possibly lost: 0 bytes in 0 blocks
==21268==    still reachable: 72,704 bytes in 1 blocks
==21268==         suppressed: 0 bytes in 0 blocks
==21268== 
==21268== For counts of detected and suppressed errors, rerun with: -v
==21268== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 2)

[Bug libstdc++/64535] Emergency buffer for exception allocation too small

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64535

--- Comment #16 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #15)
> I think we need to get a suppression into valgrind:
> 
> ==21268== Memcheck, a memory error detector
> ==21268== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
> ==21268== Using Valgrind-3.9.0 and LibVEX; rerun with -h for copyright info
> ==21268== Command: ./a.out
> ==21268== 
> ==21268== 
> ==21268== HEAP SUMMARY:
> ==21268==     in use at exit: 72,704 bytes in 1 blocks
> ==21268==   total heap usage: 5,747 allocs, 5,746 frees, 822,784 bytes
> allocated
> ==21268== 
> ==21268== 72,704 bytes in 1 blocks are still reachable in loss record 1 of 1
> ==21268==    at 0x4A0645D: malloc (vg_replace_malloc.c:291)
> ==21268==    by 0x4C990FF: _GLOBAL__sub_I_eh_alloc.cc (eh_alloc.cc:117)
> ==21268==    by 0x394940F2D9: call_init.part.0 (dl-init.c:82)
> ==21268==    by 0x394940F3C2: _dl_init (dl-init.c:34)
> ==21268==    by 0x3949401229: ??? (in /usr/lib64/ld-2.18.so)
> ==21268== 
> ==21268== LEAK SUMMARY:
> ==21268==    definitely lost: 0 bytes in 0 blocks
> ==21268==    indirectly lost: 0 bytes in 0 blocks
> ==21268==      possibly lost: 0 bytes in 0 blocks
> ==21268==    still reachable: 72,704 bytes in 1 blocks
> ==21268==         suppressed: 0 bytes in 0 blocks
> ==21268== 
> ==21268== For counts of detected and suppressed errors, rerun with: -v
> ==21268== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 2)

Or add a destructor.

Index: libstdc++-v3/libsupc++/eh_alloc.cc
===================================================================
--- libstdc++-v3/libsupc++/eh_alloc.cc  (revision 220160)
+++ libstdc++-v3/libsupc++/eh_alloc.cc  (working copy)
@@ -81,6 +81,7 @@ namespace
     {
     public:
       pool();
+      ~pool();

       void *allocate (std::size_t);
       void free (void *);
@@ -240,6 +242,11 @@ namespace
              && p < arena + arena_size);
     }

+  pool::~pool ()
+    {
+      free (arena);
+    }
+
   pool emergency_pool;
 }

[Bug libstdc++/64535] Emergency buffer for exception allocation too small

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64535

--- Comment #17 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Ah, I assumed the lack of destructor was intentional, so we can still deal with
exceptions while destroying globals. Otherwise an exception could try to
allocate from the pool after the destructor has run.

[Bug libstdc++/64535] Emergency buffer for exception allocation too small

[rguenther at suse dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64535

--- Comment #18 from rguenther at suse dot de <rguenther at suse dot de> ---
On Tue, 27 Jan 2015, redi at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64535
> 
> --- Comment #17 from Jonathan Wakely <redi at gcc dot gnu.org> --- Ah, I 
> assumed the lack of destructor was intentional, so we can still deal 
> with exceptions while destroying globals. Otherwise an exception could 
> try to allocate from the pool after the destructor has run.

Well - technically accessing emergency_pool after its default destructor
ran is undefined (though we don't seem to run any destructor on it...
I wonder if we do for __scoped_lock and if that works).

I hope that initialization/destruction order imposed by some means
allows EH to be thrown during initialization or destruction (though
what would catch that?)

We can make the patch safer by using

  pool::~pool ()
    {
      __gnu_cxx::__scoped_lock sentry(emergency_mutex);
      free (arena);
      arena = NULL;
    }

and/or by attaching a init_priority to the class.

But again - where can you catch exceptions thrown from global
initializers / destructors?  If I throw from a __thread global
constructor will the parent process be able to catch that exception
somehow?

[Bug libstdc++/64535] Emergency buffer for exception allocation too small

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64535

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mark at gcc dot gnu.org

--- Comment #19 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I think a destructor is too risky here.
Can't you just register with valgrind a pointer known not to be freed at exit?
Would be nice to have something like __libc_freeres for libstdc++ too, that
valgrind/mtrace/LeakSanitizer could invoke.
I'm afraid tons of programs just do busy work in various threads until some
thread exits the whole app, and your change could break it.

[Bug libstdc++/64535] Emergency buffer for exception allocation too small

[rguenther at suse dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64535

--- Comment #20 from rguenther at suse dot de <rguenther at suse dot de> ---
On Tue, 27 Jan 2015, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64535
> 
> Jakub Jelinek <jakub at gcc dot gnu.org> changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                  CC|                            |mark at gcc dot gnu.org
> 
> --- Comment #19 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
> I think a destructor is too risky here.
> Can't you just register with valgrind a pointer known not to be freed at exit?
> Would be nice to have something like __libc_freeres for libstdc++ too, that
> valgrind/mtrace/LeakSanitizer could invoke.
> I'm afraid tons of programs just do busy work in various threads until some
> thread exits the whole app, and your change could break it.

It indeed would free memory of in-flight exceptions.  Which means that
process termination in OOM situations might become interesting?

OTOH we now leak with dlopen/dlclose of libstdc++.so (just consider
doing that multiple times).

[Bug libstdc++/64535] Emergency buffer for exception allocation too small

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64535

--- Comment #21 from Richard Biener <rguenth at gcc dot gnu.org> ---
We can make it extra-safe but still deallocate in most common cases:

  pool::~pool ()
    {
      __gnu_cxx::__scoped_lock sentry(emergency_mutex);
      if (arena
          && arena == reinterpret_cast <char *> (first_free_entry)
          && arena_size == first_free_entry->size)
        {
          free (arena);
          arena = NULL;
          first_free_entry = NULL;
        }
    }

this ensures threads won't continue allocating from the pool.  Well,
they may in case some other thread frees some exception...  So indeed
running a destructor makes the whole stuff undefined (object lifetime
of the pool ended) :/

[Bug libstdc++/64535] Emergency buffer for exception allocation too small

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64535

--- Comment #22 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Can't you use a .bss object for the initial case, so you don't malloc anything
in the ctor unless user requests something larger than that?
That way "freeing" that would be handled in most cases.  And I assume you
really can't dlclose libstdc++ while other threads are handling exceptions,
because then those libraries should use libstdc++ entry points and either would
need to be dlclosed too, or libstdc++ wouldn't be really unmapped.

[Bug libstdc++/64535] Emergency buffer for exception allocation too small

[rguenther at suse dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64535

--- Comment #23 from rguenther at suse dot de <rguenther at suse dot de> ---
On Tue, 27 Jan 2015, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64535
> 
> --- Comment #22 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
> Can't you use a .bss object for the initial case, so you don't malloc anything
> in the ctor unless user requests something larger than that?

Is there a non-zeroed .bss section?  I think using dynamically allocated
memory might be cheaper.

But sure - it was a .bss object previously (four actually).

> That way "freeing" that would be handled in most cases.  And I assume you
> really can't dlclose libstdc++ while other threads are handling exceptions,
> because then those libraries should use libstdc++ entry points and either would
> need to be dlclosed too, or libstdc++ wouldn't be really unmapped.

Ok, so what's the real issue then with the destructor?  Don't we destroy
the global IO and locale stuff as well?

[Bug libstdc++/64535] Emergency buffer for exception allocation too small

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64535

--- Comment #24 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to rguenther@suse.de from comment #23)
> Is there a non-zeroed .bss section?

No.

> I think using dynamically allocated
> memory might be cheaper.

I very much doubt it.

> > That way "freeing" that would be handled in most cases.  And I assume you
> > really can't dlclose libstdc++ while other threads are handling exceptions,
> > because then those libraries should use libstdc++ entry points and either would
> > need to be dlclosed too, or libstdc++ wouldn't be really unmapped.
> 
> Ok, so what's the real issue then with the destructor?  Don't we destroy
> the global IO and locale stuff as well?

IO destruction is a huge can of worms, just look at some of the interesting
glibc bugs.  It is an area which is essentially unsolvable.
Most other stuff isn't destructed by glibc at all, there is __libc_freeres
exactly to make valgrind/mtrace etc. happy, but still not free otherwise.

[Bug libstdc++/64535] Emergency buffer for exception allocation too small

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64535

--- Comment #25 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to rguenther@suse.de from comment #18)
> But again - where can you catch exceptions thrown from global
> initializers / destructors?

Within those global constructors/destructors themselves:

struct Global {
  ~Global() {
    try {
      throw 1;
    } catch (...) {
    }
  }
} global;

Anyway, we should probably use an init_priority for the pool, because as well
as an order of destruction problem it's possible for a global constructor to
try to use the pool, and that must not happen before it has been initialized by
the constructor.

[Bug libstdc++/64535] Emergency buffer for exception allocation too small

[rguenther at suse dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64535

--- Comment #26 from rguenther at suse dot de <rguenther at suse dot de> ---
On Tue, 27 Jan 2015, redi at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64535
> 
> --- Comment #25 from Jonathan Wakely <redi at gcc dot gnu.org> ---
> (In reply to rguenther@suse.de from comment #18)
> > But again - where can you catch exceptions thrown from global
> > initializers / destructors?
> 
> Within those global constructors/destructors themselves:
> 
> struct Global {
>   ~Global() {
>     try {
>       throw 1;
>     } catch (...) {
>     }
>   }
> } global;
> 
> Anyway, we should probably use an init_priority for the pool, because as well
> as an order of destruction problem it's possible for a global constructor to
> try to use the pool, and that must not happen before it has been initialized by
> the constructor.

Of course that's broken in older releases as well because of the
emergency_mutex being dynamically constructed.

[Bug libstdc++/64535] Emergency buffer for exception allocation too small

[dumoulin.thibaut at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64535

Thibaut M. <dumoulin.thibaut at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dumoulin.thibaut at gmail dot com

--- Comment #27 from Thibaut M. <dumoulin.thibaut at gmail dot com> ---
With this patch, a global variable is declared and `malloc` is called in its
constructor.

Linking libstdc++ will automatically allocate at least 2528 bytes on the heap.
Since this library is also used in embedded software, this is a problem, 2,5ko
represent a lot of memory (when you have only 4ko available for example). A
temporary solution would be to call the freeres() function but better solution
would be to do not allocate at all.

Second problem with this commit: the constructor of the global variable `pool
emergency_pool` must be call at run time due to `malloc` and `new` functions.
Even if this code is not used, the linker script will put the constructor in
`.init_array` section. Linker cannot get rid of this constructor due to
non-pure functions called.

A patch could be a least to avoid this `malloc` with some `#define` options?

Or maybe you know a solution to avoid those problems?

[Bug libstdc++/64535] Emergency buffer for exception allocation too small

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64535

--- Comment #28 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Thibaut M. from comment #27)
> A patch could be a least to avoid this `malloc` with some `#define` options?

That discussion belongs in PR 68606.