CGAL users discussion list

[Sebastien Loriot <>]

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