search

SCOREC / core

parallel finite element unstructured meshes
Other
178 stars 63 forks source link

Calling createMdsMesh(gmi_model*, apf::Mesh*) with a .null model and an mds mesh causes an invalid read #153

Open wrtobin opened 6 years ago

wrtobin commented 6 years ago

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 null gmi_model and one of these mds meshes valgrind reports an invalid read at gmi_lookup.c:67. Following up on this it appears the memory location is calculated in agm_tag_at.cc:506 and dereferenced at gmi_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 the PCU_ALWAYS_ASSERT(*data) at agm.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)?

wrtobin commented 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.

cwsmith commented 6 years ago

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?

wrtobin commented 6 years ago

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.