Bug report #8588

problems with grass plug-in on QGIS 64bit

Added by Alessandro Ciali about 7 years ago. Updated about 7 years ago.

Status:Closed
Priority:Severe/Regression
Assignee:Jürgen Fischer
Category:GRASS
Affected QGIS version:master Regression?:No
Operating System:windows Easy fix?:No
Pull Request or Patch supplied:No Resolution:up-/downstream
Crashes QGIS or corrupts data:Yes Copied to github as #:17330

Description

On 64bit version of QGIS under windows, grass plugin doesn't work. Program crashes and a minidump is generated. Also Grass command under processing toolbox do not work. 1.8 and last master are affected. Is it a known iussue?

History

#1 Updated by Giovanni Manghi about 7 years ago

I can confirm the issue on QGIS 64bit/osgeo4w. GRASS itself works, so it should really be a QGIS issue. Hopefully is a packaging issue.

#2 Updated by Radim Blazek about 7 years ago

What exactly does not work?
  • GRASS layers visualization?
  • GRASS modules from plugin GUI?
  • GRASS modules from QGIS GRASS shell?

Isn't it possible that 64bit modules are run with 32bit libs or vice versa? I am just guessing. The path to GRASS modules is taken from WINGISBASE or GISBASE environment variables or from /GRASS/gisbase QGIS settings. The path to libs should be set in qgis.bat.

Try to verify if your QGIS registry /GRASS/gisbase does not point to 32bit version and path in qgis.bat is correct etc.

#3 Updated by Giovanni Manghi about 7 years ago

Radim Blazek wrote:

What exactly does not work?
  • GRASS layers visualization?
  • GRASS modules from plugin GUI?
  • GRASS modules from QGIS GRASS shell?

opening a mapset qgis crashes
creating a mapset qgis crashes (when selecting the CRS)

in sextante when opening a grass module the result is

g.proj.exe has stopped working

grass itself works.

Isn't it possible that 64bit modules are run with 32bit libs or vice versa? I am just guessing. The path to GRASS modules is taken from WINGISBASE or GISBASE environment variables or from /GRASS/gisbase QGIS settings. The path to libs should be set in qgis.bat.

Try to verify if your QGIS registry /GRASS/gisbase does not point to 32bit version and path in qgis.bat is correct etc.

this is qgis-dev.bat

@echo off
call "%~dp0\\o4w_env.bat" 
call "%OSGEO4W_ROOT%"\\apps\\grass\\grass-6.4.3\\etc\\env.bat
@echo off
path %PATH%;%OSGEO4W_ROOT%\\apps\\qgis-dev\\bin;%OSGEO4W_ROOT%\\apps\\grass\\grass-6.4.3\\lib
set QGIS_PREFIX_PATH=%OSGEO4W_ROOT:\\=/%/apps/qgis-dev
set GDAL_FILENAME_IS_UTF8=YES
rem Set VSI cache to be used as buffer, see #6448
set VSI_CACHE=TRUE
set VSI_CACHE_SIZE=1000000
start "QGIS" /B "%OSGEO4W_ROOT%"\\bin\\qgis-dev-bin.exe %*

#4 Updated by Steven Horner about 7 years ago

I get the same problem when trying to run a GRASS module from within Sextante (r.los) in my case. This happens on both latest weekly 64bit build in Windows and in nightly build in Ubuntu.

I get the same message as you in Windows and I get no message in Ubuntu it just freezes up.

#5 Updated by Jürgen Fischer about 7 years ago

  • Assignee set to Jürgen Fischer

#6 Updated by Radim Blazek about 7 years ago

Can you add debug output from DebugView here? Everything it prints after you click OK in open mapset dialog until it crashes.

#7 Updated by Steven Horner about 7 years ago

I'm not sure if this is any help but when running the nightly build 64bit under Ubuntu.
If I try to run r.los under processing (Sextante) I click r.los and I am stuck with the loading symbol. The following are the logs.

INFO:

GRASS execution commands
g.proj -c proj4="+proj=utm +zone=30 +ellps=intl +towgs84=-87,-98,-121,0,0,0,0 +units=m +no_defs" 
v.in.ogr min_area=0.0001 snap=-1 dsn="/usr/share/qgis/python/plugins/processing/tests/data" layer=points output=tmp1378754122122 --overwrite -o
g.region n=4458983.8488 s=4458921.97814 e=270855.745301 w=270778.60198 res=1
v.voronoi input=tmp1378754122122 output=outputb9f4a9a889314855adeed21adb5c88df --overwrite
v.out.ogr -e input=outputb9f4a9a889314855adeed21adb5c88df dsn="/tmp/processing/e68aaf5c8baa43aab482769f249b0f8c" format=ESRI_Shapefile olayer=output type=auto

ALGORITHM:

processing.runalg("grass:v.voronoi","/usr/share/qgis/python/plugins/processing/tests/data/points.shp",False,False,"270778.60198,270855.745301,4458921.97814,4458983.8488",-1,0.0001,0,None)

I will try running from within GRASS in QGIS

#8 Updated by Gerhard Spieles about 7 years ago

Path in qgis-dev.bat leads to directory OSGEO4W --> = 32 bit.
The standard path for 64bit is "OSGEO4W64".
Maybe, that is an issue?
Gerhard

#9 Updated by Giovanni Manghi about 7 years ago

Gerhard Spieles wrote:

Path in qgis-dev.bat leads to directory OSGEO4W --> = 32 bit.
The standard path for 64bit is "OSGEO4W64".
Maybe, that is an issue?
Gerhard

I have installed the 64bit osgeo4w stack in c:\\osgeo4w and got the same issues.

#10 Updated by Jürgen Fischer about 7 years ago

  • Status changed from Open to Closed
  • Resolution set to up-/downstream

Try grass-6.4.3-3. Still this is a packaging problem in OSGeo4W (probably due to mingw64 being able to link .lib files, but producing broken binaries in that case) and not a qgis problem.

#11 Updated by Alessandro Ciali about 7 years ago

Installed grass 6.4.3-3, I confirm that Qgis 64bit on win7 now is working fine.
Thanks

Also available in: Atom PDF