what is the best way to trap 'NEW' failling to allocate memo

[Conan]

[Kzinti]

[Conan]

if NEW was returning a NULL I could trap it easily however VS2005 seems to do something else. I am getting code stepping over my test for NULL and an invalid pointer. In addition I don't know if Hekkus uses NEW or not but it is now not failing when it fails to load a WAV resource. The pointer to the data is invalid but Hekkus thinks it is and plays it causing a crash. I should point out that it's not Hekkus or my code which remain unchanged but instead it's the compiler & linker which I think have changed in some way I'm not yet understanding. All my game works except WAVs.

[Digby]

You might want to move this to the Developer's forum.

So if I understand you correctly, you claim that operator new returns a non-NULL address, but then when this memory is supposedly accessed by a 3rd Party library it crashes?

Have you tried to access the memory yourself immediatly after the the allocation to see if the problem still exists?

If you're using new to allocate a buffer, have you ensured that the buffer is the correct size? If it's too small, the returned address would be valid, but the library may think that it's larger and caused an overrun.

Have you looked at the crash in the debugger to determine if it's due to reading/writing to this buffer that you've allocated?

Can you post the line of code that makes the call to new, along with the assembly code generated by the compiler for the call?

[Conan]

How did this get in the general forum??? Will see if I can move.
I can't post the code that fails cause there's no debug version of Hekkus. All I know is that I can force the error or make it go away by changing where it does the loading. As this code HAS NOT CHANGED since eVC3 it's a setup issue or linker or memory management change or whatever but very hard to do much until I know I can trap the errors happening.

As I can't debug Hekkus I am moving the problem into my code by loading Hekkus WAVs earlier. I can then see that NEW does not act correctly. I will have time on Friday to do a sample to show what happens I hope.

No option to move to another forum, Do I need a moderator to do this???

[sponge]

[BIGBEN]

[drgoldie]

[BIGBEN]

Or maybe look at STLPort's allocate() to make it faster.

[Kzinti]

[Digby]

Kzinti is correct. From :

If there is insufficient memory for the allocation request, by default operator new returns NULL. You can change this default behavior by writing a custom exception-handling routine and calling the _set_new_handler run-time library function with your function name as its argument. For more details on this recovery scheme, see The operator new Function.

I'm pretty certain that C++ EH is now supported on WM devices and has been for a while. More info . I never use the stuff though.

[InexorableTash]

Note that older Microsoft C++ compilers used a "non-throwing new" which returned NULL. Newer ones default to a "throwing new", but you can change this with a compiler flag.

This sounds like it could be the source of the problem; code written for devices compiled with eVC++ 3/4 would probably have returned NULL. In VS2005 the compiler front end is the same between desktop and devices, so it may be a throwing new by default.

This has a partial explanation:

[Conan]

Many thanks guys, I have a day's leave on Friday to play with this. The Hekkus code was compiled with eVC3 I think so I have no control of that but I can set up the exception handler for my NEW requirements.

The thing I still don't understand here is that the WAV files Hekkus loads are there and working from the main loop but not working in the actual functions that call them so I have 2 issues not just the NEW thing.

[BIGBEN]

As I remeber Hekkus license, if you provided donation you can get the source code. Anyway I'm sure Thomas Maniero would be glad to give you the source code of Hekkus to make things work with VS2005.

http://www.shlzero.com/modules.php?name ... page&pid=2

Hope it helps,

P.S. Thank you for pioneering through VS2005

[Conan]