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

[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 at 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 at 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 at 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 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>
>>> 
>> 
>> _______________________________________________
>> grass-dev mailing list
>> grass-dev at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/grass-dev