Open wrtobin opened 6 years ago
In my particular case it is of course also possible not to copy the meshes at all and just get by with a single reference mesh with many fields for the instantiated simulations, that hasn't been a priority yet since the memory overhead for the meshes compared to the other data structures in each simulation is relatively small.
Regardless of my particular case this is still a potential source of error.
You may be able to programmatically create vertex-and-edge models using Dan's Gmodel tool:
https://github.com/ibaned/gmodel
Can you post the stack trace at the failure point and upload the corresponding mesh to this issue?
I never experienced a failure directly attributable to this issue, just an invalid read reported in valgrind, which probably makes this very low priority really.
I'll see if I can scrounge up a minimal example and corresponding valgrind log sometime next week.
In a multi-scale code I'm working on I build various vertex-and-edge mds meshes from a custom file format. These meshes do not have a corresponding geometry, so I've been using the ".null"
gmi_model
(which I know isn't particularly desirable, but we have it so I've been using it) to create and copy these meshes when needed (we have a library of small serial meshes and can potentially instantiate (copy) many instances of a particular mesh for many standalone simulations).When I call
apf::createMdsMesh()
with the nullgmi_model
and one of these mds meshes valgrind reports an invalid read atgmi_lookup.c:67
. Following up on this it appears the memory location is calculated inagm_tag_at.cc:506
and dereferenced atgmi_lookup:67
.This appears to be due to the data which should be malloc'd in
agm_tag_at
being of size 0, and the index into the malloc'd memory being -1. This results in a read of size 4 (an int) before the zero malloc location (the behavior here is implementation-specific, some mallocs will give NULL for a zero allocation and we would fail at thePCU_ALWAYS_ASSERT(*data)
atagm.c:505
).What is the best way to avoid this? It hasn't created an issue for me (outside of the valgrind log being clogged up) yet but is clearly undesirable. Do we have some capability to use an mds mesh as it's own discrete model (which would be preferable I'm sure)?