Mailing-List: contact stdcxx-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: stdcxx-dev@incubator.apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Message-ID: <4485D7F2.8070708@roguewave.com>
Date: Tue, 06 Jun 2006 13:30:58 -0600
From: Martin Sebor <sebor@roguewave.com>
Organization: Rogue Wave Software
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050920
MIME-Version: 1.0
To: stdcxx-dev@incubator.apache.org
Subject: Re: IBM VAC++ 8.0 linux placement issues
References: <D730FF7CEDDCA64483F9E99D999A158B119C13@qxvcexch01.ad.quovadx.com>
 <4485CE32.40607@roguewave.com>
In-Reply-To: <4485CE32.40607@roguewave.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

I reproduced the crash in a small compiler-only test case
(specific to XLC++) and filed a PMR with IBM. Here are the
details: http://issues.apache.org/jira/browse/STDCXX-199.
It looks to me like exceptions are essentially unusable
in this configuration.

Martin

Martin Sebor wrote:
> Scott Zhong wrote:
> 
>> There are several stdlib test that uses mynew.h and the placement new is
>> causing it to seg fault.
>>
>>  
>>
>> Affected tests:
>>
>>  
>>
>> tests/stdlib/containers/deque_modifiers
>> tests/stdlib/diagnostics/exceptions
>>
>> tests/stdlib/test/new
> 
> 
> This test exercises the correctness of the replaced operators
> themselves (i.e., those defined by the test suite to exercise
> the rest of the library). The other tests most likely all crash
> because there's something wrong with the operator. The test runs
> with the expected results when compiled with gcc so it seems that
> this might be specific to XLC++.
> 
> The stack trace from the core dump (below) shows that it occurs
> in the replacement operator new which is just a forwarding
> function with hardly any body:
> 
> 166     void* operator new (_RWSTD_SIZE_T n) _THROWS ((_RWSTD_BAD_ALLOC))
> 167     {
> 168         return operator_new (n, false);
> 169     }
> 
> That seems to suggest some kind of runtime library problem.
> Let me try to reproduce it in a smaller test case.
> 
> Here's the backtrace:
> 
> (gdb) where
> #0  0x0000000010003e78 in operator new (n=0) at rw_new.h:167
> #1  0x00000000100044fc in test_bad_alloc ()
>     at /amd/devco/sebor/dev/stdlib/tests/test/00_new.cpp:138
> #2  0x00000000100083f8 in run_test ()
>     at /amd/devco/sebor/dev/stdlib/tests/test/00_new.cpp:470
> #3  0x000000001000a080 in rw_vtest (argc=1, argv=0x1ffffffeff8,
>     file_name=0x100a719c 
> "/amd/devco/sebor/dev/stdlib/tests/test/00_new.cpp",
>     clause=0x0, comment=0x0,
>     fun=@0x100f7050: 0x10008398 <run_test(int, char**)>,
>     optstr=0x100a72ec "|-no-new-delete# |-no-bad_alloc# |-no-mismatch# 
> |-no-bad-delete# |-no-double-delete# |-no-corruption# |-no-leaks# 
> |-no-stress-test#",
>     va=0x1ffffffea48 "")
>     at /amd/devco/sebor/dev/stdlib/tests/src/driver.cpp:1043
> #4  0x000000001000b1fc in rw_test (argc=1, argv=0x1ffffffeff8,
>     fname=0x100a719c "/amd/devco/sebor/dev/stdlib/tests/test/00_new.cpp",
>     clause=0x0, comment=0x0,
>     testfun=@0x100f7050: 0x10008398 <run_test(int, char**)>,
>     optstr=0x100a72ec "|-no-new-delete# |-no-bad_alloc# |-no-mismatch# 
> |-no-bad-delete# |-no-double-delete# |-no-corruption# |-no-leaks# 
> |-no-stress-test#")
>     at /amd/devco/sebor/dev/stdlib/tests/src/driver.cpp:1140
> #5  0x0000000010005f7c in main (argc=1, argv=0x1ffffffeff8)
>     at /amd/devco/sebor/dev/stdlib/tests/test/00_new.cpp:485