[GRASS-dev] Debugging QGIS with GRASS provider on Windows

[Radim Blazek]

On Sun, Jun 21, 2015 at 4:32 AM, Glynn Clements
<glynn at gclements.plus.com> wrote:
>
> Helmut Kudrnovsky wrote:
>
>> "Finally I found it, it is similar story like with FILE.
>>
>> The provider (MSVC) calls Vect__open_old with struct Map_info variable
>> allocated in the provider where sizeof(struct Map_info) = 1408.
>> Vect__open_old (MinGW) calls G_zero on that variable, where
>> sizeof(struct Map_info) = 1520.
>>
>> It means that all structures used in GRASS libs must be also allocated
>> in GRASS. New functions like Vect_alloc_map have to be added to GRASS
>> and until it gets to GRASS and to OSGeo4w, the the structures must be
>> be allocated in the provider with enough space.
>>
>> Strange thing that it came up only now with GRASS 7 and threads.
>
> You need to get both compilers to use the same ABI.
>
> The "alternative" is to treat all structures as opaque, which isn't
> going to happen. It isn't sufficient to have GRASS allocate and free
> everything, you also can't access any fields directly, you'd need
> setters and getters for everything.

The problem was with Map_info structure which is accessed only through
GRASS lib. The structures accessed directly (line_pnts,line_cats) have
only int or double or pointers to them. In theory the size of int may
be different for different compilers, but in this case it is the same
and it is quite rare to have GRASS and QGIS compiled by two compilers
with different size of int.

I could not find a function for Map_info allocation, I am missing
Vect_new_map_struct and Vect_destroy_map_struct.

> Given the numbers, my first guess is that MinGW is using 8 bytes for
> off_t versus 4 bytes for MSVC. Yep; the bottom of config.h.in has:
>
>         #if defined(__MINGW32__)
>
>         /* add/remove as needed */
>         /* redefine off_t */
>         #include <sys/types.h>
>         #define off_t off64_t
>
> And that's unaffected by --disable-largefile.
>
> This specific issue may just need changing __MINGW32__ to WIN32 (or
> _WIN32 or _WINNT, all of which are defined by MinGW) so that MSVC gets
> the same treatment. Failing that, some way to disable LFS (e.g. making
> MinGW builds honour --disable-largefile) is needed.
>
> The FILE issues are presumably due to mismatches between different
> versions of the MSVCRT library.
>
> malloc() and free() have the same
> issue: heap data must be freed by the same version of MSVCRT which
> allocated it (NVIZ originally had issues with passing Tcl_Alloc()d
> pointers directly to free() instead of Tcl_Free(), which fails if Tcl
> uses a different version of MSVCRT to GRASS).
>
> I don't know whether it's possible to change the version of MSVCRT
> which MinGW uses. If not, then we'll need to look at why files opened
> by lib/gis functions are being read/written by user code. But it would
> be preferable if FILE* could be passed around.

The problem with FILE (in my case - QGIS) was false alarm, it happened
when I mixed GRASS gis lib compiled by MinGW and vector lib compiled
by MSVC to be able to debug vect lib.

Radim