Re: [GRASS-dev] segfault on 'r.stream.extract' - debian armh

2013-12-20 Thread Markus Neteler 
On Sat, Dec 21, 2013 at 1:18 AM, epi  wrote:
> Sorry for the delay in answering, i  was out of town.
>
> i tried gdal directly on the grass dataset, but this custom built gdal 
> doesn’t have grass-plugin enabled.
>
> tring to build the grass-pluginn with gdal 1.10.1 and grass7 :
>
> cd gdal/frmts/grass
> make dist
> tar -zxvf gdal-grass-1.10.1.tar.gz
> cd tar -zxvf gdal-grass-1.10.1
> ./configure --with-gdal=/home/epi/Envs/env1/bin/gdal-config 
> --with-grass=/home/epi/Envs/env1/grass-7.0.svn/
>
> can’t find the grass libs :
>
> checking for G_asprintf in -lgrass_gis... no
> checking for G_putenv in -lgrass_gis.7.0.svn... no
...


I don't think that GDAL is already compliant with GRASS 7:
See http://trac.osgeo.org/gdal/ticket/2953

If this doesn't hold true, then the GDAL-GRASS plugin code should be
re-extracted as a package. To my knowledge the GDAL plugin is nothing
else than the source code extraction from main GDAL into a separate
package (to be done by the GDAL maintainers).

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

Re: [GRASS-dev] segfault on 'r.stream.extract' - debian armh

2013-12-20 Thread epi 
i tried this way :

valgrind --tool=memcheck --leak-check=yes --show-reachable=yes --num-callers=20 
--track-fds=yes --track-origins=yes r.stream.extract 
elevation=elevation50m@PERMANENT accumulation=accum threshold=40 
stream_rast=stream_network stream_vect=streams —o

this the log :


https://gist.github.com/27f7666de4eb0cf058b2


On Dec 8, 2013, at 10:46 AM, Maris Nartiss  wrote:

> As Glynn is pointing to a possible memory problem, I would suggest to
> try to run module under valgrind to see any bad fiddling with memory.
> 
> 
> No help form me,
> Maris.
> 
> 
> 2013/12/8 epi :
>> I tried to build gdal from source , without-pt support and rebuild grass 
>> (without-pg) and pointing it to the newly built gdal.
>> 
>> i had the same problem, same  log :(
>> 
>> 
>> should i try to rebuild libcripto ?
>> 
>> any help in how to debug this problem is greatly appreciated.
>> 
>> Also if you think that other modules (not just r.stream.extract) are 
>> potentially subject of segfault, let me know and ill try to run them on the 
>> NC tests dataset.
>> 
>> Thanks,
>> 
>> Massimo.
>> 
>> 
>> On Dec 7, 2013, at 1:15 PM, epi  wrote:
>> 
>>> Hi Glynn,
>>> 
>>> thanks for the detailed explanation!
>>> 
>>> is there something i can try ?
>>> 
>>> perhaps, build gdal from src and disabling postgresql support ?
>>> 
>>> Thanks a lot!
>>> 
>>> Massimo.
>>> 
>>> 
>>> 
>>> this a copy of the gdb-backtrace :
>>> 
>>> (gdb) exec-file r.stream.extract elevation=elevation50m@PERMANENT 
>>> accumulation=accum threshold=40 stream_rast=stream_network 
>>> stream_vect=streams --o
>>> (gdb) r
>>> Starting program: /home/epi/Envs/env1/grass-7.0.svn/bin/r.stream.extract
>>> [Thread debugging using libthread_db enabled]
>>> Using host libthread_db library 
>>> "/lib/arm-linux-gnueabihf/libthread_db.so.1".
>>> 
>>> Program received signal SIGILL, Illegal instruction.
>>> 0x2c99fe68 in ?? () from /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.0.0
>>> (gdb) bt
>>> #0  0x2c99fe68 in ?? () from /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.0.0
>>> Cannot access memory at address 0x0
>>> #1  0x2c99db2c in OPENSSL_cpuid_setup ()
>>>  from /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.0.0
>>> #2  0x2aab60d6 in call_init (env=0x7efff35c, argv=0x7efff354, argc=1,
>>>   l=) at dl-init.c:84
>>> #3  call_init (l=, argc=1, argv=0x7efff354, env=0x7efff35c)
>>>   at dl-init.c:34
>>> #4  0x2aab6158 in _dl_init (main_map=0x2aaca958, argc=1, argv=0x7efff354,
>>>   env=0x7efff35c) at dl-init.c:133
>>> #5  0x2aaabc62 in _dl_start_user () from /lib/ld-linux-armhf.so.3
>>> #6  0x2aaabc62 in _dl_start_user () from /lib/ld-linux-armhf.so.3
>>> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
>>> (gdb)
>>> 
>>> 
>>> 
>>> On Dec 6, 2013, at 7:24 PM, Glynn Clements  wrote:
>>> 
 
 epi wrote:
 
> googling �
> 
> is it possible that in :
> 
> http://svn.osgeo.org/grass/grass/trunk/raster/r.stream.extract/
> 
> there may be some assembly code that gets executed which won't work under 
> armhf  ?
 
 GRASS doesn't use assembly. And the SIGILL is reported as occurring in
 libcrypto, not in the GRASS code.
 
 The libcrypto dependency typically exists because GDAL links to libpq
 (PostgreSQL client library) which uses libcrypto for certain
 authentication methods.
 
 libcrypto probably isn't even being used in this situation, so I
 suspect that a bug is causing either a function pointer or a return
 address to be corrupted, resulting in a jump to a random memory
 location which just happens to be inside libcrypto.
 
 As r.stream.extract is relatively new, it's possible that it hasn't
 seen significant testing on platforms other than x86 and x86-64. Apart
 from anything else, alignment bugs won't show up on those platforms
 (x86 supports unaligned access, ARM doesn't AFAIK).
 
 --
 Glynn Clements 
>>> 
>> 
>> ___
>> grass-dev mailing list
>> grass-dev@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/grass-dev

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

Re: [GRASS-dev] segfault on 'r.stream.extract' - debian armh

2013-12-20 Thread epi 
Sorry for the delay in answering, i  was out of town.

i tried gdal directly on the grass dataset, but this custom built gdal doesn’t 
have grass-plugin enabled.

tring to build the grass-pluginn with gdal 1.10.1 and grass7 :

cd gdal/frmts/grass
make dist
tar -zxvf gdal-grass-1.10.1.tar.gz 
cd tar -zxvf gdal-grass-1.10.1
./configure --with-gdal=/home/epi/Envs/env1/bin/gdal-config 
--with-grass=/home/epi/Envs/env1/grass-7.0.svn/

can’t find the grass libs :


checking for G_asprintf in -lgrass_gis... no
checking for G_putenv in -lgrass_gis.7.0.svn... no
configure: error: --with-grass=/home/epi/Envs/env1/grass-7.0.svn/ requested, 
but libraries not found!  Perhaps you need to set LD_LIBRARY_PATH to include 
/home/epi/Envs/env1/grass-7.0.svn//lib?



i also tried :
export LD_LIBRARY_PATH=/home/epi/Envs/env1/grass-7.0.svn/lib:$LD_LIBRARY_PATH

or adding :  
/home/epi/Envs/env1/grass-7.0.svn/lib

in /etc/ld.so.conf.d/grass.conf

but i got the same log, i think to remember tahat gdal-grass is not compatible 
with grass70.


in any case I just tried gdalinfo on a standard geotiff (i used the the GTiff 
from the grass dataset) and it works fine :


epi@udoo:~$ which gdalinfo
/home/epi/Envs/env1/bin/gdalinfo
epi@udoo:~$ cd
epi@udoo:~$ gdalinfo basin_50K.tif 
Driver: GTiff/GeoTIFF
Files: basin_50K.tif
Size is 1500, 1350
Coordinate System is:
PROJCS["Lambert Conformal Conic",
GEOGCS["NAD83",
DATUM["North_American_Datum_1983",
SPHEROID["GRS 1980",6378137,298.2572221010002,
AUTHORITY["EPSG","7019"]],
AUTHORITY["EPSG","6269"]],
PRIMEM["Greenwich",0],
UNIT["degree",0.0174532925199433],
AUTHORITY["EPSG","4269"]],
PROJECTION["Lambert_Conformal_Conic_2SP"],
PARAMETER["standard_parallel_1",36.16],
PARAMETER["standard_parallel_2",34.34],
PARAMETER["latitude_of_origin",33.75],
PARAMETER["central_meridian",-79],
PARAMETER["false_easting",609601.22],
PARAMETER["false_northing",0],
UNIT["metre",1,
AUTHORITY["EPSG","9001"]]]
Origin = (63.000,228500.000)
Pixel Size = (10.000,-10.000)
Metadata:
  AREA_OR_POINT=Area
Image Structure Metadata:
  INTERLEAVE=BAND
Corner Coordinates:
Upper Left  (  63.000,  228500.000) ( 78d46'27.41"W, 35d48'34.59"N)
Lower Left  (  63.000,  215000.000) ( 78d46'28.63"W, 35d41'16.54"N)
Upper Right (  645000.000,  228500.000) ( 78d36'29.89"W, 35d48'33.08"N)
Lower Right (  645000.000,  215000.000) ( 78d36'32.01"W, 35d41'15.03"N)
Center  (  637500.000,  221750.000) ( 78d41'29.49"W, 35d44'54.91"N)
Band 1 Block=1500x1 Type=Int32, ColorInterp=Gray
  NoData Value=-
epi@udoo:~$ 


 
On Dec 10, 2013, at 11:22 AM, Glynn Clements  wrote:

> 
> epi wrote:
> 
>> thanks for the detailed explanation!
>> 
>> is there something i can try ?  
> 
> Does GDAL itself work? Try running one of its utilities, e.g. 
> gdalinfo.
> 
> -- 
> Glynn Clements 

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

Re: [GRASS-dev] r.null apparently doesn't work on vrt via r.external on G7

2013-12-20 Thread Markus Neteler 
Hi,

I have merged the ML comments into the manual, see
r58497.

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

[GRASS-dev] [GRASS GIS] #2146: t.register fails to register maps with relative time stamp set by r/v/r3.timestamp module

2013-12-20 Thread GRASS GIS 
#2146: t.register fails to register maps with relative time stamp set by
r/v/r3.timestamp module
---+
 Reporter:  annakrat   |   Owner:  grass-dev@…  
 Type:  defect |  Status:  new  
 Priority:  minor  |   Milestone:  7.0.0
Component:  Temporal   | Version:  svn-trunk
 Keywords:  t.register, timestamp  |Platform:  Unspecified  
  Cpu:  Unspecified|  
---+
 Module t.register fails here
 source:grass/trunk/lib/python/temporal/register.py#L102 when I try to use
 the new feature of t.register to use the time stamps previously assigned
 by r.timestamp (r58084). It fails for relative time stamp. If I specify
 unit parameter, it is registered correctly, but the unit is already given
 in the timestamp so it shouldn't require it.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] xganim: fix compilation or remove completely?

2013-12-20 Thread Vaclav Petras 
On Fri, Dec 20, 2013 at 10:26 AM, Glynn Clements
wrote:

>
> Vaclav Petras wrote:
>
> > xganim removed in r58484 and r58487.
>
> Do we want to keep wximgview (I believe that it has been superseded by
> wximgview.py)? If not, we can remove the wxWidgets configure checks
> altogether.
>

Good point, we have now:

ximgview (visualization/ximgview/)
wximgview (visualization/wximgview/)
wxpyimgview (scripts/wxpyimgview/)

For sure, we don't need all three and wximgview is C++ and wxWidgets (so it
does not fit to our C+Python+wxPython). The only question is if wxpyimgview
is as fast as wximgview. Speed is the only reason why they exists, isn't it?

I'm wondering if somebody is using at least one of them.

Vaclav


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

Re: [GRASS-dev] xganim: fix compilation or remove completely?

2013-12-20 Thread Glynn Clements 

Vaclav Petras wrote:

> xganim removed in r58484 and r58487.

Do we want to keep wximgview (I believe that it has been superseded by
wximgview.py)? If not, we can remove the wxWidgets configure checks
altogether.

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

Re: [GRASS-dev] r.null apparently doesn't work on vrt via r.external on G7

2013-12-20 Thread Glynn Clements 

Margherita Di Leo wrote:

> Is it an expected behaviour that r.null doesn't affect vrt raster linked
> via r.external?

Yes.

r.null manipulates the null bitmap directly. GDAL-linked (r.external)
maps don't have or use a null bitmap; null cells are those whose value
matches the value reported by the GDALGetRasterNoDataValue() function.

You'll need to either create a mask (e.g. with r.mask) then "apply" it
using e.g. r.resample, or use r.mapcalc to create a copy with the
appropriate categories changed to null, e.g.

r.mapcalc "mosaic.new = if(mosaic==0||mosaic==2||mosaic==3,null(),mosaic)"

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

Re: [GRASS-dev] rules for testing GUI components for encoding errors before commit ?

2013-12-20 Thread Moritz Lennert 

On 18/12/13 09:57, Moritz Lennert wrote:

Hi,

I just posted a bug report about encoding issues in the new Vector
network analysis tool [1].

More generally: I regularly get these kinds of encoding errors in the
 wxGUI. And I guess some of them only show up once translators have
translated the strings of a new module. Maybe we should try to define
 some general rules / a how-to about testing new GUI components for
such potential encoding issues. We could also propose a toolkit in
form of example strings to put into the code, or through the
obligation to test with at least two .po files in languages with
special characters.

What do the GUI developers think about this ?


Here's some more from the related bug ticket:

>Replying to [comment:1 annakrat]:

This particular error should be fixed in r58490. There was an empty
translatable string which resulted in some garbage.
However, once certain strings get translated, you will get such
errors again from multiple places. The code is pretty complex,
converting to string is there multiple times and I am not sure how to
fix this. In general, I don't really understand how to deal with this
issue and how to test it correctly.




I don't think there is one good way to fix this, but if we could
propose a test protocol that allows developers to quickly test their
work for different locale settings then maybe it would make it
easier to avoid such issues in the first place.


But as I'm not a GUI developer, I'd like some feedback on what those who 
are would find most useful. As a start, new developments should be 
tested in different locales, but as translation generally come later, it 
might be good practice to fill a .po file with artificial non-ascii 
strings and to test the module against those.


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

Re: [GRASS-dev] [GRASS GIS] #2145: wxGUI network analysis tool: fails to launch in French locale

2013-12-20 Thread GRASS GIS 
#2145: wxGUI network analysis tool: fails to launch in French locale
---+
  Reporter:  mlennert  |   Owner:  grass-dev@…  
  Type:  defect|  Status:  closed   
  Priority:  normal|   Milestone:  7.0.0
 Component:  wxGUI | Version:  svn-trunk
Resolution:  fixed |Keywords:  network analysis tool
  Platform:  Linux | Cpu:  Unspecified  
---+
Changes (by mlennert):

  * status:  new => closed
  * resolution:  => fixed


Comment:

 Replying to [comment:1 annakrat]:
 > This particular error should be fixed in r58490. There was an empty
 translatable string which resulted in some garbage.

 Thanks. I can confirm the fix. Closing this bug.

 > However, once certain strings get translated, you will get such errors
 again from multiple places. The code is pretty complex, converting to
 string is there multiple times and I am not sure how to fix this. In
 general, I don't really understand how to deal with this issue and how to
 test it correctly.

 I don't think there is one good way to fix this, but if we could propose a
 test protocol that allows developers to quickly test their work for
 different locale settings then maybe it would make it easier to avoid such
 issues in the first place.

 Moritz

-- 
Ticket URL: 
GRASS GIS 

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