Just for your information it segfaults while copying (any?) raster.
I don't know if it has been fixed later, if not I could submit a bug report.
--
Francesco P. Lovergine
Francesco P. Lovergine wrote:
Just for your information it segfaults while copying
(any?) raster. I don't know if it has been fixed later,
if not I could submit a bug report.
Francesco,
g.copy has been working OK for me recently.
What platform? Do you build from source? Any extra flags
used if so? Can you reproduce the error in spearfish location?
Maciek
Hi,
there where problems with g.copy some time a go, but problem went away
without explanation about it's source/roots.
http://wald.intevation.org/tracker/?group_id=21&atid=204&func=detail&aid=431
If You can provide more information how to reproduce crash (using
spearfish or publush Your location somewhere) it would be welcomed.
Maris.
On Thu, Sep 27, 2007 at 05:49:01PM +0300, Maris Nartiss wrote:
Hi,
there where problems with g.copy some time a go, but problem went away
without explanation about it's source/roots.http://wald.intevation.org/tracker/?group_id=21&atid=204&func=detail&aid=431
If You can provide more information how to reproduce crash (using
spearfish or publush Your location somewhere) it would be welcomed.Maris.
It happens with any raster from the spearfish60 dataset, on Debian GNU/Linux.
If you had problem to reproduce it I can track better the issue in a
debugging session.
--
Francesco P. Lovergine
We did a lot of tests back then, and it seems to be a problem with the compiler optimisation code. This issue isn't fixed, but you can work around it by re-compiling g.copy without optimisation enabled (see thread below). I don't think it is a GRASS issue.
Volker
Francesco P. Lovergine wrote:
On Thu, Sep 27, 2007 at 05:49:01PM +0300, Maris Nartiss wrote:
there where problems with g.copy some time a go, but problem went away
without explanation about it's source/roots.http://wald.intevation.org/tracker/?group_id=21&atid=204&func=detail&aid=431
It happens with any raster from the spearfish60 dataset, on Debian GNU/Linux.
If you had problem to reproduce it I can track better the issue in a
debugging session.
It may be not a GRASS issue, but it would be nice to know why it
happens, as, probably, there are some tricks to disable THIS
optimization in GRASS. Like adding some *magic* in code or tests in
autoconf part to disable optimization if system is FOO.
Just 0.002$,
Maris.
2007/9/27, Volker Wichmann <wichmann@laserdata.at>:
We did a lot of tests back then, and it seems to be a problem with the
compiler optimisation code. This issue isn't fixed, but you can work
around it by re-compiling g.copy without optimisation enabled (see
thread below). I don't think it is a GRASS issue.Volker
I also had this problem on OSX last year, and it eventually went away. It looked liked some problem with Postgres in GDAL, but it's unlcear. From the old tracker:
http://intevation.de/rt/webrt?serial_num=3585
I never tried it with/without optimization, as Volker suggested.
Currently working on OSX 10.4 with optimization.
On Sep 27, 2007, at 7:49 AM, Maris Nartiss wrote:
Hi,
there where problems with g.copy some time a go, but problem went away
without explanation about it's source/roots.http://wald.intevation.org/tracker/?group_id=21&atid=204&func=detail&aid=431
If You can provide more information how to reproduce crash (using
spearfish or publush Your location somewhere) it would be welcomed.Maris.
_______________________________________________
grass-dev mailing list
grass-dev@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass-dev
-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/
"We are at war with them. Neither in hatred nor revenge and with no particular pleasure I shall kill every ___ I can until the war is over. That is my duty."
"Don't you even hate 'em?"
"What good would it do if I did? If all the many millions of people of the allied nations devoted an entire year exclusively to hating the ____ it wouldn't kill one ___ nor shorten the war one day."
<Ha, ha> "And it might give 'em all stomach ulcers."
- Tarzan, on war
It would be certainly nice to know why, if you like to dig deeper have a look at thread [GRASS-dev] [grass-code I][431] g.copy segmentation fault ( http://www.mail-archive.com/grass-dev@grass.itc.it/msg00359.html )
Volker
Maris Nartiss wrote:
It may be not a GRASS issue, but it would be nice to know why it
happens, as, probably, there are some tricks to disable THIS
optimization in GRASS. Like adding some *magic* in code or tests in
autoconf part to disable optimization if system is FOO.Just 0.002$,
Maris.2007/9/27, Volker Wichmann <wichmann@laserdata.at>:
We did a lot of tests back then, and it seems to be a problem with the
compiler optimisation code. This issue isn't fixed, but you can work
around it by re-compiling g.copy without optimisation enabled (see
thread below). I don't think it is a GRASS issue.Volker