   Really, Really, Really strange bug...
  hi, im currently writing a 3D engine and im up to the rendererbasicaly i need to explain how its structured before i can tell you the problem, here goes...PER-FRAME:Object  ^   --> Push Polygons Into Renderer  |   --> Renderer Sorts By Shader/Texture |   --> Flush  |    | +---------+    Loop  now to speed things up a bit & to avoid memory fragmentation, i do a one time memory allocation for my sort lists and polygon buffersheres the problem:if i have 1 polygon buffer i can allocate as much space as i wanteg.    const int MAX_RENDER_LIST_SIZE = 20480;struct SortKey { int key, data; };struct SortList { SortList() {list = new SortKey[MAX_RENDER_LIST_SIZE];  } SortKey *list;};class RENDERER {  SortList buffer;}    Now, if i have more than 1 buffer, i can only allocate something around 4500 as a maximum per buffer, the wierd bit is, i get an access violation error message comming in from GLU32, and im like WTF??? becasue the error is originiating from my Texture managers JPEG loader...ie. nothing to do with the frame-renderingso here''s what i think, its either:a stack overflow (i doubt it..)a segmetation fault (i doubt this too..)im running out of memmory to allocate (not possible.)System Specs:Win2k SP4 & Latest UpdatesP4 3.0Ghz, 512 DDR400, VC++ 6.0 SP5, Radeon9500 Pro PLEASE HELP, IM STUMPED.ThanksDanushka | IrixMSN & E-Mail: silvermace007#hotmail.com 
  if you''re getting an access violation error you are most likely writing past the end of one of your lists somewhere.  check to make sure you''re not accidentally using the same iterator twice without re-initializing it, and check to make sure that you are counting up the amount of info you are writing to the list correctly.  make sure you never write past the end of your arrays ( buffer[MAX_SIZE-1] ).  step through your code with a debugger and watch the values of your iterators or put in an assert statement that will throw up a message box if the iterator is ever bigger than MAX_SIZE-1.-me ;  hmm cant tell without the code that causes the bug, but you can do some things:-check if new is allocating mem (=dont return 0), sometimes it will stop allocating, but i dont know why exactly (maybe allocating to fast or filling the stack to much)-use some sort of memory manager that can tell you where the bug is located and then track it down (this one is good but need some manual fixes if used in net)edit: damn i think the mmgr iam talking about isnt available anymore, or the link is a wrong oneT2k   [edited by - T2k on February 1, 2004 4:51:42 PM];quote:Original post by T2k  -check if new is allocating mem (=dont return 0), sometimes it will stop allocating, but i dont know why exactly (maybe allocating to fast or filling the stack to much)negative!new will throw std::bad_alloc if the memory allocation goes screawy, returning 0 isnt gareented and your better off checking for an exception being thrown;  the thing is that the render() function hasnt even been called when the violation occurs.. ;quote:Original post by _the_phantom_   quote:Original post by T2k    -check if new is allocating mem (=dont return 0), sometimes it will stop allocating, but i dont know why exactly (maybe allocating to fast or filling the stack to much)negative!new will throw std::bad_alloc if the memory allocation goes screawy, returning 0 isnt gareented and your better off checking for an exception being thrown Depends on the compiler you're using. VC++6.0 SP5 doesn't throw, it returns zero.   [edited by - petewood on February 2, 2004 4:07:59 AM];  That''s because VC++6 is significantly more broken than the average C++ compiler.;  if you take the average, you might find that its VC (in some form) ;  Yes, but neither VC++ 7 nor 7.1 have this bug.  Nor, for that matter, does g++.;quote:Original post by DrPizza  Yes, but neither VC++ 7 nor 7.1 have this bug.  Nor, for that matter, does g++. actually it depends which library you link with in VC++ 7C++ supports dynamic allocation and deallocation of objects using the new and delete operators. These operators allocate memory for objects from a pool called the free store. The new operator calls the special function operator new, and the delete operator calls the special function operator delete.Beginning in Visual C++ .NET 2002, the CRT''s new function (in libc.lib, libcd.lib, libcmt.lib, libcmtd.lib, msvcrt.lib, and msvcrtd.lib) will continue to return NULL if memory allocation fails. However, the new function in the Standard C++ Library (in libcp.lib, libcpd.lib, libcpmt.lib, libcpmtd.lib, msvcprt.lib, and msvcprtd.lib) will support the behavior specified in the C++ standard, which is to throw a std::bad_alloc exception if the memory allocation fails.Normally, if you #include one of the C++ standard headers, like , you''ll get a /defaultlib directive in your object that will reference the appropriate C++ Standard Library according to the CRT model you used (the /M* compiler options). Generally, that will cause the linker to use the throwing operator new from the C++ Standard Library instead of the nonthrowing one from the main CRT, because the order of defaultlib directives will cause libcp.lib to be searched before libc.lib (under /ML).see these links too:knowledge basethe operator new function