Advanced Question bad alloc on calling oapiLoadMeshGlobal

[jedidia]

It's a pretty huge ship, the bad alloc happens at the 87. call. As far as I can tell I still have free ram, but I assume that the textures are stored in video memory? if so, the message is most probably me running out of that...

 

[orb]

As far as I can tell I still have free ram, but I assume that the textures are stored in video memory?

No, not video memory. Bad alloc is usually thrown if the heap is too fragmented to allocate a contiguous block, when you don't request huge amounts of memory, otherwise if too large memory block to fit in the largest contiguous block of RAM. How large are the meshes (vertices, faces) you want to load?

 

[jedidia]

How large are the meshes (vertices, faces) you want to load?

Mostly SSBB4.1, which average somewhere around 4000 faces if I'm not mistaken.

Also, I was mistaken before. oapiLoadMeshGlobal does not get called 87 times (that's the total number of modules, but not every module is a different mesh). The total ammount of meshes loaded is 22 at this time. I have vessels with more meshes which run perfectly fine... *scratches head*.

 

[lassombra]

If you clean memory right before running orbiter (several programs on the web to do this) does this still happen? And does it happen to anyone else? If yes to both of these, then it is probably some bug in the mesh load function. Meshes don't take that much ram though, so I'd be surprised if 22 meshes can fill allocation. If either of the mentioned actions solves it, check if you have other programs running at the same time that are being memory hogs. In some cases, certain programs will "pin" themselves to main memory and not allow their memory pages to be virtualized which can then cause memory to become fragmented preventing malloc from finding useful memory space.

Otherwise, check there is likely a memory leak within your code that is causing early fragmentation of the heap (do you create and destroy a lot of objects quickly? This can cause bad fragmentation)

 

[jedidia]

If you clean memory right before running orbiter (several programs on the web to do this) does this still happen?

Yes. Indeed, it even happens in the same memory address, even after a reboot. If ram was that fragmented, I wouldn't expect it to get the same memory address every single time... But it's still a possibility. After all, I only have 512 megs in this ancient crate.

Otherwise, check there is likely a memory leak within your code that is causing early fragmentation of the heap (do you create and destroy a lot of objects quickly? This can cause bad fragmentation)

No, there's a surprising absence of pointers in the code, actually. The only objects I have to allocate memory for myself remain valid until program exit and don't get deleted. There's a lot of orbiter handles getting created and deleted at times, but if there's a memory leak in there I can hardly do anything about it...

The interesting thing is that I'm only able to reproduce it with one particular vessel. It happens always at the same place, but the mesh that should get loaded at that time works without trouble in other vessels. Also, I have bigger vessels (the biggest with 36 different meshes. While that alone doesn't say much, as far as I can see they are about the same average size) which work too.

 

[Linguofreak]

Yes. Indeed, it even happens in the same memory address, even after a reboot. If ram was that fragmented, I wouldn't expect it to get the same memory address every single time... But it's still a possibility. After all, I only have 512 megs in this ancient crate.

The thing is, any modern operating system uses what's called "[ame="http://en.wikipedia.org/wiki/Virtual_memory"]virtual memory[/ame]". It doesn't matter if system memory is heavily fragmented because Orbiter doesn't deal with physical addresses: Windows gives it its own address space that starts out empty. As long as your swap space (which Windows calls the page file) is decently large, it doesn't even matter (except performance-wise) if you run out of RAM: the OS will write pages that it thinks won't be accessed for a while out to disk to free up RAM. When a program needs them again, it's paused until the OS can get them from disk, then resumed. Even the "pinning" that lassombra mentioned won't prevent malloc from allocating memory, it just limits the amount of memory that non-pinned programs can have in RAM *at the same time*. A program can have a gigabyte allocated on a 512 meg system, it's just that at any given time, half its address space will be on disk instead of in RAM.

The upshot of this is, unless the system is out of both RAM and swap (which is, on the other hand, quite possible given your RAM size), any allocation failure will almost certainly be a result of a fragmentation or low-memory condition in the program's own address space (which for 32-bit Windows programs will generally be 2GB (actually 4, but 2 GB is reserved for the kernel)). Fragmentation of physical memory is a complete non-issue for applications.

 

[Hielor]

What memory address, out of curiousity?

 

[movieman]

It doesn't matter if system memory is heavily fragmented because Orbiter doesn't deal with physical addresses: Windows gives it its own address space that starts out empty

However, video drivers may need contiguous memory if they're reading meshes from system RAM. Depends on whether the hardware is smart enough to DMA from non-contiguous buffers.

 

[jedidia]

What memory address, out of curiousity?

0x00aeeabc

here's the local disassembly, if that's any help at all:

7C812ADD  ja          7C844950 
7C812AE3  test        ecx,ecx 
7C812AE5  mov         dword ptr [ebp-40h],ecx 
7C812AE8  je          7C812AF1 
7C812AEA  push        edi  
7C812AEB  lea         edi,[ebp-3Ch] 
7C812AEE  rep movs    dword ptr es:[edi],dword ptr [esi] 
7C812AF0  pop         edi  
7C812AF1  lea         eax,[ebp-50h] 
7C812AF4  push        eax  
7C812AF5  call        dword ptr ds:[7C801510h] 
7C812AFB  pop         esi        <------ arrow shows up here
7C812AFC  leave            
7C812AFD  ret         10h  
7C812B00  test        edi,edi 
7C812B02  jle         7C80BE3E 
7C812B08  mov         edx,dword ptr [ebp-4] 
7C812B0B  mov         dword ptr [ebp+0Ch],edx 
7C812B0E  movzx       edx,word ptr [esi] 
7C812B11  mov         edi,dword ptr [ebp-8] 
7C812B14  mov         dl,byte ptr [edx+edi] 
7C812B17  mov         byte ptr [ecx],dl 
7C812B19  mov         edi,dword ptr [eax+0Ch] 
7C812B1C  movzx       edx,dl 
7C812B1F  mov         dx,word ptr [edi+edx*2] 
7C812B23  cmp         dx,word ptr [esi] 
7C812B26  jne         7C84B737 
7C812B2C  mov         edx,dword ptr [eax+8] 
7C812B2F  mov         bx,word ptr [edx+4] 
7C812B33  cmp         byte ptr [ecx],bl 
7C812B35  je          7C84B744

I can't really make sense of disassemblies, but it looks like vector operations to me... I know vectors are sometimes a bit excessive in their memory reservation, so that might be an explanation.

Depends on whether the hardware is smart enough to DMA from non-contiguous buffers.

I doubt that my hardware is smart for any today's definitions of smart. it's almost 10 years old...

 

[Black Phoenix]

Bad allocation errors you cannot figure out almost certainly point to memory corruption somewhere. Check for that.

Memory corruption is more likely than randomly running out of RAM (without intent to allocate gigabytes of data).

 

[lassombra]

Bad allocation errors you cannot figure out almost certainly point to memory corruption somewhere. Check for that.

Memory corruption is more likely than randomly running out of RAM (without intent to allocate gigabytes of data).

This, especially if it's at the same address. Happening at different addresses would have suggested a bug in orbiter's allocation scheme, but if it always happens at the same address, you've probably got a stick going bad. Also, has anyone else been able to reproduce this bug?

 

[Linguofreak]

This, especially if it's at the same address. Happening at different addresses would have suggested a bug in orbiter's allocation scheme, but if it always happens at the same address, you've probably got a stick going bad.

It doesn't need to be corruption due to bad memory. It might also be a write beyond the bounds of an array or through a bad pointer that's causing it.

 

[Black Phoenix]

It doesn't need to be corruption due to bad memory. It might also be a write beyond the bounds of an array or through a bad pointer that's causing it.

That's one of kinds of memory corruption. I'm mostly talking about that kind of memory corruption (not literally fault in memory chips).

 

[lassombra]

I was assuming faulty memory chip based on my (possibly incorrect I now realize) perception that only one computer was generating this error and it was working fine on others.

 

[Linguofreak]

I was assuming faulty memory chip based on my (possibly incorrect I now realize) perception that only one computer was generating this error and it was working fine on others.

My impression is that the code in question has only been tried on one machine, which doesn't really say anything for or against bad RAM.

However, the fact that it's always happening at the same virtual address means it probably isn't: Bad RAM will cause errors at a constant physical address, but a given physical address is by no means guaranteed to end up mapped to the same virtual address on different runs of a program (or even to always be assigned to the same program, which means he'd be observing crashes in other programs, or even the OS itself, if bad RAM were the problem).