[Qgis-developer] Crash in thread on FILE opened by a lib compiled by MinGW
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?
It works if the library is compiled by MSVC.
Radim
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Crash in thread on FILE opened by a lib compiled by MinGW
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*);
It works if the library is compiled by MSVC.
Radim
___
Qgis-developer mailing list
Qgis-developer@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@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Crash in thread on FILE opened by a lib compiled by MinGW
On Fri, Jun 19, 2015 at 11:32 AM, Even Rouault
even.roua...@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@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@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Crash in thread on FILE opened by a lib compiled by MinGW
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.bla...@gmail.com wrote:
On Fri, Jun 19, 2015 at 11:32 AM, Even Rouault
even.roua...@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@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@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Crash in thread on FILE opened by a lib compiled by MinGW
Hi Radim,
Did you check that the internal offsets of the members inside the struct
are the same? Or are you accessing the members always only in one of the
two libs?
To be honest, this sounds a bit scary...
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.bla...@gmail.com wrote:
On Fri, Jun 19, 2015 at 11:32 AM, Even Rouault
even.roua...@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@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@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Crash in thread on FILE opened by a lib compiled by MinGW
On Fri, Jun 19, 2015 at 7:51 PM, Matthias Kuhn matth...@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.
Radim
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.bla...@gmail.com
wrote:
On Fri, Jun 19, 2015 at 11:32 AM, Even Rouault
even.roua...@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@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@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer
