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

Massimo_Di_Stefano1 · December 6, 2013, 6:06pm

Hi,

i’m trying to run “r.stream.extract” on a little linux machine, i got got grass up and running on a small quad-core Arm 1gb ram
OS : Debian SID ArmHF.

the command i’m using is :

r.stream.extract elevation=elevation@PERMANENT accumulation=accum threshold=40 stream_rast=stream_network stream_vect=streams --o --q

location : nc_spm_08_grass7/PERMANENT/

i set the debug level to 5, this the segfault log :

https://gist.github.com/epifanio/7829206

if helpful, this is the log of make clean and make :

https://gist.github.com/epifanio/7829256

On other platform (same grass and r.stream.extract version it wks just fine)
Have you any idea on what’s wrong ?

Thanks,

Massimo.

Mohammed_Rashad · December 6, 2013, 9:16pm

Hello Massimo,

A gdb output could be more helpful for a segfault

···

On Fri, Dec 6, 2013 at 7:06 PM, epi <massimodisasha@gmail.com> wrote:

Hi,

i’m trying to run “r.stream.extract” on a little linux machine, i got got grass up and running on a small quad-core Arm 1gb ram
OS : Debian SID ArmHF.

the command i’m using is :

r.stream.extract elevation=elevation@PERMANENT accumulation=accum threshold=40 stream_rast=stream_network stream_vect=streams --o --q

location : nc_spm_08_grass7/PERMANENT/

i set the debug level to 5, this the segfault log :

https://gist.github.com/epifanio/7829206

if helpful, this is the log of make clean and make :

https://gist.github.com/epifanio/7829256

On other platform (same grass and r.stream.extract version it wks just fine)
Have you any idea on what’s wrong ?

Thanks,

Massimo.

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

–

Regards,
Rashad

Massimo_Di_Stefano1 · December 6, 2013, 9:32pm

Hi !

this the output of gdb :

Starting program: /home/epi/Envs/env1/grass-7.0.svn/bin/r.stream.extract .stream.extract elevation=elevation50m@PERMANENT accumulation=accum threshold=40 stream_rast=stream_network stream_vect=streams --o
[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.
0x2c966e68 in ?? () from /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.0.0
(gdb)

Thanks for your help!

Massimo.

···

On Fri, Dec 6, 2013 at 7:06 PM, epi <massimodisasha@gmail.com> wrote:

Hi,

i’m trying to run “r.stream.extract” on a little linux machine, i got got grass up and running on a small quad-core Arm 1gb ram
OS : Debian SID ArmHF.

the command i’m using is :

r.stream.extract elevation=elevation@PERMANENT accumulation=accum threshold=40 stream_rast=stream_network stream_vect=streams --o --q

location : nc_spm_08_grass7/PERMANENT/

i set the debug level to 5, this the segfault log :

https://gist.github.com/epifanio/7829206

if helpful, this is the log of make clean and make :

https://gist.github.com/epifanio/7829256

On other platform (same grass and r.stream.extract version it wks just fine)
Have you any idea on what’s wrong ?

Thanks,

Massimo.

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

–

Regards,
Rashad

Massimo_Di_Stefano1 · December 6, 2013, 9:37pm

i tried to add :
handle SIGILL nostop
to have more debug …

i can’t understand the log

(gdb) handle SIGILL nostop
Signal Stop Print Pass to program Description
SIGILL No Yes Yes Illegal instruction
(gdb)

(gdb) exec-file r.stream.extract elevation=elevation@PERMANENT accumulation=accum threshold=20 stream_rast=stream_network stream_vect=streams --o
(gdb) r
Starting program: /home/epi/Envs/env1/grass-7.0.svn/bin/r.stream.extract .stream.extract elevation=elevation50m@PERMANENT accumulation=accum threshold=40 stream_rast=stream_network stream_vect=streams --o
[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.
D2/5: G_file_name(): path = /home/epi/Envs/grass7data/nc_spm_08_grass7/PERMANENT

Description:
Performs stream network extraction.

Keywords:
raster, hydrology, stream network

Usage:
r.stream.extract elevation=name [accumulation=name] [depression=name]
threshold=value [d8cut=value] [mexp=value] [stream_length=value]
[memory=value] [stream_rast=name] [stream_vect=name] [direction=name]
[–overwrite] [–verbose] [–quiet]

Flags:
–o Allow output files to overwrite existing files
–v Verbose module output
–q Quiet module output

Parameters:
elevation Name of input elevation raster map
accumulation Name of input accumulation raster map
Stream extraction will use provided accumulation instead of calculating it a new
depression Name of raster map with real depressions
Streams will not be routed out of real depressions
threshold Minimum flow accumulation for streams
Must be > 0
d8cut Use SFD above this threshold
If accumulation is larger than d8cut, SFD is used instead of MFD. Applies only if no accumulation map is given.
default: infinity
mexp Montgomery exponent for slope, disabled with 0
Montgomery: accumulation is multiplied with pow(slope,mexp) and then compared with threshold.
default: 0
stream_length Delete stream segments shorter than stream_length cells.
Applies only to first-order stream segments (springs/stream heads).
default: 0
memory Maximum memory to be used in MB
default: 300
stream_rast Name for output raster map with unique stream ids
stream_vect Name for output vector map with unique stream ids
direction Name for output raster map with flow direction

ERROR: Option does not accept multiple answers
[Inferior 1 (process 7565) exited with code 01]
(gdb)

···

On Fri, Dec 6, 2013 at 7:06 PM, epi <massimodisasha@gmail.com> wrote:

Hi,

i’m trying to run “r.stream.extract” on a little linux machine, i got got grass up and running on a small quad-core Arm 1gb ram
OS : Debian SID ArmHF.

the command i’m using is :

r.stream.extract elevation=elevation@PERMANENT accumulation=accum threshold=40 stream_rast=stream_network stream_vect=streams --o --q

location : nc_spm_08_grass7/PERMANENT/

i set the debug level to 5, this the segfault log :

https://gist.github.com/epifanio/7829206

if helpful, this is the log of make clean and make :

https://gist.github.com/epifanio/7829256

On other platform (same grass and r.stream.extract version it wks just fine)
Have you any idea on what’s wrong ?

Thanks,

Massimo.

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

–

Regards,
Rashad

Massimo_Di_Stefano1 · December 6, 2013, 10:18pm

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 ?

Massimo.

···

On Fri, Dec 6, 2013 at 7:06 PM, epi <massimodisasha@gmail.com> wrote:

Hi,

i’m trying to run “r.stream.extract” on a little linux machine, i got got grass up and running on a small quad-core Arm 1gb ram
OS : Debian SID ArmHF.

the command i’m using is :

r.stream.extract elevation=elevation@PERMANENT accumulation=accum threshold=40 stream_rast=stream_network stream_vect=streams --o --q

location : nc_spm_08_grass7/PERMANENT/

i set the debug level to 5, this the segfault log :

https://gist.github.com/epifanio/7829206

if helpful, this is the log of make clean and make :

https://gist.github.com/epifanio/7829256

On other platform (same grass and r.stream.extract version it wks just fine)
Have you any idea on what’s wrong ?

Thanks,

Massimo.

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

–

Regards,
Rashad

Massimo_Di_Stefano1 · December 6, 2013, 11:33pm

i tried to rebuild grass with

CFLAGS=‘-g -Wal’
CXXFLAGS=’-g -Wal’

this the full log :

https://gist.github.com/epifanio/7833957

···

On Fri, Dec 6, 2013 at 7:06 PM, epi <massimodisasha@gmail.com> wrote:

Hi,

i’m trying to run “r.stream.extract” on a little linux machine, i got got grass up and running on a small quad-core Arm 1gb ram
OS : Debian SID ArmHF.

the command i’m using is :

r.stream.extract elevation=elevation@PERMANENT accumulation=accum threshold=40 stream_rast=stream_network stream_vect=streams --o --q

location : nc_spm_08_grass7/PERMANENT/

i set the debug level to 5, this the segfault log :

https://gist.github.com/epifanio/7829206

if helpful, this is the log of make clean and make :

https://gist.github.com/epifanio/7829256

On other platform (same grass and r.stream.extract version it wks just fine)
Have you any idea on what’s wrong ?

Thanks,

Massimo.

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

–

Regards,
Rashad

marisn · December 6, 2013, 11:36pm

Any warnings during compilation?
Try to compile with -g and -O0 to get slow but debugging-friendly version.

When program gets stopped by SIGILL in gdb, issue "bt" command to get backtrace.

No help form me, but more info never hurts

Maris.

2013/12/6 epi <massimodisasha@gmail.com>:

Hi !

this the output of gdb :

Starting program: /home/epi/Envs/env1/grass-7.0.svn/bin/r.stream.extract
.stream.extract elevation=elevation50m@PERMANENT accumulation=accum
threshold=40 stream_rast=stream_network stream_vect=streams --o
[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.
0x2c966e68 in ?? () from /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.0.0
(gdb)

Thanks for your help!

Massimo.

On Dec 6, 2013, at 4:16 PM, Rashad M <mohammedrashadkm@gmail.com> wrote:

Hello Massimo,

A gdb output could be more helpful for a segfault

On Fri, Dec 6, 2013 at 7:06 PM, epi <massimodisasha@gmail.com> wrote:

Hi,

i’m trying to run “r.stream.extract” on a little linux machine, i got got
grass up and running on a small quad-core Arm 1gb ram
OS : Debian SID ArmHF.

the command i’m using is :

r.stream.extract elevation=elevation@PERMANENT accumulation=accum
threshold=40 stream_rast=stream_network stream_vect=streams --o --q

location : nc_spm_08_grass7/PERMANENT/

i set the debug level to 5, this the segfault log :

https://gist.github.com/epifanio/7829206

if helpful, this is the log of make clean and make :

https://gist.github.com/epifanio/7829256

On other platform (same grass and r.stream.extract version it wks just
fine)
Have you any idea on what’s wrong ?

Thanks,

Massimo.

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

--
Regards,
Rashad

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

Glynn_Clements1 · December 7, 2013, 12:24am

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 <glynn@gclements.plus.com>

Massimo_Di_Stefano1 · December 7, 2013, 5:59pm

Hi Maris,

this is the bt :

(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)

rebuilding with :

gcc -g -Wall -O0

gave me no worning in r.stream.extract

On Dec 6, 2013, at 6:36 PM, Maris Nartiss <maris.gis@gmail.com> wrote:

Any warnings during compilation?
Try to compile with -g and -O0 to get slow but debugging-friendly version.

When program gets stopped by SIGILL in gdb, issue “bt” command to get backtrace.

No help form me, but more info never hurts

Maris.

2013/12/6 epi <massimodisasha@gmail.com>:

Hi !

this the output of gdb :

Starting program: /home/epi/Envs/env1/grass-7.0.svn/bin/r.stream.extract
.stream.extract elevation=elevation50m@PERMANENT accumulation=accum
threshold=40 stream_rast=stream_network stream_vect=streams --o
[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.
0x2c966e68 in ?? () from /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.0.0
(gdb)

Thanks for your help!

Massimo.

On Dec 6, 2013, at 4:16 PM, Rashad M <mohammedrashadkm@gmail.com> wrote:

Hello Massimo,

A gdb output could be more helpful for a segfault

On Fri, Dec 6, 2013 at 7:06 PM, epi <massimodisasha@gmail.com> wrote:

Hi,

i’m trying to run “r.stream.extract” on a little linux machine, i got got
grass up and running on a small quad-core Arm 1gb ram
OS : Debian SID ArmHF.

the command i’m using is :

r.stream.extract elevation=elevation@PERMANENT accumulation=accum
threshold=40 stream_rast=stream_network stream_vect=streams --o --q

location : nc_spm_08_grass7/PERMANENT/

i set the debug level to 5, this the segfault log :

https://gist.github.com/epifanio/7829206

if helpful, this is the log of make clean and make :

https://gist.github.com/epifanio/7829256

On other platform (same grass and r.stream.extract version it wks just
fine)
Have you any idea on what’s wrong ?

Thanks,

Massimo.

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

–
Regards,
Rashad

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

Massimo_Di_Stefano1 · December 7, 2013, 6:15pm

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=<optimized out>) at dl-init.c:84
#3 call_init (l=<optimized out>, 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 <glynn@gclements.plus.com> 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 <glynn@gclements.plus.com>

Massimo_Di_Stefano1 · December 8, 2013, 7:01am

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 <massimodisasha@gmail.com> 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=<optimized out>) at dl-init.c:84
#3 call_init (l=<optimized out>, 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 <glynn@gclements.plus.com> 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 <glynn@gclements.plus.com>

marisn · December 8, 2013, 9:46am

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 <massimodisasha@gmail.com>:

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 <massimodisasha@gmail.com> 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=<optimized out>) at dl-init.c:84
#3 call_init (l=<optimized out>, 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 <glynn@gclements.plus.com> 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 <glynn@gclements.plus.com>

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

Glynn_Clements1 · December 10, 2013, 10:22am

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 <glynn@gclements.plus.com>

Massimo_Di_Stefano1 · December 21, 2013, 12:18am

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.16666666666666],
    PARAMETER["standard_parallel_2",34.33333333333334],
    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 = (630000.000000000000000,228500.000000000000000)
Pixel Size = (10.000000000000000,-10.000000000000000)
Metadata:
  AREA_OR_POINT=Area
Image Structure Metadata:
  INTERLEAVE=BAND
Corner Coordinates:
Upper Left ( 630000.000, 228500.000) ( 78d46'27.41"W, 35d48'34.59"N)
Lower Left ( 630000.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=-9999
epi@udoo:~$

On Dec 10, 2013, at 11:22 AM, Glynn Clements <glynn@gclements.plus.com> 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 <glynn@gclements.plus.com>

Massimo_Di_Stefano1 · December 21, 2013, 12:32am

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 <maris.gis@gmail.com> 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 <massimodisasha@gmail.com>:

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 <massimodisasha@gmail.com> 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=<optimized out>) at dl-init.c:84
#3 call_init (l=<optimized out>, 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 <glynn@gclements.plus.com> 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 <glynn@gclements.plus.com>

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

neteler · December 21, 2013, 6:05am

On Sat, Dec 21, 2013 at 1:18 AM, epi <massimodisasha@gmail.com> 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