23 Mar, 2014, Davion wrote in the 1st comment:
Votes: 0
I've been going over ROMs loading protocols the last couple days and I've noticed a leak I've not seen reported.

When shops are loaded

void load_shops( FILE *fp )
{
SHOP_DATA *pShop;

for ( ; ; )
{
MOB_INDEX_DATA *pMobIndex;
int iTrade;

pShop = alloc_perm( sizeof(*pShop) );
pShop->keeper = fread_number( fp );
if ( pShop->keeper == 0 )
break;

}
}


here it allocates a keeper, but if it's a bad number it just breaks and returns. The pShop is just left dangling. I'd suggest holding keeper in a temp variable and after you make sure it's not zeron, then alloc_perm pShop.
23 Mar, 2014, Omega wrote in the 2nd comment:
Votes: 0
Thats a good catch. But by default, isn't the whole alloc_mem/alloc_perm, and free_list system of ROM a leak that nobody reported :P J/K.
24 Mar, 2014, Davion wrote in the 3rd comment:
Votes: 0
Omega said:
Thats a good catch. But by default, isn't the whole alloc_mem/alloc_perm, and free_list system of ROM a leak that nobody reported :P J/K.


Heh, it basically is! However, in this case, one could replace this with malloc, and it'd still leak. It's just bad form.
24 Mar, 2014, Omega wrote in the 4th comment:
Votes: 0
Yeah, I know. Its why I stick to new/delete, and to my own engine these days. Man I used to be super addicted to ROM. (prods his posted snippets for example)
24 Mar, 2014, Pymeus wrote in the 5th comment:
Votes: 0
Resource pools are a useful form of resource management that are usually a better fit for long-running programs. Individual malloc/free/new/delete calls "only" do an acceptable job in a wider range of situations.

That said, memory today is cheap, CPUs are fast, and it's up to each of us to use techniques that we can work with effectively.
24 Mar, 2014, Rarva.Riendf wrote in the 6th comment:
Votes: 0
Problem with resource pool is it is harder to detect leak. Here if there was a malloc valgrind would detect it pretty easily, and maybe even clang.
25 Mar, 2014, Pymeus wrote in the 7th comment:
Votes: 0
It is harder… but not by much. Valgrind already knows how malloc works, but you can tell it how your pool allocator works by sprinkling a couple of macros in the appropriate places, as I understand it.
25 Mar, 2014, Davion wrote in the 8th comment:
Votes: 0
Pymeus said:
Resource pools are a useful form of resource management that are usually a better fit for long-running programs. Individual malloc/free/new/delete calls "only" do an acceptable job in a wider range of situations.

That said, memory today is cheap, CPUs are fast, and it's up to each of us to use techniques that we can work with effectively.


I was under the impression that memory pools like this where purely for performance and mattered only with the frequency of the calls, and not the longevity of the program. Surely you'd think the OS recycles it's memory at least as efficiently, if not more so than a homegrown memory pool ya? If I were using something that was allocating/deallocating like crazy, I'd probably consider something like this over malloc/calloc. It's definitely not something I'd factor in when considering the life of the program.
25 Mar, 2014, Runter wrote in the 9th comment:
Votes: 0
It's useful for very specific problems. There's a few other niche areas where you can eek out some gains in speed. It was at one time more useful, many years ago.

Oh, we're talking about custom memory allocation. I was referring to C/+.
25 Mar, 2014, Pymeus wrote in the 10th comment:
Votes: 0
Davion said:
I was under the impression that memory pools like this where purely for performance and mattered only with the frequency of the calls, and not the longevity of the program. Surely you'd think the OS recycles it's memory at least as efficiently, if not more so than a homegrown memory pool ya? If I were using something that was allocating/deallocating like crazy, I'd probably consider something like this over malloc/calloc. It's definitely not something I'd factor in when considering the life of the program.

Actually, malloc/free are notoriously slow. It's much more efficient to grab the first chunk of memory off a given pool's free list (a constant-time operation, assuming the appropriate pool has an opening) than to send malloc searching through a heterogeneous mass of memory blocks for an unused space of adequate size.

I mention long-running programs because the usage patterns of most programs (lots of ad-hoc malloc and free calls on memory of different sizes) usually fragments the heap as it runs. It is admittedly an assumption on my part that malloc's search complexity increases with fragmentation.
0.0/10