Re: [GRASS-dev] raster query/r.what error with a r.external-linked raster

[Helmut Kudrnovsky]

Helmut Kudrnovsky wrote
>>This may be an issue with GDAL itself, e.g. an external library having
>>been updated without rebuilding GDAL. If that's the case, any program
>>which calls GDALAllRegister() (e.g. "gdalinfo --formats") would
>>exhibit the same issue.
> 
> gdalinfo testraster.tif
> gdalinfo --formats
> 
> both are working.
> 
>>Alternatively, it may be an issue with GDAL and GRASS using different
>>versions of a common library (e.g. libstdc++). If you've updated any
>>system libraries, perform a full re-compile of GRASS (after "make
>>clean") and 
> 
> the debian installation is updated; several times svn up in grass and
> recompiled, same behaviour.
> 
>>and ensure that GRASS isn't built against a "private" version
>>of any system library used by GDAL. 
> 
> how could this be tested/investigated? (linux newbie here on my side)

found it. GDAL 2.0.2 is self compiled, Debian's Saga GIS is compiled 
against Debian's GDAL 1.11.x. 

Deinstalling Saga GIS, querying a linked raster in GRASS GIS works again. 





-
best regards
Helmut
--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/raster-query-r-what-error-with-a-r-external-linked-raster-tp5256308p5258590.html
Sent from the Grass - Dev mailing list archive at Nabble.com.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] raster query/r.what error with a r.external-linked raster

[Helmut Kudrnovsky]

>This may be an issue with GDAL itself, e.g. an external library having
>been updated without rebuilding GDAL. If that's the case, any program
>which calls GDALAllRegister() (e.g. "gdalinfo --formats") would
>exhibit the same issue.

gdalinfo testraster.tif
gdalinfo --formats

both are working.

>Alternatively, it may be an issue with GDAL and GRASS using different
>versions of a common library (e.g. libstdc++). If you've updated any
>system libraries, perform a full re-compile of GRASS (after "make
>clean") and 

the debian installation is updated; several times svn up in grass and
recompiled, same behaviour.

>and ensure that GRASS isn't built against a "private" version
>of any system library used by GDAL. 

how could this be tested/investigated? (linux newbie here on my side)



-
best regards
Helmut
--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/raster-query-r-what-error-with-a-r-external-linked-raster-tp5256308p5258490.html
Sent from the Grass - Dev mailing list archive at Nabble.com.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] raster query/r.what error with a r.external-linked raster

[Glynn Clements]

Helmut Kudrnovsky wrote:

> Program received signal SIGSEGV, Segmentation fault.
> 0x74418090 in vtable for __cxxabiv1::__si_class_type_info ()
>from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
> 
> (gdb) bt
> #0  0x74418090 in vtable for __cxxabiv1::__si_class_type_info ()
>from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
> #1  0x7fffed6778e3 in GDALRegister_VICAR () at vicardataset.cpp:824
> #2  0x7fffed494ded in GDALAllRegister () at gdalallregister.cpp:234

This may be an issue with GDAL itself, e.g. an external library having
been updated without rebuilding GDAL. If that's the case, any program
which calls GDALAllRegister() (e.g. "gdalinfo --formats") would
exhibit the same issue.

Alternatively, it may be an issue with GDAL and GRASS using different
versions of a common library (e.g. libstdc++). If you've updated any
system libraries, perform a full re-compile of GRASS (after "make
clean") and ensure that GRASS isn't built against a "private" version
of any system library used by GDAL.

-- 
Glynn Clements 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] raster query/r.what error with a r.external-linked raster

[Helmut Kudrnovsky]

wenzeslaus wrote
> On Tue, Mar 22, 2016 at 10:03 AM, Helmut Kudrnovsky 

> hellik@

>  wrote:
> 
>>
>> as I'm not used to compile on Linux, what may be the command to
>> compile with -ggdb? configure? make?
>>
> 
> It is a compiler flag and it can be set using before you run ./configure
> using the CFLAGS environmental variable, so e.g.
> 
> export CFLAGS="-ggdb -Wall"
> ./configure ...
> 
> see full examples here
> 
> https://grasswiki.osgeo.org/wiki/Compile_and_Install_Ubuntu


(gdb) run -rf map=es_l1_1km@bugs coordinates=4395123.966942,2799025.206612
Starting program:
/home/bugs/dev/cpp/grass7_trunk/dist.x86_64-pc-linux-gnu/bin/r.what -rf
map=es_l1_1km@bugs coordinates=4395123.966942,2799025.206612
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x74418090 in vtable for __cxxabiv1::__si_class_type_info ()
   from /usr/lib/x86_64-linux-gnu/libstdc++.so.6

(gdb) bt
#0  0x74418090 in vtable for __cxxabiv1::__si_class_type_info ()
   from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#1  0x7fffed6778e3 in GDALRegister_VICAR () at vicardataset.cpp:824
#2  0x7fffed494ded in GDALAllRegister () at gdalallregister.cpp:234
#3  0x77bcf6af in Rast_init_gdal () at gdal.c:220
#4  0x77bcf85d in Rast_get_gdal_link (
name=name@entry=0x7ffca990 "es_l1_1km", 
mapset=mapset@entry=0x7ffcaa90 "bugs") at gdal.c:317
#5  0x77bc6d49 in Rast__open_old (name=0x7ffca990 "es_l1_1km", 
mapset=0x7ffcaa90 "bugs") at open.c:272
#6  0x77bc7316 in Rast_open_old (name=, 
mapset=) at open.c:116
#7  0x00401c07 in main (argc=6639232, argv=0x7fffeda9434b)
at main.c:205
(gdb) 

tested with

System Info 
GRASS Version: 7.1.svn  
GRASS SVN revision: 68112   
Build date: 2016-03-23  
Build platform: x86_64-pc-linux-gnu 
GDAL: 2.0.2 
PROJ.4: 4.8.0   
GEOS: 3.4.2 
SQLite: 3.8.7.1 
Python: 2.7.9   
wxPython: 3.0.1.1   
Platform: Linux-3.16.0-4-amd64-x86_64-with-debian-8.3




-
best regards
Helmut
--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/raster-query-r-what-error-with-a-r-external-linked-raster-tp5256308p5257987.html
Sent from the Grass - Dev mailing list archive at Nabble.com.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] raster query/r.what error with a r.external-linked raster

[Vaclav Petras]

On Tue, Mar 22, 2016 at 10:03 AM, Helmut Kudrnovsky  wrote:

>
> as I'm not used to compile on Linux, what may be the command to
> compile with -ggdb? configure? make?
>

It is a compiler flag and it can be set using before you run ./configure
using the CFLAGS environmental variable, so e.g.

export CFLAGS="-ggdb -Wall"
./configure ...

see full examples here

https://grasswiki.osgeo.org/wiki/Compile_and_Install_Ubuntu
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] raster query/r.what error with a r.external-linked raster

[Helmut Kudrnovsky]

wenzeslaus wrote
> On Mon, Mar 14, 2016 at 4:02 PM, Helmut Kudrnovsky 

> hellik@

>  wrote:
> 
>> Module run None ['r.what', '--q', '-rf',
>> 'map=EUD_CP_DEMS_3500025000_AA@demdata', 'null=No data',
>> 'coordinates=3532112.092810,2247474.190841'] ended with
>> error
>> Process ended with non-zero return code -11. See errors in
>> the (error) output.
>>
> 
> 
> Can you run this with gdb (you need to compile with -ggdb)?
> 
>> gdb r.what
> (gdb) run -rf map=EUD_CP_DEMS_3500025000_AA@demdata
> coordinates=3532112.092810,2247474.190841
> 
> [it should segfault now]
> 
> (gdb) bt
> 
> ___
> grass-dev mailing list

> grass-dev@.osgeo

> http://lists.osgeo.org/mailman/listinfo/grass-dev

as I'm not used to compile on Linux, what may be the command to
compile with -ggdb? configure? make? 




-
best regards
Helmut
--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/raster-query-r-what-error-with-a-r-external-linked-raster-tp5256308p5257823.html
Sent from the Grass - Dev mailing list archive at Nabble.com.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev