I am running into a problem I've never seen before. I was trying to digitize a vector file. I had imported it from a dxf file and was trying to close up some vectors points. Suddenly v.digit closed, and when I tried to reopen I got:
v.digit(4314,0xa0371fa0) malloc: *** mmap(size=1207963648) failed (error code=12)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
G_malloc: out of memory
When I tried to open my raster map I got:
PNG: GRASS_TRUECOLOR status: TRUE
PNG: collecting to file: /Users/kurtsprings/grassdata/OSI0834/PERMANENT/.tmp/Kurt-Springs-MacPro.local/4266.0.ppm,
GRASS_WIDTH=309, GRASS_HEIGHT=482
d.rast(4325) malloc: *** mmap(size=1206358016) failed (error code=12)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
G_malloc: out of memory
I tried opening a different project location and it still works. Can anyone tell me what is wrong and how to get this project location up and running again, or what went wrong to begin with.
I am running into a problem I've never seen before. I was trying to
digitize a vector file. I had imported it from a dxf file and was
trying to close up some vectors points. Suddenly v.digit closed, and
when I tried to reopen I got:
v.digit(4314,0xa0371fa0) malloc: *** mmap(size=1207963648) failed
(error code=12)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
G_malloc: out of memory
When I tried to open my raster map I got:
PNG: GRASS_TRUECOLOR status: TRUE
PNG: collecting to file: /Users/kurtsprings/grassdata/OSI0834/
PERMANENT/.tmp/Kurt-Springs-MacPro.local/4266.0.ppm,
GRASS_WIDTH=309, GRASS_HEIGHT=482
d.rast(4325) malloc: *** mmap(size=1206358016) failed (error code=12)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
G_malloc: out of memory
I tried opening a different project location and it still works. Can
anyone tell me what is wrong and how to get this project location up
and running again, or what went wrong to begin with.
The most likely reason is that the region resolution is too fine. Use
"g.region res=..." to change it, or "g.region -d" to restore the
default region.
I used g.region to set the resolution from 10m to 100m, then to 1m.
on 100m I get
PNG: GRASS_TRUECOLOR status: TRUE
PNG: collecting to file: /Users/kurtsprings/grassdata/OSI0834/PERMANENT/.tmp/Kurt-Springs-MacPro.local/5417.0.ppm,
GRASS_WIDTH=309, GRASS_HEIGHT=482
d.rast(5512) malloc: *** mmap(size=1206358016) failed (error code=12)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
G_malloc: out of memory
on 1m I get
PNG: GRASS_TRUECOLOR status: TRUE
PNG: collecting to file: /Users/kurtsprings/grassdata/OSI0834/PERMANENT/.tmp/Kurt-Springs-MacPro.local/5417.0.ppm,
GRASS_WIDTH=309, GRASS_HEIGHT=482
d.rast(5528) malloc: *** mmap(size=1206358016) failed (error code=12)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
G_malloc: out of memory
Other project locations, set at 10m are okay.
Kurt
On Nov 20, 2008, at 6:59 PM, Glynn Clements wrote:
Kurt Springs wrote:
I am running into a problem I've never seen before. I was trying to
digitize a vector file. I had imported it from a dxf file and was
trying to close up some vectors points. Suddenly v.digit closed, and
when I tried to reopen I got:
v.digit(4314,0xa0371fa0) malloc: *** mmap(size=1207963648) failed
(error code=12)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
G_malloc: out of memory
When I tried to open my raster map I got:
PNG: GRASS_TRUECOLOR status: TRUE
PNG: collecting to file: /Users/kurtsprings/grassdata/OSI0834/
PERMANENT/.tmp/Kurt-Springs-MacPro.local/4266.0.ppm,
GRASS_WIDTH=309, GRASS_HEIGHT=482
d.rast(4325) malloc: *** mmap(size=1206358016) failed (error code=12)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
G_malloc: out of memory
I tried opening a different project location and it still works. Can
anyone tell me what is wrong and how to get this project location up
and running again, or what went wrong to begin with.
The most likely reason is that the region resolution is too fine. Use
"g.region res=..." to change it, or "g.region -d" to restore the
default region.
I am running into a problem I've never seen before. I
was trying to digitize a vector file. I had imported it
from a dxf file and was trying to close up some vectors
points. Suddenly v.digit closed, and when I tried to reopen
I got:
v.digit(4314,0xa0371fa0) malloc: *** mmap(size=1207963648)
failed (error code=12)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
G_malloc: out of memory
whenever v.digit crashes try "v.build mapname" to recover.
I used g.region to set the resolution from 10m to 100m, then to 1m.
on 100m I get
PNG: GRASS_TRUECOLOR status: TRUE
PNG: collecting to file: /Users/kurtsprings/grassdata/OSI0834/
PERMANENT/.tmp/Kurt-Springs-MacPro.local/5417.0.ppm,
GRASS_WIDTH=309, GRASS_HEIGHT=482
d.rast(5512) malloc: *** mmap(size=1206358016) failed (error code=12)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
G_malloc: out of memory
First, try from the command line.
If the resolution isn't the problem, it might be the bounds. Check
that the output from "g.region -p" is sane (specifically, the number
of rows and columns).
Okay that worked (if I do it twice then restart grass, go figure.)
Anyway. It keeps on happening. I am trying to snap the nodes along my coastline. I also have to draw three lines to enclose my water. For trying to snap the nodes, I have been using the MOVE VERTEX to attempt this (as per the book). I am having a hard time getting it to snap. I try increasing magnification, and that is when the G_malloc likes to strike. So I want to do this in as few a steps as possible, and then get out.
Any thoughts.
Kurt
On Nov 20, 2008, at 11:21 PM, Hamish wrote:
Kurt:
I am running into a problem I've never seen before. I
was trying to digitize a vector file. I had imported it
from a dxf file and was trying to close up some vectors
points. Suddenly v.digit closed, and when I tried to reopen
I got:
v.digit(4314,0xa0371fa0) malloc: *** mmap(size=1207963648)
failed (error code=12)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
G_malloc: out of memory
whenever v.digit crashes try "v.build mapname" to recover.
Hello Kurt,
I assume You are using some stable GRASS version? I suggest to give a
try to GRASS 6.4-svn one, as I commited [1] some small fixes, that
adds tuneable snapping also for editing tools in v.digit.
If it doesn't help, can You provide Your location/mapset as .tgz so we
could make some tests to see why it's failing.
Okay that worked (if I do it twice then restart grass, go figure.)
Anyway. It keeps on happening. I am trying to snap the nodes along
my coastline. I also have to draw three lines to enclose my water.
For trying to snap the nodes, I have been using the MOVE VERTEX to
attempt this (as per the book). I am having a hard time getting it to
snap. I try increasing magnification, and that is when the G_malloc
likes to strike. So I want to do this in as few a steps as possible,
and then get out.
I am using GRASS 6.3 on Mac OS X. I usually just download the Binaries for MacOSX. I don't really know how to convert the source code into a working program.
Kurt
On Nov 22, 2008, at 8:39 AM, Maris Nartiss wrote:
Hello Kurt,
I assume You are using some stable GRASS version? I suggest to give a
try to GRASS 6.4-svn one, as I commited [1] some small fixes, that
adds tuneable snapping also for editing tools in v.digit.
If it doesn't help, can You provide Your location/mapset as .tgz so we
could make some tests to see why it's failing.
Okay that worked (if I do it twice then restart grass, go figure.)
Anyway. It keeps on happening. I am trying to snap the nodes along
my coastline. I also have to draw three lines to enclose my water.
For trying to snap the nodes, I have been using the MOVE VERTEX to
attempt this (as per the book). I am having a hard time getting it to
snap. I try increasing magnification, and that is when the G_malloc
likes to strike. So I want to do this in as few a steps as possible,
and then get out.
I'm somewhat caught up on other distractions and can focus more on GRASS again. I can package up a 6.4svn.
If your up to it, there are detailed OSX compile instructions in the source, though I should look them over for any changes needed.
On Nov 22, 2008, at 8:59 AM, Kurt Springs wrote:
I am using GRASS 6.3 on Mac OS X. I usually just download the Binaries for MacOSX. I don't really know how to convert the source code into a working program.
Kurt
On Nov 22, 2008, at 8:39 AM, Maris Nartiss wrote:
Hello Kurt,
I assume You are using some stable GRASS version? I suggest to give a
try to GRASS 6.4-svn one, as I commited [1] some small fixes, that
adds tuneable snapping also for editing tools in v.digit.
If it doesn't help, can You provide Your location/mapset as .tgz so we
could make some tests to see why it's failing.
"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?"
Okay, I'm willing to try. I hope 6.4 will help in getting nodes to snap.
Kurt
On Nov 22, 2008, at 11:22 AM, William Kyngesburye wrote:
I'm somewhat caught up on other distractions and can focus more on GRASS again. I can package up a 6.4svn.
If your up to it, there are detailed OSX compile instructions in the source, though I should look them over for any changes needed.
On Nov 22, 2008, at 8:59 AM, Kurt Springs wrote:
I am using GRASS 6.3 on Mac OS X. I usually just download the Binaries for MacOSX. I don't really know how to convert the source code into a working program.
Kurt
On Nov 22, 2008, at 8:39 AM, Maris Nartiss wrote:
Hello Kurt,
I assume You are using some stable GRASS version? I suggest to give a
try to GRASS 6.4-svn one, as I commited [1] some small fixes, that
adds tuneable snapping also for editing tools in v.digit.
If it doesn't help, can You provide Your location/mapset as .tgz so we
could make some tests to see why it's failing.
"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?"
Okay, I'm willing to try. I hope 6.4 will help in getting nodes to snap.
Kurt
On Nov 22, 2008, at 11:22 AM, William Kyngesburye wrote:
I'm somewhat caught up on other distractions and can focus more on GRASS again. I can package up a 6.4svn.
If your up to it, there are detailed OSX compile instructions in the source, though I should look them over for any changes needed.
I have 6.4 SVN binaries online now. Tested on Leopard so far. I also updated the build instructions in the source.
A couple important changes from my previous binaries (the build instructions also reflect these changes):
- It uses ActiveTcl 8.5 now for the TclTk GUI and NVIZ. This "aqua-fies" the TclTk GUI. The X11 TclTk is not bundled now and not needed.
- It uses up-to-date wxPython binaries, even on Leopard. Starting with wxPython 2.8.8, it can install to be used with the Leopard system Python 2.5 as well as the python.org Python. This may interfere with the wx gui in GRASS 6.3, but it's not as well developed anyways.
[Trillian] What are you supposed to do WITH a maniacally depressed robot?
[Marvin] You think you have problems? What are you supposed to do if you ARE a maniacally depressed robot? No, don't try and answer, I'm 50,000 times more intelligent than you and even I don't know the answer...
Well, it is installed, but it is still not snapping the nodes. (BTW I like the way it works otherwise). One thing, how do I set the keyboard keys command, option/alt, and control to work with the mouse click for middle and right mouse button. Things did not perform as expected when I tried middle or right mouse keystrokes when I tried to connect a box around the coastline.
On Nov 23, 2008, at 3:42 PM, William Kyngesburye wrote:
On Nov 22, 2008, at 7:42 PM, Kurt Springs wrote:
Okay, I'm willing to try. I hope 6.4 will help in getting nodes to snap.
Kurt
On Nov 22, 2008, at 11:22 AM, William Kyngesburye wrote:
I'm somewhat caught up on other distractions and can focus more on GRASS again. I can package up a 6.4svn.
If your up to it, there are detailed OSX compile instructions in the source, though I should look them over for any changes needed.
I have 6.4 SVN binaries online now. Tested on Leopard so far. I also updated the build instructions in the source.
A couple important changes from my previous binaries (the build instructions also reflect these changes):
- It uses ActiveTcl 8.5 now for the TclTk GUI and NVIZ. This "aqua-fies" the TclTk GUI. The X11 TclTk is not bundled now and not needed.
- It uses up-to-date wxPython binaries, even on Leopard. Starting with wxPython 2.8.8, it can install to be used with the Leopard system Python 2.5 as well as the python.org Python. This may interfere with the wx gui in GRASS 6.3, but it's not as well developed anyways.
[Trillian] What are you supposed to do WITH a maniacally depressed robot?
[Marvin] You think you have problems? What are you supposed to do if you ARE a maniacally depressed robot? No, don't try and answer, I'm 50,000 times more intelligent than you and even I don't know the answer...
On Nov 23, 2008, at 12:42 PM, William Kyngesburye wrote:
On Nov 22, 2008, at 7:42 PM, Kurt Springs wrote:
Okay, I'm willing to try. I hope 6.4 will help in getting nodes to snap.
Kurt
On Nov 22, 2008, at 11:22 AM, William Kyngesburye wrote:
I'm somewhat caught up on other distractions and can focus more on GRASS again. I can package up a 6.4svn.
If your up to it, there are detailed OSX compile instructions in the source, though I should look them over for any changes needed.
I have 6.4 SVN binaries online now. Tested on Leopard so far. I also updated the build instructions in the source.
A couple important changes from my previous binaries (the build instructions also reflect these changes):
- It uses ActiveTcl 8.5 now for the TclTk GUI and NVIZ. This "aqua-fies" the TclTk GUI. The X11 TclTk is not bundled now and not needed.
- It uses up-to-date wxPython binaries, even on Leopard. Starting with wxPython 2.8.8, it can install to be used with the Leopard system Python 2.5 as well as the python.org Python. This may interfere with the wx gui in GRASS 6.3, but it's not as well developed anyways.
-----
I downloaded this. So far the basics seem fine, but I get an error when I try to use nviz. The error is below:
Dyld Error Message:
Library not loaded: /Library/Frameworks/Tk.framework/Versions/8.5/Tk
Referenced from: /Applications/GRASS-6.4.app/Contents/MacOS/etc/nviz2.2/nviz
Reason: image not found
Do I have to separately install a new version of TclTK? I have both whatever is installed with the default 10.5.5, and I also use MacPorts and I have tcl 8.5.5 and tk 8.5.5 installed from Macports.
Do I need to install something else? Or is nviz just looking in the wrong place and needs to get pointed in the right direction?
On Dec 1, 2008, at 12:46 PM, Adam Dershowitz wrote:
I have 6.4 SVN binaries online now. Tested on Leopard so far. I also updated the build instructions in the source.
A couple important changes from my previous binaries (the build instructions also reflect these changes):
- It uses ActiveTcl 8.5 now for the TclTk GUI and NVIZ. This "aqua-fies" the TclTk GUI. The X11 TclTk is not bundled now and not needed.
- It uses up-to-date wxPython binaries, even on Leopard. Starting with wxPython 2.8.8, it can install to be used with the Leopard system Python 2.5 as well as the python.org Python. This may interfere with the wx gui in GRASS 6.3, but it's not as well developed anyways.
-----
I downloaded this. So far the basics seem fine, but I get an error when I try to use nviz. The error is below:
Do I have to separately install a new version of TclTK? I have both whatever is installed with the default 10.5.5, and I also use MacPorts and I have tcl 8.5.5 and tk 8.5.5 installed from Macports.
Do I need to install something else? Or is nviz just looking in the wrong place and needs to get pointed in the right direction?
Yes. It is mentioned in the readme.
The GUI can use any TclTk, but NVIZ and v.digit require the TclTk 8.5 Aqua framework (ActiveTcl or compiled from source).
OSX 10.5 only has TclTk 8.4 Aqua. There are problems with this version.
I'm not sure about Macports, but I think that's an X11 TclTk.
"Mon Dieu! but they are all alike. Cheating, murdering, lying, fighting, and all for things that the beasts of the jungle would not deign to possess - money to purchase the effeminate pleasures of weaklings. And yet withal bound down by silly customs that make them slaves to their unhappy lot while firm in the belief that they be the lords of creation enjoying the only real pleasures of existence....
On Dec 1, 2008, at 11:14 AM, William Kyngesburye wrote:
On Dec 1, 2008, at 12:46 PM, Adam Dershowitz wrote:
I have 6.4 SVN binaries online now. Tested on Leopard so far. I also updated the build instructions in the source.
A couple important changes from my previous binaries (the build instructions also reflect these changes):
- It uses ActiveTcl 8.5 now for the TclTk GUI and NVIZ. This "aqua-fies" the TclTk GUI. The X11 TclTk is not bundled now and not needed.
- It uses up-to-date wxPython binaries, even on Leopard. Starting with wxPython 2.8.8, it can install to be used with the Leopard system Python 2.5 as well as the python.org Python. This may interfere with the wx gui in GRASS 6.3, but it's not as well developed anyways.
-----
I downloaded this. So far the basics seem fine, but I get an error when I try to use nviz. The error is below:
Do I have to separately install a new version of TclTK? I have both whatever is installed with the default 10.5.5, and I also use MacPorts and I have tcl 8.5.5 and tk 8.5.5 installed from Macports.
Do I need to install something else? Or is nviz just looking in the wrong place and needs to get pointed in the right direction?
Yes. It is mentioned in the readme.
The GUI can use any TclTk, but NVIZ and v.digit require the TclTk 8.5 Aqua framework (ActiveTcl or compiled from source).
OSX 10.5 only has TclTk 8.4 Aqua. There are problems with this version.
I'm not sure about Macports, but I think that's an X11 TclTk.
Ooops. Sorry I missed the readme.
I checked and by default the Macports Tk is X11. But there is a flag to build it for aqua (the flag is just +quartz) and that in term passes the "--enable-aqua" flag to the tk build. It worked fine to build. And now when I run Grass 6.4 the look is different, so clearly it was using the X11 version, and now is using the aqua version. But I still get the same error that I did before.
I think that it is correctly building Tk for aqua, but it not generating a framework, and NVIZ seems to want it located in that specific location as a framework. Does NVIZ do something a little unusual about finding the path? Or does Tk do something unusual. I have looked at the portfile (build instructions essentially) for Tk and it looks like it is just putting that extra flag in place and not doing much else. So I think that it is pretty much identical to building with default settings from source.
On Dec 1, 2008, at 1:42 PM, Adam Dershowitz wrote:
The GUI can use any TclTk, but NVIZ and v.digit require the TclTk 8.5 Aqua framework (ActiveTcl or compiled from source).
OSX 10.5 only has TclTk 8.4 Aqua. There are problems with this version.
I'm not sure about Macports, but I think that's an X11 TclTk.
But I still get the same error that I did before.
I think that it is correctly building Tk for aqua, but it not generating a framework, and NVIZ seems to want it located in that specific location as a framework. Does NVIZ do something a little unusual about finding the path? Or does Tk do something unusual. I have looked at the portfile (build instructions essentially) for Tk and it looks like it is just putting that extra flag in place and not doing much else. So I think that it is pretty much identical to building with default settings from source.
NVIZ (and v.digit) are binary Tk programs, and thus use standard library linking to the Tcl and Tk libraries (frameworks).
The configure flag for creating both Tcl and Tk frameworks is --enable-framework. In Tk, this implies --enable-aqua. --enable-aqua by itself presumably only does that, as you found. This fits with the Macports style - it doesn't do frameworks, everything is *nix libraries (OK, that's just a guess).
I would be possible to use DYLD_LIBRARY_PATH to force it to find a different binary, but the framework binary is too differently named for this to work. You really need to install TclTk frameworks outside the Macports system, either ActiveTcl binaries or compiled from source without Macports.
First Pogril: Why is life like sticking your head in a bucket filled with hyena offal?
Second Pogril: I don't know. Why IS life like sticking your head in a bucket filled with hyena offal?
First Pogril: I don't know either. Wretched, isn't it?