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: grass-dev@…
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 neteler, 9 years ago

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         }

comment:2 by martinl, 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)

(1) http://wingrass.fsv.cvut.cz/grass70/

comment:3 by martinl, 9 years ago

Summary: v.in.proj crashes on Windowsv.in.proj crashes on Windows (v.in.ogr problem)

comment:4 by martinl, 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

in reply to:  4 ; comment:5 by hellik, 9 years ago

Replying to martinl:

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

any test data set?

in reply to:  5 ; comment:6 by martinl, 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...

in reply to:  6 ; comment:7 by hellik, 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 ...

in reply to:  7 comment:8 by martinl, 9 years ago

Resolution: fixed
Status: newclosed

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".

(1) http://wingrass.fsv.cvut.cz/grass70/

Note: See TracTickets for help on using tickets.