CGAL users discussion list

[Michael Vennettilli <>]

Hi Sebastien,

Just wanted to follow up on this. As you said, this made Valgrind give 
intelligible output when there were memory errors. I was able to fix the 
issue in my code.

Thanks for your help,

Mike

On 5/9/23 09:14, Sebastien Loriot ( via cgal-discuss 
Mailing List) wrote:
> Valgrind does not handle correct rounding mode changes done by CGAL.
>
> However, if you define CGAL_ALWAYS_ROUND_TO_NEAREST before including
> any CGAL header, then you'll get a slower version of CGAL filtering
> mechanism but not rounding mode changes (and Valgrind should be happy).
>
> Best,
>
> Sebastien.
>
> On 4/28/23 16:10, Michael Vennettilli ( via 
> cgal-discuss Mailing List) wrote:
> > Hello Sebastien,
> >
> > In short, I don't think that the map thing is actually an issue. The 
> > problem is inconsistent final geometries for fixed seeds. I am 
> > looking for ideas/ tools to track memory issues that disappear when 
> > running under Valgrind/ can't be detected by it.
> >
> > The indeterminism in ordering handles in maps is a relatively minor 
> > issue and not my main concern. I am using handles from a linear cell 
> > complex, but this only affects the ordering of the vertices, so I 
> > don't think this is the root of the problem. Unless there is 
> > something else to Handles (e.g. they shouldn't be used as values/ 
> > keys in a map) that I don't understand?
> >
> > The issue I'm concerned with is inconsistent final geometries (after 
> > applying forces). For the same initial condition and same seed, I am 
> > getting inconsistent final results (disagreements in the 9th digit of 
> > vertex positions when using doubles) when running the same 
> > executable. The problem is that the all final geometries looks 
> > believable, and tools for dynamic code analysis (Valgrind and Dr. 
> > Memory) report no errors and give no useful information. I've also 
> > implemented explicit bounds checking and type checking assertions on 
> > all set, array, vector, and map indexing, and no assertions are failed.
> >
> > Is Valgrind compatible with CGAL? I tried using a debug build with 
> > the flags:
> >
> > set(CMAKE_CXX_FLAGS_INIT "-Wall -pedantic -g -Wextra -pthread 
> > -Wconversion -O0")
> >
> > and running Valgrind with
> >
> > valgrind --leak-check=full --show-leak-kinds=all --track-origins=yes 
> > --verbose --log-file=valgrind-out.txt ./build/main
> >
> > but I get kind of useless output that looks like:
> >
> > ==87779== 16,384 bytes in 1 blocks are still reachable in loss record 
> > 6 of 6
> > ==87779==    at 0x483B7F3: malloc (in 
> > /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
> > ==87779==    by 0x6B5DE98: g_malloc (in 
> > /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6400.6)
> > ==87779==    by 0x6B687D3: ??? (in 
> > /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6400.6)
> > ==87779==    by 0x4011B99: call_init.part.0 (dl-init.c:72)
> > ==87779==    by 0x4011CA0: call_init (dl-init.c:30)
> > ==87779==    by 0x4011CA0: _dl_init (dl-init.c:119)
> > ==87779==    by 0x4001139: ??? (in /usr/lib/x86_64-linux-gnu/ld-2.31.so)
> >
> > This doesn't give me lines in the code that I've written to investigate.
> >
> > I realize I'm not exactly giving you a lot to work with, I'm still 
> > trying to find the minimal amount of code that can reproduce the 
> > error. To me, inconsistent results given the same seed and compile 
> > options point to memory issues, like reading uninitialized memory or 
> > out of bounds, but the standard tools (Valgrind and Dr. Memory) 
> > report no issues. I could study the addresses Valgrind reports in 
> > GDB, though still reachable blocks aren't a huge concern, and the 
> > contents may not be interpretable. Are there tools for dynamic code 
> > analysis tools that are compatible with CGAL structures and can point 
> > to specific lines in my code? I can also implement assertions, 
> > checking that each handle is valid before using it, but I feel like 
> > I'm running out of ideas on things to check.
> >
> > Does this clarify things? I appreciate any suggestions with this.
> >
> > Thank you,
> >
> > Mike
> >
> >
> > On 4/28/23 07:53, "Sebastien Loriot (GeometryFactory)" 
> > ( via cgal-discuss Mailing List) wrote:
> > > Hello,
> > >
> > > as soon as you are using Handles into a map you will get 
> > > non-deterministic results (IIUC this is your problem).
> > >
> > > To workaround this, we added in some packages some timestamps in 
> > > handles
> > > to avoid that kind of issue.
> > >
> > > From what data structure are the handle coming from?
> > >
> > > Best,
> > >
> > > Sebastien.
> > >
> > > On 4/18/23 11:24, Mike V ( via cgal-discuss 
> > > Mailing List) wrote:
> > > > Hello,
> > > >
> > > > The issue I mentioned in my previous email has been resolved after 
> > > > discussion with Guillaume Damiand. I am facing a broader issue with 
> > > > my code. I am using CGAL to perform mechanical simulations, and I 
> > > > am finding irreproducible results (significantly different 
> > > > positions, not just the ordering of the vertices), even with fixed 
> > > > compilation flags and random number generation. This suggests that 
> > > > I am reading from invalid or uninitialized memory.
> > > >
> > > > I was able to reduce the error (push back the disagreement to a 
> > > > later time step) by finding a place where I used a Iterator to 
> > > > index into a map whose keys were Handles. I suspect that I am doing 
> > > > this elsewhere, but it is hard to find it. This earlier mistake 
> > > > gave no errors when compiling (with regards to type mismatch), and 
> > > > running the code through Valgrind and Dr. Memory states that there 
> > > > are no leaks/ invalid reads and writes (I had to disable rounding 
> > > > checks to get these to work). Oddly enough, when I look at the 
> > > > output of running my code through Valgrind, the results are 
> > > > consistent across different compilation methods and different from 
> > > > executing the debug and release builds without Valgrind.
> > > >
> > > > I can go through my code, searching for all instances where I use a 
> > > > map or try to read memory and place a bunch of assertions there, 
> > > > but this is time consuming, and it would be nice if there was a 
> > > > systematic tool I could use to help find these errors. Does anyone 
> > > > have experience using tools to debug these kinds of issues in CGAL 
> > > > code? Is there software/ options you could recommend?
> > > >
> > > > I appreciate any advice on this.
> > > >
> > > > Thank you,
> > > >
> > > > Mike