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