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

[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 <massimodisasha at 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 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>
>