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...
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?As far as I can tell I still have free ram, but I assume that the textures are stored in video memory?
How large are the meshes (vertices, faces) you want to load?
If you clean memory right before running orbiter (several programs on the web to do this) does this still happen?
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)
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.
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
What memory address, out of curiousity?
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
Depends on whether the hardware is smart enough to DMA from non-contiguous buffers.
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.
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.
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.