Opened 9 years ago
Closed 9 years ago
#2662 closed defect (fixed)
v.in.proj crashes on Windows (v.in.ogr problem)
| Reported by: | martinl | Owned by: | |
|---|---|---|---|
| Priority: | blocker | Milestone: | 7.0.1 |
| Component: | LibGIS | Version: | svn-releasebranch70 |
| Keywords: | v.in.proj, r.in.proj | Cc: | |
| CPU: | Unspecified | Platform: | Unspecified |
Description
v.in.proj crashes on Windows (epsg:4326 -> epsg:5514)
D2/5: file open: read (mode = r) D2/5: G__read_Cell_head D2/5: G__read_Cell_head_array D3/5: region item: proj: 3 D3/5: region item: zone: 0 D3/5: region item: north: 935275:00:27.10224S ERROR: Syntax error in cell header
on source:grass/trunk/vector/v.in.ogr/main.c#L591
This issue has been apparently fixed in trunk (where it works). The last change of get_window.c is from 2014-12-29. Any idea when it was fixed (and backported to relbr70)?
Change History (8)
comment:1 by , 9 years ago
comment:2 by , 9 years ago
I can confirm this bug also in 7.0.1svn.
BTW, daily winGRASS builds for 7.0.1svn are newly available at (1)
comment:3 by , 9 years ago
| Summary: | v.in.proj crashes on Windows → v.in.proj crashes on Windows (v.in.ogr problem) |
|---|
follow-up: 5 comment:4 by , 9 years ago
With latest build (1) I cannot reproduce this issue, v.in.proj successfully imports shapefile in EPSG:4326 to location in EPSG:5514.
Does anybody here can also test it? Thanks.
(1) http://wingrass.fsv.cvut.cz/grass70/WinGRASS-7.0.1svn-r65457-45-Setup.exe
follow-up: 6 comment:5 by , 9 years ago
Replying to martinl:
With latest build (1) I cannot reproduce this issue,
v.in.projsuccessfully imports shapefile in EPSG:4326 to location in EPSG:5514.Does anybody here can also test it? Thanks.
(1) http://wingrass.fsv.cvut.cz/grass70/WinGRASS-7.0.1svn-r65457-45-Setup.exe
any test data set?
follow-up: 7 comment:6 by , 9 years ago
Replying to hellik:
any test data set?
Just try to import data using v.in.proj to the location with different srs...
follow-up: 8 comment:7 by , 9 years ago
Replying to martinl:
Replying to hellik:
any test data set?
Just try to import data using v.in.proj to the location with different srs...
tested with
GRASS Version: 7.1.svn GRASS SVN revision: 65460 Build date: 2015-06-14 Build platform: i686-pc-mingw32 GDAL: 1.11.2 PROJ.4: 4.8.0 GEOS: 3.4.2 SQLite: 3.7.17 Python: 2.7.4 wxPython: 2.8.12.1 Platform: Windows-7-6.1.7601-SP1 (OSGeo4W)
C:\tmp>ogrinfo -al vienna.shp
INFO: Open of `vienna.shp'
using driver `ESRI Shapefile' successful.
Layer name: vienna
Geometry: Polygon
Feature Count: 1
Extent: (16.289482, 48.155973) - (16.463998, 48.275724)
Layer SRS WKT:
GEOGCS["GCS_WGS_1984",
DATUM["WGS_1984",
SPHEROID["WGS_84",6378137.0,298.257223563]],
PRIMEM["Greenwich",0.0],
UNIT["Degree",0.0174532925199433]]
g.proj -p -PROJ_INFO------------------------------------------------- name : Transverse Mercator proj : tmerc datum : hermannskogel ellps : bessel lat_0 : 0 lon_0 : 16.33333333333333 k : 1 x_0 : 750000 y_0 : 0 no_defs : defined towgs84 : 577.326,90.129,463.919,5.1366,1.4742,5.2970,2.4232 -PROJ_EPSG------------------------------------------------- epsg : 31286 -PROJ_UNITS------------------------------------------------ unit : meter units : meters meters : 1
(Sun Jun 14 21:56:04 2015) v.in.proj --verbose input_file=C:\tmp\vienna.shp output=vienna extents=input [...] (Sun Jun 14 21:56:09 2015) Befehl ausgeführt (5 Sek)
seems to work
Helmut
p.s. any chance to get back OSGeo4W-winGRASS7.0.x-daiylies; no chance to test here the standalone winGRASS7.0.x-daiylies
p.p.s https://trac.osgeo.org/grass/ticket/2634 is quite annyoing and makes winGRASS-trunk quite unusable for me ...
comment:8 by , 9 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
Replying to hellik:
> GRASS Version: 7.1.svn
please not that this bug has been possible to reproduce only in relbr70, not trunk
p.s. any chance to get back OSGeo4W-winGRASS7.0.x-daiylies; no chance to test here the standalone winGRASS7.0.x-daiylies
there are already there (1)
Closing this ticket since it seems to be "fixed".

Not sure if that matters but there is this coverity scan report:
*** CID 1262561: Unbounded source buffer (STRING_SIZE) /lib/gis/get_window.c: 65 in G_get_window() 59 if (regvar) { 60 char **tokens = G_tokenize(regvar, ";"); 61 G__read_Cell_head_array(tokens, &st->dbwindow, 0); 62 G_free_tokens(tokens); 63 } 64 else { >>> CID 1262561: Unbounded source buffer (STRING_SIZE) >>> Assigning: "wind" = "getenv". "wind" is now tainted. 65 char *wind = getenv("WIND_OVERRIDE"); 66 if (wind) 67 G_get_element_window(&st->dbwindow, "windows", wind, G_mapset()); 68 else 69 G_get_element_window(&st->dbwindow, "", "WIND", G_mapset()); 70 }