|
From: Nicholas N. <nj...@ca...> - 2004-07-14 13:04:07
|
Hi, I recently changed Valgrind so that the malloc-replacing tools return NULL if they can't satisfy the request, rather than dying with an assertion failure. This is good for malloc(), but not the right behaviour for C++'s operator new and operator new[]. (It the right behaviour for the 'nothrow' versions of new and new[]). This is a problem. Does anyone have any suggestions? How hard would it be to throw an exception from Valgrind's C code? N |
|
From: Tom H. <th...@cy...> - 2004-07-14 13:11:15
|
In message <Pin...@he...>
Nicholas Nethercote <nj...@ca...> wrote:
> This is good for malloc(), but not the right behaviour for C++'s
> operator new and operator new[]. (It the right behaviour for the
> 'nothrow' versions of new and new[]).
>
> This is a problem. Does anyone have any suggestions? How hard would
> it be to throw an exception from Valgrind's C code?
To do it portably must be virtually impossible as there's no
standard way to implement exceptions as far as I know so different
compilers may do it completely differently.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Nicholas N. <nj...@ca...> - 2004-07-14 13:35:02
|
On Wed, 14 Jul 2004, Tom Hughes wrote: >> This is good for malloc(), but not the right behaviour for C++'s >> operator new and operator new[]. (It the right behaviour for the >> 'nothrow' versions of new and new[]). >> >> This is a problem. Does anyone have any suggestions? How hard would >> it be to throw an exception from Valgrind's C code? > > To do it portably must be virtually impossible as there's no > standard way to implement exceptions as far as I know so different > compilers may do it completely differently. That's what I was afraid of. Hmm. Would it be better to abort with a warning if new/new[] failed? And maybe have an option that lets them return NULL? Silently doing the wrong thing (not throwing an exception) is bad. N |
|
From: Tom H. <th...@cy...> - 2004-07-14 13:47:22
|
In message <Pin...@he...>
Nicholas Nethercote <nj...@ca...> wrote:
> On Wed, 14 Jul 2004, Tom Hughes wrote:
>
>>> This is good for malloc(), but not the right behaviour for C++'s
>>> operator new and operator new[]. (It the right behaviour for the
>>> 'nothrow' versions of new and new[]).
>>>
>>> This is a problem. Does anyone have any suggestions? How hard would
>>> it be to throw an exception from Valgrind's C code?
>>
>> To do it portably must be virtually impossible as there's no
>> standard way to implement exceptions as far as I know so different
>> compilers may do it completely differently.
>
> That's what I was afraid of. Hmm. Would it be better to abort with a
> warning if new/new[] failed? And maybe have an option that lets them
> return NULL? Silently doing the wrong thing (not throwing an
> exception) is bad.
Aborting is probably better, yes.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Nicholas N. <nj...@ca...> - 2004-07-15 16:29:59
|
On Wed, 14 Jul 2004, Tom Hughes wrote: >> That's what I was afraid of. Hmm. Would it be better to abort with a >> warning if new/new[] failed? And maybe have an option that lets them >> return NULL? Silently doing the wrong thing (not throwing an >> exception) is bad. > > Aborting is probably better, yes. That's what I've done. A better scheme can be implemented if necessary. N |
|
From: Jeremy F. <je...@go...> - 2004-07-14 20:01:42
|
On Wed, 2004-07-14 at 14:04 +0100, Nicholas Nethercote wrote: > Hi, > > I recently changed Valgrind so that the malloc-replacing tools return NULL > if they can't satisfy the request, rather than dying with an assertion > failure. > > This is good for malloc(), but not the right behaviour for C++'s operator > new and operator new[]. (It the right behaviour for the 'nothrow' > versions of new and new[]). > > This is a problem. Does anyone have any suggestions? How hard would it > be to throw an exception from Valgrind's C code? As Tom said, pretty much impossible. But we could set up a piece of client-side code to throw the exception (as generated by the c++ compiler), and have Valgrind get the client to jump into it. J |
|
From: Nicholas N. <nj...@ca...> - 2004-07-14 20:55:46
|
On Wed, 14 Jul 2004, Jeremy Fitzhardinge wrote: > As Tom said, pretty much impossible. But we could set up a piece of > client-side code to throw the exception (as generated by the c++ > compiler), and have Valgrind get the client to jump into it. But won't that break if the client hasn't been compiled with GCC, due to the different compiler implementations of exceptions? N |
|
From: Jeremy F. <je...@go...> - 2004-07-14 21:18:10
|
On Wed, 2004-07-14 at 21:55 +0100, Nicholas Nethercote wrote:
> On Wed, 14 Jul 2004, Jeremy Fitzhardinge wrote:
>
> > As Tom said, pretty much impossible. But we could set up a piece of
> > client-side code to throw the exception (as generated by the c++
> > compiler), and have Valgrind get the client to jump into it.
>
> But won't that break if the client hasn't been compiled with GCC, due to
> the different compiler implementations of exceptions?
Yes, but so will all the intercepts since the other compiler will
(probably) use a different mangling scheme.
To support multiple compilers, we'd need to:
1. have intercepts for all the new/delete variants for each
compiler
2. compile an exception-throwing stub with each compiler
In principle, if two compilers use the same mangling scheme, they
implement the same ABI and therefore have the exception-throwing
mechanism. In practice, I think it probably comes down to luck.
J
|