Bug report #874

Windows - Crash when creatin new mapset in GRASS with custom proyection with +towgs84

Added by Fernando Pacheco - almost 17 years ago. Updated about 15 years ago.

Status:Closed
Priority:Low
Assignee:Magnus Homann
Category:GRASS
Affected QGIS version: Regression?:No
Operating System:Windows Easy fix?:No
Pull Request or Patch supplied: Resolution:fixed
Crashes QGIS or corrupts data: Copied to github as #:10933

Description

In Windows, QGis crash when the user trying to create a new mapset with a custom projection containing the parameter +towgs84. There is no problem in Linux.

To reproduce this bug:

1-run Qgis in Windows;

2-create a custom projection in QGis. For example ROU-USAM (Uruguay): +proj=tmerc +lat_0=-90 +lon_0=-55.8 +k=1.000000000 +x_0=500000 +y_0=0 +ellps=intl +towgs84=-155,171,37,0,0,0,0 +units=m +no_defs;

3-establish this or another projection in QGis;

4-begin to create a new mapset with GRASS (database,location, mapset). When you set the projection created in step 1, QGis crash.

Thanks. Fernando.

History

#1 Updated by Magnus Homann almost 17 years ago

  • Status changed from Open to In Progress

#2 Updated by Magnus Homann almost 17 years ago

This seems to be some sort of GRASS error. qgsgrassnewmapset calls GPJ_osr_to_grass
and it appears that the crash is somewhere there.

This is the last output from WinXP before crash, see the (null) at last line:

Debug: c:/Qgis-devel/qgis_trunk/src/gui/qgsprojectionselector.cpp: 276: (getCurrentProj4String) mySrsId = 100000
Debug: c:/Qgis-devel/qgis_trunk/src/gui/qgsprojectionselector.cpp: 277: (getCurrentProj4String) USER_PROJECTION_START_ID = 100000
Debug: c:/Qgis-devel/qgis_trunk/src/gui/qgsprojectionselector.cpp: 294: (getCurrentProj4String) users qgis.db found
Debug: c:/Qgis-devel/qgis_trunk/src/gui/qgsprojectionselector.cpp: 301: (getCurrentProj4String) db = C:/Documents and Settings/homann/.qgis/
qgis.db
Debug: c:/Qgis-devel/qgis_trunk/src/gui/qgsprojectionselector.cpp: 320: (getCurrentProj4String) Selection sql: select parameters from tbl_sr
s where srs_id = 100000
Item selected : [[CrashTest]]
Item selected full string : +proj=tmerc +lat_0=-90 +lon_0=-55.8 +k=1.000000000 +x_0=500000 +y_0=0 +ellps=intl +towgs84=-155,171,37,0,0,0,0 +
units=m +no_defs
proj4 = +proj=tmerc +lat_0=-90 +lon_0=-55.8 +k=1.000000000 +x_0=500000 +y_0=0 +ellps=intl +towgs84=-155,171,37,0,0,0,0 +units=m +no_defs
OSRIsGeographic = 0
OSRIsProjected = 1
wkt = PROJCS[[unnamed"GEOGCS["International 1909 (Hayford)"DATUM["unknown"SPHEROID["intl]],PRIM
EM[[Greenwich"0]UNIT["degree"00174532925199433]]PROJECTION["Transverse_Mercator"]PARAMETER["latitude_of_origin]],PARAMETER["centra
l_meridian",-55.8],PARAMETER[[scale_factor"1]PARAMETER["false_easting"500000]PARAMETER["false_northing"0]UNIT["Meter]]
error_routine (fatal = 0): unable to open datum table file: (null)
No such file or directory

Program received signal SIGSEGV, Segmentation fault.
0x77c423e4 in wscanf () from /cygdrive/c/WINDOWS/system32/msvcrt.dll

Crash in wscanf due to nonexistinging file?

#3 Updated by Magnus Homann almost 17 years ago

In Ubuntu, I moved the file //usr/lib/grass/etc/datum.table, and got similar response. No crash, however. Notice that file name is present

Debug: /home/homann/Qgis-Devel/qgis_trunk/src/gui/qgsprojectionselector.cpp: 320: (getCurrentProj4String) Selection sql: select parameters from tbl_srs where srs_id = 100007
Item selected : SWEREF 99 TM
Item selected full string : +proj=tmerc +lat_0=0 +lon_0=15 +k=0.9996 +x_0=500000 +y_0=0 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs
proj4 = +proj=tmerc +lat_0=0 +lon_0=15 +k=0.9996 +x_0=500000 +y_0=0 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs
OSRIsGeographic = 0
OSRIsProjected = 1
wkt = PROJCS[[unnamed"GEOGCS["GRS 1980(IUGG 1980)"DATUM["unknown"SPHEROID["GRS80"6378137298257222101]TOWGS84r0000000]PRIMEM["Greenwich"0]UNIT["degree"00174532925199433]]PROJECTION["Transverse_Mercator"]PARAMETER["latitude_of_origin"0]PARAMETER["central_meridian"15]PARAMETER["scale_factor"09996]PARAMETER["false_easting"500000]PARAMETER["false_northing"0]UNIT["Meter]]
error_routine (fatal = 0): unable to open datum table file: /usr/lib/grass/etc/datum.table
ret = 2
mProjInfo = 0x8c75120

#4 Updated by Markus Neteler almost 17 years ago

The datum file is searched in $GISBASE/etc/datum.table". I suspect that it is missing there or unaccessible? It should work since the native winGRASS version also works.

Other source of error: white space in the path of $GISBASE - if so, please let the GRASS team know.

Markus

#5 Updated by Markus Neteler almost 17 years ago

Note: the error is generated in grass63/lib/gis/datum.c

#6 Updated by Marco Pasetti - over 16 years ago

  • Status changed from In Progress to Closed
  • Resolution set to fixed

#7 Updated by Anonymous about 15 years ago

Milestone Version 0.9.2 deleted

Also available in: Atom PDF