Introcuding safe_malloc and safe_realloc macros: fixes #480

[unoebauer]

Simple safe_malloc and safe_realloc macros are introduced. These check for returned NULL pointers in the allocation process and stop the calculation in these cases.

• introduce safe_malloc and safe_realloc macros
• replace memory operations with safe counterparts
• test it:
  • tardis_example
  • tardis_example with OMP
  • tardis_example with v-logging
  • tardis_example with OMP and v-logging

[yeganer]

When i was looking at the C code I noticed several uses of malloc in combination with memcopy to zero out the allocated space. I think we should replace those with calloc which uses the operating system to do that.

Another thing i noticed is the exponential behavior of the allocation for the virtual packets. using a good guess for the 1st allocation we should only need to realloc in special cases. In these cases we should only extend the array by no_of_packets and not double it.

[orbitfold]

what's the point of the FAIL macro?

[unoebauer]

You're right, we could get rid of it

[unoebauer]

@orbitfold, @yeganer, @wkerzendorf Unit tests needed for the macros?

[wkerzendorf]

@yeganer we have no general good guess for then number of virtual packets. @orbitfold mirrored pythons way allocating memory for lists.

[wkerzendorf]

@unoebauer would be good - but I don't know if that is easy.

[unoebauer]

@yeganer: you kneed to know the number of real packets (trivial - set in the config), the number of virtual packets spawned each time the virtual packets are generated (trivial - set in the config) and finally the number of events triggering the generation of v-packets (very hard - each time a real packet is launched -> trivial - and each time a real packet interacts -> very hard).

[yeganer]

@unoebauer If I interpret this correctly we have

no_virt_packets = no_of_packets * virt_packet_count * average_spawn_per_packet

So all we have to do is generate some statistics, ceil the result and every time it runs out of space add another no_of_packets.

[wkerzendorf]

@yeganer what's wrong with the current approach? I doubt that it causes any problems. I mean even with 10 million floats this is still only 80 Mb in memory.

[unoebauer]

@yeganer Let's not overdo it - --with-vpacket-logging is a diagnostics tool. It won't be active in normal runs. So no need to invest too much time into making the memory allocation process very sophisticated.

Moreover, doing statistics on this would be a lengthy process because there's a huge parameter space to be covered.

BTW, an estimate for the number of virtual packets would look like:

no_virt_packets = no_real_packets * virt_packets_per_event + no_real_packets * virt_packets * average_no_real_packet_interactions

[unoebauer]

@yeganer, @orbitfold, @wkerzendorf
Given the simplicity of the macros, I'd not include unit tests. Tardis example runs fine (see milestones), Travis is happy so I'd merge it....

[yeganer]

@unoebauer Yeah you are right. This isn't needed. I just had the segfault issue in the back of my had and was wondering if this was connected. After doing the math, I agree this shouldn't be connected.

Update:

I'm fine with merging. Unit tests shouldn't be needed. I assume you DID test the macros in a local environment?
I think we should add an error message.