You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@stdcxx.apache.org by Martin Sebor <se...@roguewave.com> on 2007/07/11 21:25:28 UTC

Re: svn commit: r553587 - /incubator/stdcxx/trunk/tests/self/0.new.cpp

faridz@apache.org wrote:
> Author: faridz
> Date: Thu Jul  5 11:13:04 2007
> New Revision: 553587
> 
> URL: http://svn.apache.org/viewvc?view=rev&rev=553587
> Log:
> 2007-07-05 Farid Zaripov <Fa...@epam.com>
> 
> 	* 0.new.cpp: Catch SIGSEGV signal as SIGABRT.

Why is this necessary?

Martin

> 
> Modified:
>     incubator/stdcxx/trunk/tests/self/0.new.cpp
> 
> Modified: incubator/stdcxx/trunk/tests/self/0.new.cpp
> URL: http://svn.apache.org/viewvc/incubator/stdcxx/trunk/tests/self/0.new.cpp?view=diff&rev=553587&r1=553586&r2=553587
> ==============================================================================
> --- incubator/stdcxx/trunk/tests/self/0.new.cpp (original)
> +++ incubator/stdcxx/trunk/tests/self/0.new.cpp Thu Jul  5 11:13:04 2007
> @@ -61,6 +61,7 @@
>  #define FAIL(code)                                              \
>      fail = line = __LINE__;                                     \
>      signal (SIGABRT, handle_ABRT);                              \
> +    signal (SIGSEGV, handle_ABRT);                              \
>      if (0 == setjmp (env)) {                                    \
>          code;                                                   \
>          exit_status = 1;                                        \
> @@ -72,6 +73,7 @@
>  #define PASS(code)                                              \
>      fail = -1; line = __LINE__;                                 \
>      signal (SIGABRT, handle_ABRT);                              \
> +    signal (SIGSEGV, handle_ABRT);                              \
>      if (0 == setjmp (env)) {                                    \
>          code;                                                   \
>      }                                                           \
> 
> 


Re: svn commit: r553587 - /incubator/stdcxx/trunk/tests/self/0.new.cpp

Posted by Martin Sebor <se...@roguewave.com>.
Farid Zaripov wrote:
>> -----Original Message-----
>> From: Martin Sebor [mailto:msebor@gmail.com] On Behalf Of Martin Sebor
>> Sent: Wednesday, July 18, 2007 7:12 AM
>> To: stdcxx-dev@incubator.apache.org
>> Subject: Re: svn commit: r553587 - 
>> /incubator/stdcxx/trunk/tests/self/0.new.cpp
>>
>>>   No, because of _config-msvcrt.h, line 151:
>>>
>>>    // operator new and delete is not reliably replaceable across
>>>    // shared library boundaries, which includes the shared library
>>>    // version of the language support library #define 
>>> _RWSTD_NO_REPLACEABLE_NEW_DELETE
>>>
>>>   Shall we install SIGSEGV signal handler only if 
>>> _RWSTD_NO_REPLACEABLE_NEW_DELETE macro is #defined ?
>> Right. Then the test for the replacement operator new should 
>> be guarded by the macro, shouldn't it?
> 
>   I think it should, but then the all 0.new.cpp test should be guarded
> by the macro,
> because of all test cases in this test are excercising the replacement
> new/delete operators:

True. If there's no way to reliably replace operators new and delete
on Windows that's what we'll have to do. I thought I heard that it was
possible with some MSVC-specific hackery. If you can find some docs on
how to it that would great. If not, let's just guard the test (as we
do the uses of the replacement operator new machinery) and be done
with it.

Martin

RE: svn commit: r553587 - /incubator/stdcxx/trunk/tests/self/0.new.cpp

Posted by Farid Zaripov <Fa...@epam.com>.
> -----Original Message-----
> From: Martin Sebor [mailto:msebor@gmail.com] On Behalf Of Martin Sebor
> Sent: Wednesday, July 18, 2007 7:12 AM
> To: stdcxx-dev@incubator.apache.org
> Subject: Re: svn commit: r553587 - 
> /incubator/stdcxx/trunk/tests/self/0.new.cpp
> 
> >   No, because of _config-msvcrt.h, line 151:
> > 
> >    // operator new and delete is not reliably replaceable across
> >    // shared library boundaries, which includes the shared library
> >    // version of the language support library #define 
> > _RWSTD_NO_REPLACEABLE_NEW_DELETE
> > 
> >   Shall we install SIGSEGV signal handler only if 
> > _RWSTD_NO_REPLACEABLE_NEW_DELETE macro is #defined ?
> 
> Right. Then the test for the replacement operator new should 
> be guarded by the macro, shouldn't it?

  I think it should, but then the all 0.new.cpp test should be guarded
by the macro,
because of all test cases in this test are excercising the replacement
new/delete operators:

/***********************************************************************
****
 *
 * 0.new.cpp - test exercising replacement operator new and delete

Farid.

Re: svn commit: r553587 - /incubator/stdcxx/trunk/tests/self/0.new.cpp

Posted by Martin Sebor <se...@roguewave.com>.
Farid Zaripov wrote:
>> -----Original Message-----
>> From: Martin Sebor [mailto:sebor@roguewave.com] 
>> Sent: Friday, July 13, 2007 5:57 PM
>> To: stdcxx-dev@incubator.apache.org
>> Subject: Re: svn commit: r553587 - 
>> /incubator/stdcxx/trunk/tests/self/0.new.cpp
>>
>>>   To continue the execution and check another testcases the SIGSEGV 
>>> signal should be handled.
>> But the SIGSEGV indicates an error, while SIGABRT indicates 
>> the expected behavior. I.e., the replacement operator delete 
>> defined in the driver aborts when it's passed a pointer that 
>> wasn't returned from a prior call to the matching operator 
>> new. The operator should never segfault. Is the replacement 
>> operator not being called?
> 
>   No, because of _config-msvcrt.h, line 151:
> 
>    // operator new and delete is not reliably replaceable across
>    // shared library boundaries, which includes the shared library
>    // version of the language support library
> #define _RWSTD_NO_REPLACEABLE_NEW_DELETE
> 
>   Shall we install SIGSEGV signal handler only if
> _RWSTD_NO_REPLACEABLE_NEW_DELETE macro is #defined ?

Right. Then the test for the replacement operator new should be
guarded by the macro, shouldn't it?

Martin


RE: svn commit: r553587 - /incubator/stdcxx/trunk/tests/self/0.new.cpp

Posted by Farid Zaripov <Fa...@epam.com>.
> -----Original Message-----
> From: Martin Sebor [mailto:sebor@roguewave.com] 
> Sent: Friday, July 13, 2007 5:57 PM
> To: stdcxx-dev@incubator.apache.org
> Subject: Re: svn commit: r553587 - 
> /incubator/stdcxx/trunk/tests/self/0.new.cpp
> 
> >   To continue the execution and check another testcases the SIGSEGV 
> > signal should be handled.
> 
> But the SIGSEGV indicates an error, while SIGABRT indicates 
> the expected behavior. I.e., the replacement operator delete 
> defined in the driver aborts when it's passed a pointer that 
> wasn't returned from a prior call to the matching operator 
> new. The operator should never segfault. Is the replacement 
> operator not being called?

  No, because of _config-msvcrt.h, line 151:

   // operator new and delete is not reliably replaceable across
   // shared library boundaries, which includes the shared library
   // version of the language support library
#define _RWSTD_NO_REPLACEABLE_NEW_DELETE

  Shall we install SIGSEGV signal handler only if
_RWSTD_NO_REPLACEABLE_NEW_DELETE macro is #defined ?

Farid.

Re: svn commit: r553587 - /incubator/stdcxx/trunk/tests/self/0.new.cpp

Posted by Martin Sebor <se...@roguewave.com>.
Farid Zaripov wrote:
>> -----Original Message-----
>> From: Martin Sebor [mailto:sebor@roguewave.com] 
>> Sent: Wednesday, July 11, 2007 10:25 PM
>> To: stdcxx-dev@incubator.apache.org
>> Subject: Re: svn commit: r553587 - 
>> /incubator/stdcxx/trunk/tests/self/0.new.cpp
>>
>> faridz@apache.org wrote:
>>> Author: faridz
>>> Date: Thu Jul  5 11:13:04 2007
>>> New Revision: 553587
>>>
>>> URL: http://svn.apache.org/viewvc?view=rev&rev=553587
>>> Log:
>>> 2007-07-05 Farid Zaripov <Fa...@epam.com>
>>>
>>> 	* 0.new.cpp: Catch SIGSEGV signal as SIGABRT.
>> Why is this necessary?
> 
>   On MSVC operator delete[] () invoke operator delete (). So in the
> following code
> (taken from test_mismatch()):
> 
>   void* p = operator new (0);
>   operator delete[] (p);
>   operator delete (p);
> 
>   the operator delete[] (p) frees the memory and next operator delete
> (p) raises SIGSEGV.
> 
>   To continue the execution and check another testcases the SIGSEGV
> signal should be handled.

But the SIGSEGV indicates an error, while SIGABRT indicates
the expected behavior. I.e., the replacement operator delete
defined in the driver aborts when it's passed a pointer that
wasn't returned from a prior call to the matching operator
new. The operator should never segfault. Is the replacement
operator not being called?

Martin

RE: svn commit: r553587 - /incubator/stdcxx/trunk/tests/self/0.new.cpp

Posted by Farid Zaripov <Fa...@epam.com>.
> -----Original Message-----
> From: Martin Sebor [mailto:sebor@roguewave.com] 
> Sent: Wednesday, July 11, 2007 10:25 PM
> To: stdcxx-dev@incubator.apache.org
> Subject: Re: svn commit: r553587 - 
> /incubator/stdcxx/trunk/tests/self/0.new.cpp
> 
> faridz@apache.org wrote:
> > Author: faridz
> > Date: Thu Jul  5 11:13:04 2007
> > New Revision: 553587
> > 
> > URL: http://svn.apache.org/viewvc?view=rev&rev=553587
> > Log:
> > 2007-07-05 Farid Zaripov <Fa...@epam.com>
> > 
> > 	* 0.new.cpp: Catch SIGSEGV signal as SIGABRT.
> 
> Why is this necessary?

  On MSVC operator delete[] () invoke operator delete (). So in the
following code
(taken from test_mismatch()):

  void* p = operator new (0);
  operator delete[] (p);
  operator delete (p);

  the operator delete[] (p) frees the memory and next operator delete
(p) raises SIGSEGV.

  To continue the execution and check another testcases the SIGSEGV
signal should be handled.

Farid.