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

[Maris Nartiss]

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