Jump to content
  • Advertisement

Archived

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

FXO

Malloc error

This topic is 5851 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

Hello! Im having some trouble with malloc. I run WindowsXP and MSVC 6.0. This following line causes my program to crash:
      
texture->imageData=(GLubyte *)malloc(imageSize);	



- imageSize = 65536
- GLubyte is defined as "unsigned char" (not that it should matter though)
- imageData is a GLubyte pointer
  
Could this be an error in MSVC's malloc function? I have no idea of how to fix this. I have pinpointed the line that causes the crash and printed out the variable values. The strange thing is that it only crashes when i run the program without a debugging enviroment. / The program is COMPILED in DEBUG MODE in both cases. / When I run the program in MSVC's debug enviroment, it runs fine. / When I execute the exe-file in any other way it crashes (Ctrl+F5 or Explorer). I have rebuild everyting about 10 times and im sure im running the right exe-file. Crash information:
  
AppName: cn.exe	 AppVer: 0.0.0.0	 ModName: ntdll.dll
ModVer: 5.1.2600.0	 Offset: 000036f7
  
The program error:
  
The instruction at "0x77f536f7" referred to the memory at "0x00000000". The memory operation could not be executed.
The following error was returned:
The memory could not be "written".
  
Thank you for your time. /Fredrik Olsson [edited by - FXO on September 8, 2002 11:30:53 PM]

Share this post


Link to post
Share on other sites
Advertisement
I believe that in some part your program are writing to the wrong memory address, maybe you alloc some number of bytes, but are writing more than the allocated number.
Or maybe the "texture" is pointing to the wrong address or are NULL.

Share this post


Link to post
Share on other sites
Nope.. the texture struct is valid, checked it both in debug and "free" execution of the program.

Share this post


Link to post
Share on other sites
Are you refering/opening/loading some files using relative path before that codes? If so, it might caused by the path thingie. Change it to absolute path and see. Try using GetLastError and FormatMessage to see what''s your error.

Just my suggestion.

Share this post


Link to post
Share on other sites
Is the statement inside an object that is not being initialized properly? If so, set a breakpoint at that line, and check your ''this'' value.

Share this post


Link to post
Share on other sites
crash on malloc? 97% of the time that means somewhere previous in your program in corrupting memory. Here''s why. the malloc function uses a table of data to manage where memory is allocated and how much, and the only reaosn aa call to malloc will crash is because that table is being corrupted. In debug mode, the table is stored differently than in release mode, and it''s pretty common in my experience for memory corruption to sneak past Visual C''s pretty loust CRT Debug libraries and then only show up in release mode, where CRT debug stuff isn''t present.

(CRT is the memchecking stuff used by default in debug mode-- it''s supposed to generate assert() errors if you overwrite memory).

Also! Check for accidentally using free(ptr) on either a NULL pointer or a pointer you''ve already free''d. That was usually the main culprit for cauing malloc to crash in my experience.

- Air

Share this post


Link to post
Share on other sites
Thank you for your input!

DerekSaw: Yes, the relative paths are cluttered all over the place, I changed the onces close to the malloc()-statement, but it didnt help.
I couldn''t get the GetLastError()/FormatMessage() working, I''ll have to read up on which parameters to parse. Where should I put it?

lytlea: Im going through all the calls to loadTGA(), and there are a few .
I have found one class that has __vfptr=0x0000000, but none have a "NULL" this-pointer.

Air: I found a call to free() with a NULL pointer (I used a macro to check all.

daerid: Shouldn''t malloc work? I have quite a few lines to replace, my project is spread over 192 files.



-Im not recompiling the exe, its a debug build, are the malloc table still stored differently when run under MSVC debug enviroment and from explorer?

-__vfptr is a pointer to a class virtual functions, right?
My "material"-class, which calls loadTGA() sometimes has a NULL _vfptr, could this be right?

Share this post


Link to post
Share on other sites
Ok, if I understand your response to my suggestion correctly, youd don''t need to check every single call to LoadTGA - just the one that''s causing the crash. If the function is called many times in your program, don''t set the breakpoint inside the function, set it on the function call itself. Then use MSVCs debugger to ''step-into'' the function and check your values. See if anything is out of whack.

However, the other suggestions people have been giving about corrupted memory are probably more likely. Try checking your last few memory allocations before the crash. See if anything is bogus there.

And if you are using C++, it is better to use new. Malloc ''will'' work, but the biggest reason (from my limited knowledge), is that malloc doesn''t understand constructors. Also, you can pass delete a NULL pointer and it won''t crash hard like free(). Plus you can create your own new handler easily for debugging purposes.

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!