[GRASS-dev] Debugging, parallelism, etc.

[Maris Nartiss]

There is no issue with supporting both OpenMP and pthreads as most of
libraries use neither of them. There are a few modules with some
parallelism implemented and in such case they use only one of options
thus bypassing any compatibility issues per se.

As for valgrind noise – it comes from design decisions made decades a
go – each module is a short running independent program and thus it is
left to OS to reclaim memory at exit. Analysis tools sometimes also
report potential uninitialized use but in cases that can not be
reached during a normal GRASS module run. Unfortunately improving
GRASS quite often is like restoring an ancient artefact where it is
hard to tell bugs from features apart.

Māris.

svētd., 2022. g. 9. okt., plkst. 19:37 — lietotājs Brad ReDacted
(<brad.redacted at outlook.com>) rakstīja:
>
> Hello,
>
> I'm working on adding parallelism to modules, but debugging is turning
> out to be a logistical nightmare:
>
> Why do I not get any reporting from GCC option '-fsanitize=address|thread"?
>
> I am also having trouble getting the profiler to work properly inside
> GRASS (I assume due to shell?). The gmon.out file produced has no usable
> data.
>
> OpenMP is extremely poorly supported by most tools. valgrind with
> helgrind reports a lot of nonsense. I can't seem to get the Intel linux
> tools to work properly, either.
>
> BTW, we are supporting both pthreads and OpenMP. While this isn't an
> issue in most cases, there can be races and deadlocks if not handled
> properly. Pthreads aren't entirely portable. OpenMP is. However,
> pthreads gives us a more control. May I suggest using OpenMP for most
> modules and reserve Pthreads to libraries, etc? Or should we start
> moving away from pthreads?
>
> Any suggestions would be greatly appreciated!
>
>
> --
> Best Regards,
> -Brad
>
> _______________________________________________
> grass-dev mailing list
> grass-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev