[Bug libstdc++/40606] New: Inside new_handler "throw;" operator may cause abort

[Bug libstdc++/40606] New: Inside new_handler "throw;" operator may cause abort

[tsyvarev at ispras dot ru]

The attached example causes abort() on SLES11 (IA64).

This example comes from a test suite that checks operator new in various
situations. According to the execution results of these tests, it seems to me
that the problem is somewhere in "throw;" operator inside
NewHandlerBox::new_handler_box() method, which is called as new_handler when
new operator fails to allocate memory.

Unfortunately I have no direct access to the machine with this configuration
(SLES11 installed on IA64 architecture), so I couldn't prepare a shorter
example program. For now, I can't say which parts of the program are essential
to reproduce the problem and which ones are not. However, in a very simple
example the problem wasn't reproduced.

Also, the mentioned test suite was executed on many other machines with
different OSes and architectures, but the problem have not arisen there so far.


-- 
           Summary: Inside new_handler "throw;" operator may cause abort
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: tsyvarev at ispras dot ru


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40606

[Bug libstdc++/40606] Inside new_handler "throw;" operator may cause abort

[paolo dot carlini at oracle dot com]

------- Comment #1 from paolo dot carlini at oracle dot com  2009-07-01 13:52 -------
Attachment missing. Also, please dougle check this is not a core C++ proper
issue.


-- 

paolo dot carlini at oracle dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40606

[Bug libstdc++/40606] Inside new_handler "throw;" operator may cause abort

[tsyvarev at ispras dot ru]

------- Comment #2 from tsyvarev at ispras dot ru  2009-07-01 13:54 -------
Created an attachment (id=18108)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18108&action=view)
reproduce problem

g++ -O2 test.cpp && ./a.out

Executing test_4_10()
Aborted

Exit code is 134.

Unfortunately, there is no reasonable backtrace, as the error is reported via 
abort() and the stack only shows the abort() call.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40606

[Bug libstdc++/40606] Inside new_handler "throw;" operator may cause abort

[paolo dot carlini at oracle dot com]

------- Comment #3 from paolo dot carlini at oracle dot com  2009-07-01 14:09 -------
gcc version, please.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40606

[Bug libstdc++/40606] Inside new_handler "throw;" operator may cause abort

[paolo dot carlini at oracle dot com]

------- Comment #4 from paolo dot carlini at oracle dot com  2009-07-01 14:19 -------
On x86_64, I can't reproduce either 4_3-branch, 4_4-branch or mainline. I would
suggest you to double check if the problem happens also with an official GNU
release (not Novell' SLES) and, in case it does, mark the PR as target, if not
report to Novell. Thanks.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40606

[Bug libstdc++/40606] Inside new_handler "throw;" operator may cause abort

[tsyvarev at ispras dot ru]

------- Comment #5 from tsyvarev at ispras dot ru  2009-07-01 14:56 -------
Sorry, forgot about gcc version. I will post it not long after.

As for core C++ or libstdcxx problem - I don't know because couldn't localize
problem yet. Probably, this core C++ issue.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40606

[Bug libstdc++/40606] Inside new_handler "throw;" operator may cause abort

[paolo dot carlini at oracle dot com]

------- Comment #6 from paolo dot carlini at oracle dot com  2009-07-01 14:57 -------
... and very probably target dependent, I can't reproduce on x86_64-linux.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40606

[Bug libstdc++/40606] Inside new_handler "throw;" operator may cause abort

[tsyvarev at ispras dot ru]

------- Comment #7 from tsyvarev at ispras dot ru  2009-07-02 06:16 -------
gcc --version gets:

gcc (SUSE Linux) 4.3.2 [gcc-4_3-branch revision 141291]

Yes, problem very probably target dependent - as I said, test suite was
executed on many other machines, including IA64 arhictecures with other
OSes(even SLES10) and SLES11 on other architectures(even on x86_64). But
problem have arisen only on SLES11[IA64].


-- 

tsyvarev at ispras dot ru changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 GCC target triplet|                            |ia64-suse-linux


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40606

[Bug target/40606] Inside new_handler "throw;" operator may cause abort

[paolo dot carlini at oracle dot com]

------- Comment #8 from paolo dot carlini at oracle dot com  2009-07-02 09:29 -------
Richard, can you please have a quick look? I don't have any ia64 machine
available and the problem can't reproduce for me on x86_64 with 4_3/4_4/4_5


-- 

paolo dot carlini at oracle dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rguenth at gcc dot gnu dot
                   |                            |org
          Component|libstdc++                   |target


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40606

[Bug target/40606] Inside new_handler "throw;" operator may cause abort

[rguenth at gcc dot gnu dot org]

------- Comment #9 from rguenth at gcc dot gnu dot org  2009-07-02 10:05 -------
I can reproduce it, the abort is from the system libunwind:

(gdb) run
Starting program: /tmp/a.out 
Executing test_4_10()

#0  0xa000000000010721 in __kernel_syscall_via_break ()
#1  0x2000000000422940 in *__GI_raise (sig=<value optimized out>)
    at ../nptl/sysdeps/unix/sysv/linux/raise.c:67
#2  0x2000000000425210 in *__GI_abort () at abort.c:88
#3  0x2000000000383a40 in _UIia64__sos_alloc (size=736) at mi/mempool.c:61
#4  0x2000000000383c30 in expand (pool=0x20000000003ab990) at mi/mempool.c:137
#5  0x2000000000383e00 in _UIia64__mempool_alloc (pool=0x20000000003ab990)
    at mi/mempool.c:180
#6  0x200000000038a680 in desc_prologue (body=0, rlen=9, mask=12 '\f', 
    grsave=44 ',', sr=0x600ffffffff7b218) at ia64/Gparser.c:52
#7  0x200000000038ce40 in create_state_record_for (c=0x600ffffffff7baf0, 
    sr=0x600ffffffff7b218, ip=<value optimized out>)
    at ia64/unwind_decoder.h:204
#8  0x2000000000394ed0 in uncached_find_save_locs (c=0x600ffffffff7baf0)
    at ia64/Gscript.c:458
#9  0x2000000000396420 in _ULia64_find_save_locs (c=0x600ffffffff7baf0)
    at ia64/Gscript.c:662
#10 0x2000000000397710 in _ULia64_step (cursor=0x600ffffffff7baf0)
    at ia64/Gstep.c:338
#11 0x2000000000385ce0 in _Unwind_RaiseException (
    exception_object=0x2000000000251860) at unwind/unwind-internal.h:78
#12 0x2000000000386400 in _Unwind_Resume_or_Rethrow (
    exception_object=0x2000000000251860) at unwind/Resume_or_Rethrow.c:43
#13 0x20000000001fd510 in __cxa_rethrow () from /usr/lib/libstdc++.so.6
#14 0x4000000000001b50 in NewHandlerBox::new_handler_box () at test.cpp:188
#15 0x20000000001fe2e0 in operator new(unsigned long) ()
   from /usr/lib/libstdc++.so.6
#16 0x4000000000001530 in test_4_10 () at test.cpp:257
#17 0x4000000000001900 in main (argc=4145104, argv=0xc00000000000048c)
    at test.cpp:431

which means libunwind cannot allocate memory.

(gdb) p *pool
$2 = {lock = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, 
      __kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, 
    __size = '\0' <repeats 39 times>, __align = 0}, obj_size = 736, 
  chunk_size = 65536, reserve = 44, num_free = 16, 
  free_list = 0x20000000003afcc0}

the pool seems to have plenty of space, no idea why it is expanded...

    if (pool->num_free <= pool->reserve)
      expand (pool);

    assert (pool->num_free > 0);

obviously expand here doesn't need to fatally fail here ...

OTOH alloc_memory

static void *
alloc_memory (size_t size)
{
  /* Hopefully, mmap() goes straight through to a system call stub...  */
  void *mem = mmap (0, size, PROT_READ | PROT_WRITE,
                    MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
  if (mem == MAP_FAILED)
    return NULL;

fails with a size of 65536.

This is a libunwind bug on one hand (the unnecessary fatal fail) and an
invalid testcase because you make libunwind fail by setrlimit.

Thus, invalid - not a GCC bug.  You might want to file the libunwind bug
where that is appropriate (http://savannah.nongnu.org/projects/libunwind/).


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|                            |INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40606

[Bug target/40606] Inside new_handler "throw;" operator may cause abort

[paolo dot carlini at oracle dot com]

------- Comment #10 from paolo dot carlini at oracle dot com  2009-07-02 10:08 -------
Thanks Richard.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40606

[Bug target/40606] Inside new_handler "throw;" operator may cause abort

[tsyvarev at ispras dot ru]

------- Comment #11 from tsyvarev at ispras dot ru  2009-07-02 11:26 -------
Ok, sorry for noise. I'll try with libunwind.

Only thing - what does it mean

> invalid testcase because you make libunwind fail by setrlimit.

Does it mean that setrlimit shouldn't be used with new operator? or with
exception unwind mechanism?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40606