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

Radim Blazek radim.blazek at gmail.com
Fri Jun 19 11:41:39 PDT 2015

On Fri, Jun 19, 2015 at 7:51 PM, Matthias Kuhn <matthias at opengis.ch> wrote:
> Hi Radim,
> Did you check that the internal offsets of the members inside the struct
> are the same?

No I did not and I would not expect that.

> Or are you accessing the members always only in one of the
> two libs?

The data are read via GRASS lib functions to which pointer to map
structure is passed as argument. Only some simple structures (composed
of int,double) are accessed directly.

> To be honest, this sounds a bit scary...

I know that even size of int is not guaranteed but that is probably
the only suspicious type and that is surely the same for MSVC and
MinGW, double is IEEE 754.


> Cheers
> Matthias
> On 06/19/2015 07:25 PM, Radim Blazek 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.
>> 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
>> _______________________________________________
>> Qgis-developer mailing list
>> Qgis-developer at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/qgis-developer

More information about the osgeo4w-dev mailing list