Archived

This topic is now archived and is closed to further replies.

Problems with c++ new()

This topic is 6028 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

This is a very, very bizzare problem I''m getting. I''m currently testing some image convertor code, and the bit I''m testing is an 8-bit windowed screen from an 8bit bitmap file. Fine, simple. BUT, get this, new() is failing, but only when I set my desktop to 256 colours. Anything else is fine, but put it in 8bit, and BOOM, new(() fails. _CrtCheckMemory() tells me there''s a bad node on the heap, which isn''t a lot of good to me as I''m not too sure how to fix that. Platform is Win2K SP2, PIII 866, 256MB ram, and an old 4MB S3 VirGE PCI vid card (don''t snigger, it''s only tempoary) I did some tracing etc... and found the heap allocations were failing due to exceptions in NTDLL.DLL Question is, anyone got a clue how the desktop colour depth is causing failures (access violations) in NTDLL.DLL? Waassaap!!

Share this post


Link to post
Share on other sites
Possiblay sounds like not enough memory. new() (u using c++??? if u are use ''new''without the parenthesis) allocates host memory not video mem, also M$ windows may not like u using the new command to allocate memoory. look for the windows specific one in the msdn and try again.

~prevail by daring to fail~

Share this post


Link to post
Share on other sites
I''m not sure why you''re setting your deskrop to 256 colours anyway. What exactly are you trying to do? If you''re just converting the bit-depth of an image, your desktop bit-depth would no impact on that at all... Can you describe exactly what you''re trying to do?

Zerosignull, you can use whatever you like to allocate memory on windows. If you trace the source for operator new, you will eventually see a call to HeapAlloc(). Look at the source for _heap_alloc_base() in malloc.c (assuming you have the CRT source installed)


War Worlds - A 3D Real-Time Strategy game in development.

Share this post


Link to post
Share on other sites
_CrtCheckMemory() tells you if you''ve destroyed your memory heap. If _DEBUG is not defined, then the preprocessor will remove any reference to it, so it''s only available in Debug builds. Basically, it verifies the base heap and inspects every memory block you''ve allocated. If it returns FALSE, you''ve done something wrong...

You can have it so that _CrtCheckMemory is called every time you allocate memory by turning the flag _CRTDBG_CHECK_ALWAYS_DF on in a call to _CrtSetDbgFlag().


War Worlds - A 3D Real-Time Strategy game in development.

Share this post


Link to post
Share on other sites
Ok, an update for you all to clarify a few things.

The reason I'm setting my desktop depth down to 256 is because it's a DX app, and I have to run in windowed mode so I can debug it properly. This means that to get a target image format of 8bit, I have to adjust the colour depth of the desktop down.

I've only just started the image convertor class, and so all I've done is the bit-depth independent straight-copy function. I just wanted to test it and get a visible result before I start the ones that are actually more effort to do.

The items I'm trying to allocate with new are classes, I just put the brackets in my message to show I meant the c++ new command.

Originally, the errors came when I was trying to create an instance of my CGraphic class. I wondered how this happened, as I hadn't altered the class in any way since my last debug build, and so I set breakpoints in the constructor(s), but they never got called.

I traced new into the crt source code, and came to HeapAlloc(), and after that is where the exceptions in NTDLL.DLL occur, so I created some dummy classes based on the graphic class, but without any of the functions, just the data to test things out. And these are what are still failing:

    
class _CD2XGraphicDummyTest
{
protected:
int Height; // Heigth of the graphic, in pixels

int Width; // Width of the graphic, in pixels

int ColourDepth; // The colour depth of the graphic

bitfield Flags; // Miscellaneous info of object instance



// What the graphic is currently doing

enum State { Unloaded, Loading } CurrentState;
};


Again, all the allocations work fine in any other colour depth, just not 8 bit.

My suspicions are starting to think that somehow, something the debugger does is causing problems with the video driver's 8 bit code, but it's a wild guess.

I'm at a loss here, I've never had problems with the haep before. I was under the assumption that it would grow automatically to the programs requests, without needing any intervention, and as I have 256MB of ram + my swap file, I figured it'd be fine.

Waassaap!!

Edited by - mr_jrt on June 11, 2001 11:44:35 AM

Share this post


Link to post
Share on other sites
Ok, I fixed it.

-Sorry for blaming you Bill-

Turns out it was a mistake in a previous malloc (which only runs in 8bit mode), where I allocated the memory for the pallette, I allocated 256 bytes, not 256 entries - my bad.

Hence when I filled it in with DDSurface->GetEntries(), I overwrote the heap, causing all the fun of the fair I got. Thanks go out to all for taking to take the time to try and help.

- mr_jrt

Waassaap!!

Share this post


Link to post
Share on other sites