[osgeo4w-dev] [Qgis-developer] Crash in thread on FILE opened by a lib compiled by MinGW

[Radim Blazek]

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.

Thanks for your ideas Even and Jef
Radim

On Fri, Jun 19, 2015 at 11:49 AM, Radim Blazek <radim.blazek at gmail.com> wrote:
> On Fri, Jun 19, 2015 at 11:32 AM, Even Rouault
> <even.rouault at spatialys.com> wrote:
>> Le vendredi 19 juin 2015 11:04:39, Radim Blazek a écrit :
>>> Hi,
>>>
>>> I am trying to fix QGIS (compiled by MSVC) crashes with GRASS 7
>>> (compiled by MinGW) on Windows. I have traced down that it crashes
>>> when functions are called on a FILE structure which was created by a
>>> library (libgrass_gis.7.0.0.dll in this case) compiled by MinGW in a
>>> thread in an application compiled by MSVC. It crashes in Microsoft
>>> _lock_file(FILE *pf) where pf is casted to _FILEX:
>>>
>>>     EnterCriticalSection( &(((_FILEX *)pf)->lock) );
>>>
>>> where _FILEX is defined as
>>>
>>>     typedef struct {
>>>         FILE f;
>>>         CRITICAL_SECTION lock;
>>>     }   _FILEX;
>>>
>>> Most probably, when the file is opened in a library compiled by MinGW,
>>> it is not allocated as _FILEX but as FILE and accessing the lock is
>>> causing the crash. Does anybody have deeper insight into the problem
>>> and how to solve it?
>>>
>>> It does not happen with GRASS 6 compiled with MinGW. Are you aware of
>>> any difference between GRASS 6 and 7 build in OSGeo4W? E.g. different
>>> GCC version or compilation options?
>>
>> I cannot comment on this particular case, but in the Windows world, I believe
>> the internal layout of FILE structure is specific to the C runtime used, so you
>> cannot exchange them between different compilers. If you want to mix them, the
>> library must return an opaque pointer to the using code and provide all needed
>> functions to manipulate and free it.
>>
>> /* Opaque type */
>> typedef struct mySuperFile mySuperFile;
>>
>> mySuperFile* MyLibReturnFile(...);
>> int MyLibReadFile(mySuperFile*, ...); /* use same protype as fread() */
>> void MyLibCloseFile(mySuperFile*);
>
> Thanks for your comment. It means that I am probably on a wrong track.
> The GRASS lib in fact does all the operations on the file. Because it
> is impossible to debug a lib compiled with MinGW when QGIS is compiled
> by MSVC and it works OK with GRASS libs compiled with MSVC I have
> mixed vector lib compiled by MSVC (which I con debug) with gis lib
> compiled by MinGW, which I thought is causing the problem.
>
> I have also created new issue https://hub.qgis.org/issues/13002
> and added your comment.
>
> Radim
>
>
>>> It works if the library is compiled by MSVC.
>>>
>>> Radim
>>> _______________________________________________
>>> Qgis-developer mailing list
>>> Qgis-developer at lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>>
>> --
>> Spatialys - Geospatial professional services
>> http://www.spatialys.com