Re: [GRASS-dev] segfault on 'r.stream.extract' - debian armh
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 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=) at dl-init.c:84 > #3 call_init (l=, 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 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 > ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Is the dash a Mapset naming restriction?
"g.mlist rast pat=hpf* mapset=pre-processing_post" gives a "Segmentation fault". Is the dash an unwanted character in naming Mapsets? I don't see a segfault with "normal" Mapset names. Nikos ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] trying to compile GRASS 7 on Mavericks
Did a bit of checking. ODBC is no longer shipped with Mavericks. Need to install unixodbc is the note I saw. Michael C. Michael Barton Director, Center for Social Dynamics & Complexity Professor of Anthropology, School of Human Evolution & Social Change Arizona State University voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC) fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC) www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu On Dec 7, 2013, at 2:42 PM, William Kyngesburye wrote: > Maybe the headers are missing? > > /usr/include/iodbc*.h > > On Dec 7, 2013, at 3:38 PM, Michael Barton wrote: > >> Just found libiodb* in /usr/lib >> >> Maybe just need to specify a path to it? >> >> --with-odbc worked find prevously but does not configure now. >> >> Michael >> >> C. Michael Barton >> Director, Center for Social Dynamics & Complexity >> Professor of Anthropology, School of Human Evolution & Social Change >> Arizona State University >> >> voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC) >> fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC) >> www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu >> >> >> >> >> >> >> >> >> >> >> >> >> On Dec 7, 2013, at 11:27 AM, William Kyngesburye >> wrote: >> >>> On Dec 7, 2013, at 12:04 PM, Michael Barton wrote: >>> Additional good news. I grabbed a copy of the old packagemaker.app from the XCode 4 auxtools, dropped it into /Developer/Aux_tools/ (where I had it before), and it seems to work find for making a GRASS 7 package. >>> Another casualty in Xcode. We need to figure out how to use the new >>> packaging tools. Packagemaker was deprecated in Xcode 4 in favor of more >>> raw tools (which are also necessary for signing): pkgbuild, productbuild >>> and pkgutil. I found a stackoverflow question with some good info to start >>> with, I just haven't sat down and tried anything yet. >>> >>> http://stackoverflow.com/questions/11487596/making-os-x-installer-packages-like-a-pro-xcode4-developer-id-mountain-lion-re >>> Now I just need to get odbc and gettext to configure again and I'm back in business. odbc seems to be in /Library/ODBC Can I just add --with-odbc="/Library/ODBC" in the configure string? >>> /Library/ODBC is just for ODBC drivers. >>> >>> ODBC should still be iODBC, and --with-odbc should be enough. Unless Apple >>> completely reorganized iODBC. Is libiodbc.dylib in /Library/ODBC? Are >>> headers in there? >>> >>> >>> - >>> William Kyngesburye >>> http://www.kyngchaos.com/ >>> >>> "History is an illusion caused by the passage of time, and time is an >>> illusion caused by the passage of history." >>> >>> - Hitchhiker's Guide to the Galaxy >>> >>> >> > > - > William Kyngesburye > http://www.kyngchaos.com/ > > "This is a question about the past, is it? ... How can I tell that the past > isn't a fiction designed to account for the discrepancy between my immediate > physical sensations and my state of mind?" > > - The Ruler of the Universe > > ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] trying to compile GRASS 7 on Mavericks
Maybe the headers are missing? /usr/include/iodbc*.h On Dec 7, 2013, at 3:38 PM, Michael Barton wrote: > Just found libiodb* in /usr/lib > > Maybe just need to specify a path to it? > > --with-odbc worked find prevously but does not configure now. > > Michael > > C. Michael Barton > Director, Center for Social Dynamics & Complexity > Professor of Anthropology, School of Human Evolution & Social Change > Arizona State University > > voice:480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC) > fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC) > www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu > > > > > > > > > > > > > On Dec 7, 2013, at 11:27 AM, William Kyngesburye > wrote: > >> On Dec 7, 2013, at 12:04 PM, Michael Barton wrote: >> >>> Additional good news. I grabbed a copy of the old packagemaker.app from the >>> XCode 4 auxtools, dropped it into /Developer/Aux_tools/ (where I had it >>> before), and it seems to work find for making a GRASS 7 package. >>> >> Another casualty in Xcode. We need to figure out how to use the new >> packaging tools. Packagemaker was deprecated in Xcode 4 in favor of more >> raw tools (which are also necessary for signing): pkgbuild, productbuild and >> pkgutil. I found a stackoverflow question with some good info to start >> with, I just haven't sat down and tried anything yet. >> >> http://stackoverflow.com/questions/11487596/making-os-x-installer-packages-like-a-pro-xcode4-developer-id-mountain-lion-re >> >>> Now I just need to get odbc and gettext to configure again and I'm back in >>> business. >>> >>> odbc seems to be in /Library/ODBC >>> Can I just add --with-odbc="/Library/ODBC" in the configure string? >>> >> /Library/ODBC is just for ODBC drivers. >> >> ODBC should still be iODBC, and --with-odbc should be enough. Unless Apple >> completely reorganized iODBC. Is libiodbc.dylib in /Library/ODBC? Are >> headers in there? >> >> >> - >> William Kyngesburye >> http://www.kyngchaos.com/ >> >> "History is an illusion caused by the passage of time, and time is an >> illusion caused by the passage of history." >> >> - Hitchhiker's Guide to the Galaxy >> >> > - William Kyngesburye http://www.kyngchaos.com/ "This is a question about the past, is it? ... How can I tell that the past isn't a fiction designed to account for the discrepancy between my immediate physical sensations and my state of mind?" - The Ruler of the Universe ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] trying to compile GRASS 7 on Mavericks
Just found libiodb* in /usr/lib Maybe just need to specify a path to it? --with-odbc worked find prevously but does not configure now. Michael C. Michael Barton Director, Center for Social Dynamics & Complexity Professor of Anthropology, School of Human Evolution & Social Change Arizona State University voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC) fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC) www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu On Dec 7, 2013, at 11:27 AM, William Kyngesburye wrote: > On Dec 7, 2013, at 12:04 PM, Michael Barton wrote: > >> Additional good news. I grabbed a copy of the old packagemaker.app from the >> XCode 4 auxtools, dropped it into /Developer/Aux_tools/ (where I had it >> before), and it seems to work find for making a GRASS 7 package. >> > Another casualty in Xcode. We need to figure out how to use the new > packaging tools. Packagemaker was deprecated in Xcode 4 in favor of more raw > tools (which are also necessary for signing): pkgbuild, productbuild and > pkgutil. I found a stackoverflow question with some good info to start with, > I just haven't sat down and tried anything yet. > > http://stackoverflow.com/questions/11487596/making-os-x-installer-packages-like-a-pro-xcode4-developer-id-mountain-lion-re > >> Now I just need to get odbc and gettext to configure again and I'm back in >> business. >> >> odbc seems to be in /Library/ODBC >> Can I just add --with-odbc="/Library/ODBC" in the configure string? >> > /Library/ODBC is just for ODBC drivers. > > ODBC should still be iODBC, and --with-odbc should be enough. Unless Apple > completely reorganized iODBC. Is libiodbc.dylib in /Library/ODBC? Are > headers in there? > > > - > William Kyngesburye > http://www.kyngchaos.com/ > > "History is an illusion caused by the passage of time, and time is an > illusion caused by the passage of history." > > - Hitchhiker's Guide to the Galaxy > > ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] trying to compile GRASS 7 on Mavericks
On Dec 7, 2013, at 11:27 AM, William Kyngesburye wrote: > On Dec 7, 2013, at 12:04 PM, Michael Barton wrote: > >> Additional good news. I grabbed a copy of the old packagemaker.app from the >> XCode 4 auxtools, dropped it into /Developer/Aux_tools/ (where I had it >> before), and it seems to work find for making a GRASS 7 package. >> > Another casualty in Xcode. We need to figure out how to use the new > packaging tools. Packagemaker was deprecated in Xcode 4 in favor of more raw > tools (which are also necessary for signing): pkgbuild, productbuild and > pkgutil. I found a stackoverflow question with some good info to start with, > I just haven't sat down and tried anything yet. At least the old packagemaker.app still seems to work in the meantime > > http://stackoverflow.com/questions/11487596/making-os-x-installer-packages-like-a-pro-xcode4-developer-id-mountain-lion-re > >> Now I just need to get odbc and gettext to configure again and I'm back in >> business. >> >> odbc seems to be in /Library/ODBC >> Can I just add --with-odbc="/Library/ODBC" in the configure string? >> > /Library/ODBC is just for ODBC drivers. > > ODBC should still be iODBC, and --with-odbc should be enough. Unless Apple > completely reorganized iODBC. Is libiodbc.dylib in /Library/ODBC? Are > headers in there? Nothing is in my /Library/ODBC except a couple of very old (2003) files: odbc.ini and odbcinst.ini. Could it be someplace else? I could find nothing named ODBC in the other Library folders. Michael > > > - > William Kyngesburye > http://www.kyngchaos.com/ > > "History is an illusion caused by the passage of time, and time is an > illusion caused by the passage of history." > > - Hitchhiker's Guide to the Galaxy > > ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] trying to compile GRASS 7 on Mavericks
On Dec 7, 2013, at 12:04 PM, Michael Barton wrote: > Additional good news. I grabbed a copy of the old packagemaker.app from the > XCode 4 auxtools, dropped it into /Developer/Aux_tools/ (where I had it > before), and it seems to work find for making a GRASS 7 package. > Another casualty in Xcode. We need to figure out how to use the new packaging tools. Packagemaker was deprecated in Xcode 4 in favor of more raw tools (which are also necessary for signing): pkgbuild, productbuild and pkgutil. I found a stackoverflow question with some good info to start with, I just haven't sat down and tried anything yet. http://stackoverflow.com/questions/11487596/making-os-x-installer-packages-like-a-pro-xcode4-developer-id-mountain-lion-re > Now I just need to get odbc and gettext to configure again and I'm back in > business. > > odbc seems to be in /Library/ODBC > Can I just add --with-odbc="/Library/ODBC" in the configure string? > /Library/ODBC is just for ODBC drivers. ODBC should still be iODBC, and --with-odbc should be enough. Unless Apple completely reorganized iODBC. Is libiodbc.dylib in /Library/ODBC? Are headers in there? - William Kyngesburye http://www.kyngchaos.com/ "History is an illusion caused by the passage of time, and time is an illusion caused by the passage of history." - Hitchhiker's Guide to the Galaxy ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] segfault on 'r.stream.extract' - debian armh
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=) at dl-init.c:84 #3 call_init (l=, 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 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 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] segfault on 'r.stream.extract' - debian armh
Hi Maris, this is the bt : (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=) at dl-init.c:84 #3 call_init (l=, 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) rebuilding with : gcc -g -Wall -O0 gave me no worning in r.stream.extract On Dec 6, 2013, at 6:36 PM, Maris Nartiss wrote: > Any warnings during compilation? > Try to compile with -g and -O0 to get slow but debugging-friendly version. > > When program gets stopped by SIGILL in gdb, issue "bt" command to get > backtrace. > > No help form me, but more info never hurts ;) > > Maris. > > > 2013/12/6 epi : >> Hi ! >> >> this the output of gdb : >> >> Starting program: /home/epi/Envs/env1/grass-7.0.svn/bin/r.stream.extract >> .stream.extract elevation=elevation50m@PERMANENT accumulation=accum >> threshold=40 stream_rast=stream_network stream_vect=streams --o >> [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. >> 0x2c966e68 in ?? () from /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.0.0 >> (gdb) >> >> >> Thanks for your help! >> >> >> Massimo. >> >> >> On Dec 6, 2013, at 4:16 PM, Rashad M wrote: >> >> Hello Massimo, >> >> A gdb output could be more helpful for a segfault >> >> >> On Fri, Dec 6, 2013 at 7:06 PM, epi wrote: >>> >>> Hi, >>> >>> i’m trying to run “r.stream.extract” on a little linux machine, i got got >>> grass up and running on a small quad-core Arm 1gb ram >>> OS : Debian SID ArmHF. >>> >>> the command i’m using is : >>> >>> r.stream.extract elevation=elevation@PERMANENT accumulation=accum >>> threshold=40 stream_rast=stream_network stream_vect=streams --o --q >>> >>> location : nc_spm_08_grass7/PERMANENT/ >>> >>> >>> i set the debug level to 5, this the segfault log : >>> >>> https://gist.github.com/epifanio/7829206 >>> >>> if helpful, this is the log of make clean and make : >>> >>> https://gist.github.com/epifanio/7829256 >>> >>> On other platform (same grass and r.stream.extract version it wks just >>> fine) >>> Have you any idea on what’s wrong ? >>> >>> Thanks, >>> >>> Massimo. >>> >>> ___ >>> grass-dev mailing list >>> grass-dev@lists.osgeo.org >>> http://lists.osgeo.org/mailman/listinfo/grass-dev >> >> >> >> >> -- >> Regards, >> Rashad >> >> >> >> ___ >> 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
Re: [GRASS-dev] PCA (i.pca) in G7: filtering and rescaling
Moritz Lennert wrote: .. > Try the attached diff to imagery/i.pca/main.c. Great! So, applied the diff. Here some numbers: PC1 238310.68 ( 0.1606, 0.2231, 0.1228, 0.9536) [96.10%] PC2 9364.65 ( 0.4319, 0.5989, 0.6082,-0.2912) [ 3.78%] PC3217.78 ( 0.7028, 0.1609,-0.6897,-0.0672) [ 0.09%] PC4 80.33 ( 0.5420,-0.7521, 0.3732, 0.0366) [ 0.03%] Thus, we have: 96.10 + 3.78 + 0.09 = 99.88 + 0.09 = 99.97 Then, pca with "-f": i.pca in=Blue_DNs,Green_DNs,Red_DNs,NIR1_DNs out=TEST_PC --o -f percent=96.10 ERROR: Not enough principal components left for filtering and i.pca in=Blue_DNs,Green_DNs,Red_DNs,NIR1_DNs out=TEST_PC --o -f percent=96.11 gives: r.info -r TEST_PC.1 min=19.4012346427396 max=1570.71398669652 Good sign, means it works :-). And it does not truncate (otherwise, trunc(96.11) = 96, so "normally" it should fail to filter again)! Then, with "percent=99.87" still the same: r.info -r TEST_PC.1 min=19.4012346427396 max=1570.71398669652 while with "percent=99.88" it works: r.info -r TEST_PC.1 min=8.08831247843905 max=1443.35532373978 Finally, with "percent=99.97" OR below OR above, always gives the same r.info -r TEST_PC.1 min=8.08831247843905 max=1443.35532373978 So, the questions are: 1) why does it make the switch with 99.11 and not with 99.10, while it does make the switch already with 99.88 instead of requiring 99.89? 2) Why is there no filtering taking place for "percent >= 99.97" ? In a way, though, this is already getting better :-) Nikos ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] r.univar, ERROR G_realloc:
On Fri, Dec 6, 2013 at 11:58 PM, Glynn Clements wrote: >> D1/1: G_find_raster(): name=MASK mapset=pietro >> Current region rows: 28545, cols: 27645 >> ERROR: G_realloc: unable to allocate 68000 bytes of memory at >>r.univar_main.c:327 > > Don't use "r.univar -e", particularly for large maps. r.quantile and > r.statistics3 are far more efficient. ok, thanks I will look into it! >> Maybe is a stupid idea but since I had some problems also with >> v.build, do you think that could be possible that the problem is due >> not to the GRASS code, but to my physical memory that maybe is damaged >> in some sector? > > That's unlikely. Is the OS recognising that you have 24 GiB of RAM? yes it is. > Are you allowed to use all (or most) of it for a single process (check > the output from "ulimit -a")? I think so: $ ulimit -a core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited scheduling priority (-e) 30 file size (blocks, -f) unlimited pending signals (-i) 192592 max locked memory (kbytes, -l) unlimited max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size(512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 99 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) 192592 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited Actually running Memtest86, to test the memory bank I found hundred of errors so I strongly believe that the problem is due to some physical problem. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
