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

[epi]

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