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@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....@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 <massimodisa...@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 <massimodisa...@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@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 <gl...@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 <gl...@gclements.plus.com> >>> >> >> _______________________________________________ >> grass-dev mailing list >> grass-dev@lists.osgeo.org >> http://lists.osgeo.org/mailman/listinfo/grass-dev _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev