[GRASS-user] r.li help

GRASS GRASS user
1

I just installed GRASS 6.4 on MacOS X and have been attempting to run some landscape analysis with the r.li modules. I can run the r.li.setup module just fine, but when I attempt to run r.li.patchnum or the density function it just crashes immediately. I've run it from the python GUI and the command-line and the same thing happens. Is there a fix for this?

Thanks,
Nate

2

On Mon, Aug 10, 2009 at 7:43 AM, Nathan Lemoine<lemoine.nathan@gmail.com> wrote:

I just installed GRASS 6.4 on MacOS X and have been attempting to run some
landscape analysis with the r.li modules. I can run the r.li.setup module
just fine, but when I attempt to run r.li.patchnum or the density function
it just crashes immediately. I've run it from the python GUI and the
command-line and the same thing happens. Is there a fix for this?

Are you able to reproduce it with the Spearfish or North Carolina
data set? If yes, please tell us the steps and we try to reproduce
the problem. I ran a few r.li measures successfully recently on Linux (64bit).

Markus

3

When it crashes, if you get a crash dialog box, click the Report button and copy the details text from that (don't send the crash report).

or

Run Console.app and look for a crash log for r.li.patchnum in your home Library.

On Aug 10, 2009, at 12:43 AM, Nathan Lemoine wrote:

I just installed GRASS 6.4 on MacOS X and have been attempting to run some landscape analysis with the r.li modules. I can run the r.li.setup module just fine, but when I attempt to run r.li.patchnum or the density function it just crashes immediately. I've run it from the python GUI and the command-line and the same thing happens. Is there a fix for this?

Thanks,
Nate
_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/

"The beast is actively interested only in now, and, as it is always now and always shall be, there is an eternity of time for the accomplishment of objects."

- the wisdom of Tarzan

4

I've attempted to find the config file on my harddrive and can't seem to locate it. It shows up when I run r.li.setup in the list of available config files and seems to load fine, but when i search for the file it isn't on my harddrive. The config file is supposed to be in the path ~/.r.li/history, but r.li.setup does not create such a path. I've run the r.le.setup which creates the appropriate file path in my user folder to the r.le config files, but r.li does not seem to do this.

On Aug 10, 2009, at 12:49 PM, Markus Neteler wrote:

Can you please send the config file to me?

Markus

PS: please keep the list in the loop since other may be able to help
even better than me...

On Mon, Aug 10, 2009 at 4:44 PM, Nathan Lemoine<lemoine.nathan@gmail.com> wrote:

I copied landuse96_28m file to the user1 MAPSET (I named the copy
"landuse"), and used r.li.setup to make my config file. I named the config
file "mov" and selected the "landuse" raster file. I set the sampling frame
to the whole region, and set the sampling area to a moving window. I chose a
rectangular window of 5x5 cells. The config file was the set and seemed to
be fine. I attempted to run r.li.patchnum rast=landuse config=mov
output=test and got the following reports:

This is the GRASS terminal report:

Illegal filename. Character < > not allowed.
Unable to open header file for raster map < @(null)>
CHILD[pid = 1486]: unable to open mask ... continue without!!!
Illegal filename. Character < > not allowed.
Unable to open header file for raster map < @(null)>
CHILD[pid = 1485]: unable to open mask ... continue without!!!

and here is the crash report:

Process: r.li.patchnum [1476]
Path:
/Applications/GRASS-6.4.app/Contents/MacOS/bin/r.li.patchnum
Identifier: r.li.patchnum
Version: ??? (???)
Code Type: X86-64 (Native)
Parent Process: Python [981]

Interval Since Last Report: 134 sec
Crashes Since Last Report: 5
Per-App Interval Since Last Report: 0 sec
Per-App Crashes Since Last Report: 5

Date/Time: 2009-08-10 09:40:14.814 -0500
OS Version: Mac OS X 10.5.8 (9L30)
Report Version: 6
Anonymous UUID: 79A157D4-B61F-432E-8CB4-A2211DE1A30D

Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x0000006174614420
Crashed Thread: 0

Thread 0 Crashed:
0 libSystem.B.dylib 0x00007fff806cfd70 strcpy + 48
1 libgrass_rli.dylib 0x000000010005c3ed next_Area + 111
2 libgrass_rli.dylib 0x000000010005ca8a calculateIndex +
859
3 r.li.patchnum 0x00000001000008c8 start + 52

Thread 0 crashed with X86 Thread State (64-bit):
rax: 0x0000000000000005 rbx: 0x00007fff5fbfe600 rcx: 0x00007fff5fbfe4fc
rdx: 0x0000000000000004
rdi: 0x00007fff5fbfe4fc rsi: 0x0000006174614420 rbp: 0x00007fff5fbfaea0
rsp: 0x00007fff5fbfae98
  r8: 0x00000001001fe026 r9: 0x0000000000000208 r10: 0x00000001000618c0
r11: 0x00007fff806cfd40
r12: 0x00000001001007d0 r13: 0x00007fff5fbfe4e0 r14: 0x00000001001007d0
r15: 0x0000000000000000
rip: 0x00007fff806cfd70 rfl: 0x0000000000010202 cr2: 0x0000006174614420

Binary Images:
      0x100000000 - 0x100000fff +r.li.patchnum ??? (???)
<06f892abad9a2d2989b9c21d1b12d783>
/Applications/GRASS-6.4.app/Contents/MacOS/bin/r.li.patchnum
      0x100003000 - 0x100041ff7 +libgrass_gis.dylib ??? (???)
<3f754d3fd572946f5f5c57939c5efd58>
/Applications/GRASS-6.4.app/Contents/MacOS/lib/libgrass_gis.dylib
      0x100052000 - 0x100057fff +libgrass_datetime.dylib ??? (???)
<366b12b0e9b5622047457160897ad0ee>
/Applications/GRASS-6.4.app/Contents/MacOS/lib/libgrass_datetime.dylib
      0x10005a000 - 0x10005ffff +libgrass_rli.dylib ??? (???)
<d5dd64d7346e0357e77ecc2d883b4bd0>
/Applications/GRASS-6.4.app/Contents/MacOS/lib/libgrass_rli.dylib
   0x7fff5fc00000 - 0x7fff5fc2e643 dyld 97.1 (???)
<1d1ba42c89e77cfe2558a3c66129fff6> /usr/lib/dyld
   0x7fff806a7000 - 0x7fff80832ffb libSystem.B.dylib ??? (???)
<714d2608b5acae3ad5364897c49868fa> /usr/lib/libSystem.B.dylib
   0x7fff81d78000 - 0x7fff81d89ffd libz.1.dylib ??? (???)
<2022cc8950afdf485ba1df76364ba725> /usr/lib/libz.1.dylib
   0x7fff82abc000 - 0x7fff82ac8ff1 libgcc_s.1.dylib ??? (???)
<6fc905606335f261db4da9529c7e2711> /usr/lib/libgcc_s.1.dylib
   0x7fff841fd000 - 0x7fff84201fff libmathCommon.A.dylib ??? (???)
/usr/lib/system/libmathCommon.A.dylib
   0x7fffffe00000 - 0x7fffffe01780 libSystem.B.dylib ??? (???)
/usr/lib/libSystem.B.dylib

This seems to be a different issue than when I attempted it with my own
data, but I'm still looking into that.

Nate

On Aug 10, 2009, at 1:20 AM, Markus Neteler wrote:

On Mon, Aug 10, 2009 at 7:43 AM, Nathan Lemoine<lemoine.nathan@gmail.com>
wrote:

I just installed GRASS 6.4 on MacOS X and have been attempting to run
some
landscape analysis with the r.li modules. I can run the r.li.setup module
just fine, but when I attempt to run r.li.patchnum or the density
function
it just crashes immediately. I've run it from the python GUI and the
command-line and the same thing happens. Is there a fix for this?

Are you able to reproduce it with the Spearfish or North Carolina
data set? If yes, please tell us the steps and we try to reproduce
the problem. I ran a few r.li measures successfully recently on Linux
(64bit).

Markus

5

On Mon, Aug 10, 2009 at 8:20 PM, Nathan Lemoine<lemoine.nathan@gmail.com> wrote:

I've attempted to find the config file on my harddrive and can't seem to
locate it. It shows up when I run r.li.setup in the list of available config
files and seems to load fine, but when i search for the file it isn't on my
harddrive. The config file is supposed to be in the path ~/.r.li/history,
but r.li.setup does not create such a path.

Then that's perhaps the problem? William, does it create on your Mac
the directory?

Markus

I've run the r.le.setup which
creates the appropriate file path in my user folder to the r.le config
files, but r.li does not seem to do this.

On Aug 10, 2009, at 12:49 PM, Markus Neteler wrote:

Can you please send the config file to me?

Markus

PS: please keep the list in the loop since other may be able to help
even better than me...

On Mon, Aug 10, 2009 at 4:44 PM, Nathan Lemoine<lemoine.nathan@gmail.com>
wrote:

I copied landuse96_28m file to the user1 MAPSET (I named the copy
"landuse"), and used r.li.setup to make my config file. I named the
config
file "mov" and selected the "landuse" raster file. I set the sampling
frame
to the whole region, and set the sampling area to a moving window. I
chose a
rectangular window of 5x5 cells. The config file was the set and seemed
to
be fine. I attempted to run r.li.patchnum rast=landuse config=mov
output=test and got the following reports:

This is the GRASS terminal report:

Illegal filename. Character < > not allowed.
Illegal filename. Character < > not allowed.
Illegal filename. Character < > not allowed.
Unable to open header file for raster map < @(null)>
CHILD[pid = 1486]: unable to open mask ... continue without!!!
Illegal filename. Character < > not allowed.
Illegal filename. Character < > not allowed.
Illegal filename. Character < > not allowed.
Unable to open header file for raster map < @(null)>
CHILD[pid = 1485]: unable to open mask ... continue without!!!

and here is the crash report:

Process: r.li.patchnum [1476]
Path:
/Applications/GRASS-6.4.app/Contents/MacOS/bin/r.li.patchnum
Identifier: r.li.patchnum
Version: ??? (???)
Code Type: X86-64 (Native)
Parent Process: Python [981]

Interval Since Last Report: 134 sec
Crashes Since Last Report: 5
Per-App Interval Since Last Report: 0 sec
Per-App Crashes Since Last Report: 5

Date/Time: 2009-08-10 09:40:14.814 -0500
OS Version: Mac OS X 10.5.8 (9L30)
Report Version: 6
Anonymous UUID: 79A157D4-B61F-432E-8CB4-A2211DE1A30D

Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x0000006174614420
Crashed Thread: 0

Thread 0 Crashed:
0 libSystem.B.dylib 0x00007fff806cfd70 strcpy + 48
1 libgrass_rli.dylib 0x000000010005c3ed next_Area +
111
2 libgrass_rli.dylib 0x000000010005ca8a calculateIndex
+
859
3 r.li.patchnum 0x00000001000008c8 start + 52

Thread 0 crashed with X86 Thread State (64-bit):
rax: 0x0000000000000005 rbx: 0x00007fff5fbfe600 rcx:
0x00007fff5fbfe4fc
rdx: 0x0000000000000004
rdi: 0x00007fff5fbfe4fc rsi: 0x0000006174614420 rbp:
0x00007fff5fbfaea0
rsp: 0x00007fff5fbfae98
r8: 0x00000001001fe026 r9: 0x0000000000000208 r10: 0x00000001000618c0
r11: 0x00007fff806cfd40
r12: 0x00000001001007d0 r13: 0x00007fff5fbfe4e0 r14:
0x00000001001007d0
r15: 0x0000000000000000
rip: 0x00007fff806cfd70 rfl: 0x0000000000010202 cr2:
0x0000006174614420

Binary Images:
0x100000000 - 0x100000fff +r.li.patchnum ??? (???)
<06f892abad9a2d2989b9c21d1b12d783>
/Applications/GRASS-6.4.app/Contents/MacOS/bin/r.li.patchnum
0x100003000 - 0x100041ff7 +libgrass_gis.dylib ??? (???)
<3f754d3fd572946f5f5c57939c5efd58>
/Applications/GRASS-6.4.app/Contents/MacOS/lib/libgrass_gis.dylib
0x100052000 - 0x100057fff +libgrass_datetime.dylib ??? (???)
<366b12b0e9b5622047457160897ad0ee>
/Applications/GRASS-6.4.app/Contents/MacOS/lib/libgrass_datetime.dylib
0x10005a000 - 0x10005ffff +libgrass_rli.dylib ??? (???)
<d5dd64d7346e0357e77ecc2d883b4bd0>
/Applications/GRASS-6.4.app/Contents/MacOS/lib/libgrass_rli.dylib
0x7fff5fc00000 - 0x7fff5fc2e643 dyld 97.1 (???)
<1d1ba42c89e77cfe2558a3c66129fff6> /usr/lib/dyld
0x7fff806a7000 - 0x7fff80832ffb libSystem.B.dylib ??? (???)
<714d2608b5acae3ad5364897c49868fa> /usr/lib/libSystem.B.dylib
0x7fff81d78000 - 0x7fff81d89ffd libz.1.dylib ??? (???)
<2022cc8950afdf485ba1df76364ba725> /usr/lib/libz.1.dylib
0x7fff82abc000 - 0x7fff82ac8ff1 libgcc_s.1.dylib ??? (???)
<6fc905606335f261db4da9529c7e2711> /usr/lib/libgcc_s.1.dylib
0x7fff841fd000 - 0x7fff84201fff libmathCommon.A.dylib ??? (???)
/usr/lib/system/libmathCommon.A.dylib
0x7fffffe00000 - 0x7fffffe01780 libSystem.B.dylib ??? (???)
/usr/lib/libSystem.B.dylib

This seems to be a different issue than when I attempted it with my own
data, but I'm still looking into that.

Nate

On Aug 10, 2009, at 1:20 AM, Markus Neteler wrote:

On Mon, Aug 10, 2009 at 7:43 AM, Nathan
Lemoine<lemoine.nathan@gmail.com>
wrote:

I just installed GRASS 6.4 on MacOS X and have been attempting to run
some
landscape analysis with the r.li modules. I can run the r.li.setup
module
just fine, but when I attempt to run r.li.patchnum or the density
function
it just crashes immediately. I've run it from the python GUI and the
command-line and the same thing happens. Is there a fix for this?

Are you able to reproduce it with the Spearfish or North Carolina
data set? If yes, please tell us the steps and we try to reproduce
the problem. I ran a few r.li measures successfully recently on Linux
(64bit).

Markus

6

On Aug 10, 2009, at 1:44 PM, Markus Neteler wrote:

On Mon, Aug 10, 2009 at 8:20 PM, Nathan Lemoine<lemoine.nathan@gmail.com> wrote:

I've attempted to find the config file on my harddrive and can't seem to
locate it. It shows up when I run r.li.setup in the list of available config
files and seems to load fine, but when i search for the file it isn't on my
harddrive. The config file is supposed to be in the path ~/.r.li/history,
but r.li.setup does not create such a path.

Then that's perhaps the problem? William, does it create on your Mac
the directory?

Yes, ~/.r.li/history was created for me. And my test config. It looks sensible:

SAMPLINGFRAME 0|0|1|1
SAMPLEAREA -1|-1|0.03571428571428571|0.02631578947368421
MOVINGWINDOW

When I ran r.li.patchdensity, I got the segfault (same output and crash log).

Markus

I've run the r.le.setup which
creates the appropriate file path in my user folder to the r.le config
files, but r.li does not seem to do this.

On Aug 10, 2009, at 12:49 PM, Markus Neteler wrote:

Can you please send the config file to me?

Markus

PS: please keep the list in the loop since other may be able to help
even better than me...

On Mon, Aug 10, 2009 at 4:44 PM, Nathan Lemoine<lemoine.nathan@gmail.com>
wrote:

I copied landuse96_28m file to the user1 MAPSET (I named the copy
"landuse"), and used r.li.setup to make my config file. I named the
config
file "mov" and selected the "landuse" raster file. I set the sampling
frame
to the whole region, and set the sampling area to a moving window. I
chose a
rectangular window of 5x5 cells. The config file was the set and seemed
to
be fine. I attempted to run r.li.patchnum rast=landuse config=mov
output=test and got the following reports:

-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/

All generalizations are dangerous, even this one.

7

On Mon, Aug 10, 2009 at 4:44 PM, Nathan Lemoine<lemoine.nathan@gmail.com> wrote:

I copied landuse96_28m file to the user1 MAPSET (I named the copy
"landuse"),

(note that above step isn't really needed, but ok):

and used r.li.setup to make my config file. I named the config
file "mov" and selected the "landuse" raster file. I set the sampling frame
to the whole region, and set the sampling area to a moving window. I chose a
rectangular window of 5x5 cells. The config file was the set and seemed to
be fine. I attempted to run r.li.patchnum rast=landuse config=mov
output=test and got the following reports:

This is the GRASS terminal report:

Illegal filename. Character < > not allowed.
Illegal filename. Character < > not allowed.

...

I have tried:

GRASS 6.5.svn (nc_spm_08):~ > g.copy rast=landuse96_28m,landuse
Copy raster <landuse96_28m@PERMANENT> to current mapset as <landuse>
GRASS 6.5.svn (nc_spm_08):~ > g.region rast=landuse
GRASS 6.5.svn (nc_spm_08):~ > r.li.patchnum landuse96_28m conf=mov
output=test --o
r.li.worker (pid 29902) terminated
r.li.worker (pid 29909) terminated
r.li.worker (pid 29910) terminated
r.li.worker (pid 29905) terminated
r.li.worker (pid 29903) terminated
r.li.worker (pid 29908) terminated
r.li.worker (pid 29906) terminated
r.li.worker (pid 29907) terminated
r.li.worker (pid 29904) terminated
r.li.worker (pid 29911) terminated

Also 6.4:
GRASS 6.4.0svn (nc_spm_08):~ > r.li.patchnum landuse96_28m conf=mov
output=test --o
r.li.worker (pid 30035) terminated
r.li.worker (pid 30034) terminated
r.li.worker (pid 30029) terminated
r.li.worker (pid 30030) terminated
r.li.worker (pid 30033) terminated
r.li.worker (pid 30037) terminated
r.li.worker (pid 30038) terminated
r.li.worker (pid 30032) terminated
r.li.worker (pid 30036) terminated
r.li.worker (pid 30031) terminated

It works on Linux but apparently the map name gets lost in the r.li daemon
on MacOSX.

I am afraid that only debugging on Mac helps. The easiest is perhaps
to add G_debug() statements if you don't want/cannot use a gdb debugger -
to figure out in which code area of r.li.daemon or r.li.patchnum the name
disappears.

Markus

8

Here's an interesting clue (or maybe a completely different problem) - our previous crash was run 64bit. When I force the 32bit binary to run with arch -386 (OSX-only command) I still get lots of:

WARNING: Unable to open header file for raster map <@(null)>
CHILD[pid = xxxxx]: unable to open mask ... continue without!!!

but no illegal filename errors and no crash and all the workers processes complete. I don't know what the output is supposed to look like, but the raster looks sensible.

I'll try poking around with some debugging. Maybe a bug report is in order also?

On Aug 11, 2009, at 12:28 AM, Markus Neteler wrote:

On Mon, Aug 10, 2009 at 4:44 PM, Nathan Lemoine<lemoine.nathan@gmail.com> wrote:

I copied landuse96_28m file to the user1 MAPSET (I named the copy
"landuse"),

(note that above step isn't really needed, but ok):

and used r.li.setup to make my config file. I named the config
file "mov" and selected the "landuse" raster file. I set the sampling frame
to the whole region, and set the sampling area to a moving window. I chose a
rectangular window of 5x5 cells. The config file was the set and seemed to
be fine. I attempted to run r.li.patchnum rast=landuse config=mov
output=test and got the following reports:

This is the GRASS terminal report:

Illegal filename. Character < > not allowed.

...

I have tried:

GRASS 6.5.svn (nc_spm_08):~ > g.copy rast=landuse96_28m,landuse
Copy raster <landuse96_28m@PERMANENT> to current mapset as <landuse>
GRASS 6.5.svn (nc_spm_08):~ > g.region rast=landuse
GRASS 6.5.svn (nc_spm_08):~ > r.li.patchnum landuse96_28m conf=mov
output=test --o
r.li.worker (pid 29902) terminated
r.li.worker (pid 29909) terminated
r.li.worker (pid 29910) terminated
r.li.worker (pid 29905) terminated
r.li.worker (pid 29903) terminated
r.li.worker (pid 29908) terminated
r.li.worker (pid 29906) terminated
r.li.worker (pid 29907) terminated
r.li.worker (pid 29904) terminated
r.li.worker (pid 29911) terminated

Also 6.4:
GRASS 6.4.0svn (nc_spm_08):~ > r.li.patchnum landuse96_28m conf=mov
output=test --o
r.li.worker (pid 30035) terminated
r.li.worker (pid 30034) terminated
r.li.worker (pid 30029) terminated
r.li.worker (pid 30030) terminated
r.li.worker (pid 30033) terminated
r.li.worker (pid 30037) terminated
r.li.worker (pid 30038) terminated
r.li.worker (pid 30032) terminated
r.li.worker (pid 30036) terminated
r.li.worker (pid 30031) terminated

It works on Linux but apparently the map name gets lost in the r.li daemon
on MacOSX.

I am afraid that only debugging on Mac helps. The easiest is perhaps
to add G_debug() statements if you don't want/cannot use a gdb debugger -
to figure out in which code area of r.li.daemon or r.li.patchnum the name
disappears.

Markus
_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/

"Those people who most want to rule people are, ipso-facto, those least suited to do it."

- A rule of the universe, from the HitchHiker's Guide to the Galaxy

9

Markus - I ran patchdensity, here's the upper-left corner of the 32bit run on the spearfish landuse raster, does this look the same as you get? I'm wondering about the overlapping parts, if they should be combined like that (it's working despite the mask errors) or if they should be a single color/value or something else (it's not working)?

(attachments)

Picture 1.png

10

On Tue, Aug 11, 2009 at 5:56 PM, William
Kyngesburye<woklist@kyngchaos.com> wrote:

Markus - I ran patchdensity, here's the upper-left corner of the 32bit run
on the spearfish landuse raster, does this look the same as you get? I'm
wondering about the overlapping parts, if they should be combined like that
(it's working despite the mask errors) or if they should be a single
color/value or something else (it's not working)?

# Spearfish

g.region rast=landuse
r.li.patchnum map="landuse" conf="mov" output="test"
d.mon x0
d.rast landuse
d.mon x1
d.rast test

My result, upper left corner only, is attached (Mandriva Linux, 64bit).
Visually it looks ok to me.

Markus

(attachments)

r_li_patchnum.png

11

Markus Neteler ha scritto:

My result, upper left corner only, is attached (Mandriva Linux, 64bit).
Visually it looks ok to me.

I'm also having problems with r.li:

r.li.shannon map=uso conf=latignano_5 output=provaln

WARNING: Unable to open header file for raster map <@(null)>
CHILD[pid = 1954]: unable to open mask ... continue without!!!
WARNING: Unable to open header file for raster map <@(null)>
CHILD[pid = 1953]: unable to open mask ... continue without!!!
WARNING: Unable to open header file for raster map <@(null)>
CHILD[pid = 1952]: unable to open mask ... continue without!!!
WARNING: Unable to open header file for raster map <@(null)>
CHILD[pid = 1951]: unable to open mask ... continue without!!!
WARNING: Unable to open header file for raster map <@(null)>
CHILD[pid = 1950]: unable to open mask ... continue without!!!
WARNING: Unable to open header file for raster map <@(null)>
CHILD[pid = 1949]: unable to open mask ... continue without!!!
WARNING: Unable to open header file for raster map <@(null)>
CHILD[pid = 1948]: unable to open mask ... continue without!!!
WARNING: Unable to open header file for raster map <@(null)>
CHILD[pid = 1947]: unable to open mask ... continue without!!!
WARNING: Unable to open header file for raster map <@(null)>
CHILD[pid = 1946]: unable to open mask ... continue without!!!
WARNING: Unable to open header file for raster map <@(null)>
CHILD[pid = 1945]: unable to open mask ... continue without!!!
Segmentation fault

Debian ustable, 64 bit.
Any hint appreciated.
--
Paolo Cavallini: http://www.faunalia.it/pc

12

On Wed, Aug 12, 2009 at 3:38 PM, Paolo Cavallini<cavallini@faunalia.it> wrote:

Markus Neteler ha scritto:

My result, upper left corner only, is attached (Mandriva Linux, 64bit).
Visually it looks ok to me.

I'm also having problems with r.li:

r.li.shannon map=uso conf=latignano_5 output=provaln

WARNING: Unable to open header file for raster map <@(null)>
CHILD[pid = 1954]: unable to open mask ... continue without!!!
WARNING: Unable to open header file for raster map <@(null)>
CHILD[pid = 1953]: unable to open mask ... continue without!!!
WARNING: Unable to open header file for raster map <@(null)>
CHILD[pid = 1952]: unable to open mask ... continue without!!!
WARNING: Unable to open header file for raster map <@(null)>
CHILD[pid = 1951]: unable to open mask ... continue without!!!
WARNING: Unable to open header file for raster map <@(null)>
CHILD[pid = 1950]: unable to open mask ... continue without!!!
WARNING: Unable to open header file for raster map <@(null)>
CHILD[pid = 1949]: unable to open mask ... continue without!!!
WARNING: Unable to open header file for raster map <@(null)>
CHILD[pid = 1948]: unable to open mask ... continue without!!!
WARNING: Unable to open header file for raster map <@(null)>
CHILD[pid = 1947]: unable to open mask ... continue without!!!
WARNING: Unable to open header file for raster map <@(null)>
CHILD[pid = 1946]: unable to open mask ... continue without!!!
WARNING: Unable to open header file for raster map <@(null)>
CHILD[pid = 1945]: unable to open mask ... continue without!!!
Segmentation fault

Debian ustable, 64 bit.
Any hint appreciated.

I see three options:
- use the debugger
  http://grass.osgeo.org/wiki/GRASS_Debugging#Using_GDB
- otherwise fill the source code with G_debug() statements to figure out
  where it fails (needs recompilation obviously)
- grant access to a machine where it fails, hoping that a GRASS
   developers tracks it down for you :slight_smile:

Markus

13

I did a little crude debugging yesterday (G_message) and found it failed for me in daemon.c, line 626 / nextArea()

     else {
  return next(g, m);
     }

But all this tells me is that at this point the mask name is missing, not where it was lost.

I didn't have more time to poke around more.

Note: bug report at http://trac.osgeo.org/grass/ticket/718

On Aug 12, 2009, at 9:34 AM, Markus Neteler wrote:

On Wed, Aug 12, 2009 at 3:38 PM, Paolo Cavallini<cavallini@faunalia.it> wrote:

Markus Neteler ha scritto:

My result, upper left corner only, is attached (Mandriva Linux, 64bit).
Visually it looks ok to me.

I'm also having problems with r.li:

r.li.shannon map=uso conf=latignano_5 output=provaln

WARNING: Unable to open header file for raster map <@(null)>
CHILD[pid = 1954]: unable to open mask ... continue without!!!
WARNING: Unable to open header file for raster map <@(null)>
CHILD[pid = 1953]: unable to open mask ... continue without!!!
WARNING: Unable to open header file for raster map <@(null)>
CHILD[pid = 1952]: unable to open mask ... continue without!!!
WARNING: Unable to open header file for raster map <@(null)>
CHILD[pid = 1951]: unable to open mask ... continue without!!!
WARNING: Unable to open header file for raster map <@(null)>
CHILD[pid = 1950]: unable to open mask ... continue without!!!
WARNING: Unable to open header file for raster map <@(null)>
CHILD[pid = 1949]: unable to open mask ... continue without!!!
WARNING: Unable to open header file for raster map <@(null)>
CHILD[pid = 1948]: unable to open mask ... continue without!!!
WARNING: Unable to open header file for raster map <@(null)>
CHILD[pid = 1947]: unable to open mask ... continue without!!!
WARNING: Unable to open header file for raster map <@(null)>
CHILD[pid = 1946]: unable to open mask ... continue without!!!
WARNING: Unable to open header file for raster map <@(null)>
CHILD[pid = 1945]: unable to open mask ... continue without!!!
Segmentation fault

Debian ustable, 64 bit.
Any hint appreciated.

I see three options:
- use the debugger
http://grass.osgeo.org/wiki/GRASS_Debugging#Using_GDB
- otherwise fill the source code with G_debug() statements to figure out
where it fails (needs recompilation obviously)
- grant access to a machine where it fails, hoping that a GRASS
  developers tracks it down for you :slight_smile:

Markus
_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/

[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...

- HitchHiker's Guide to the Galaxy

14

I've tried running gdb on the r.li.patchnum program, but I have no debugging or programming experience, so I can only report the error messages I've received. running the program normally, without of gdb, gets me the error:

Illegal filename. Character <> not allowed.
WARNING: Unable to open header file for raster map <@(null)>
CHILD[pid = 326]: unable to open mask ... continue without!!!

this error message typically just repeats itself.

running the program with gdb gets me:

Starting program: /Applications/GRASS-6.4.app/Contents/MacOS/bin/r.li.patchnum .li.patchnum map=northrast conf=whole out=test

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000008
0x00007fff806b0964 in strcmp ()

and if I backtrace:

(gdb) bt
#0 0x00007fff806b0964 in strcmp ()
#1 0x000000010005bc63 in parseSetup ()
#2 0x000000010005c899 in calculateIndex ()
#3 0x00000001000008c8 in start ()

that's as much as I've been able to learn so far given my limited skills at this.

On Aug 11, 2009, at 9:00 AM, William Kyngesburye wrote:

Here's an interesting clue (or maybe a completely different problem) - our previous crash was run 64bit. When I force the 32bit binary to run with arch -386 (OSX-only command) I still get lots of:

WARNING: Unable to open header file for raster map <@(null)>
CHILD[pid = xxxxx]: unable to open mask ... continue without!!!

but no illegal filename errors and no crash and all the workers processes complete. I don't know what the output is supposed to look like, but the raster looks sensible.

I'll try poking around with some debugging. Maybe a bug report is in order also?

On Aug 11, 2009, at 12:28 AM, Markus Neteler wrote:

On Mon, Aug 10, 2009 at 4:44 PM, Nathan Lemoine<lemoine.nathan@gmail.com> wrote:

I copied landuse96_28m file to the user1 MAPSET (I named the copy
"landuse"),

(note that above step isn't really needed, but ok):

and used r.li.setup to make my config file. I named the config
file "mov" and selected the "landuse" raster file. I set the sampling frame
to the whole region, and set the sampling area to a moving window. I chose a
rectangular window of 5x5 cells. The config file was the set and seemed to
be fine. I attempted to run r.li.patchnum rast=landuse config=mov
output=test and got the following reports:

This is the GRASS terminal report:

Illegal filename. Character < > not allowed.

...

I have tried:

GRASS 6.5.svn (nc_spm_08):~ > g.copy rast=landuse96_28m,landuse
Copy raster <landuse96_28m@PERMANENT> to current mapset as <landuse>
GRASS 6.5.svn (nc_spm_08):~ > g.region rast=landuse
GRASS 6.5.svn (nc_spm_08):~ > r.li.patchnum landuse96_28m conf=mov
output=test --o
r.li.worker (pid 29902) terminated
r.li.worker (pid 29909) terminated
r.li.worker (pid 29910) terminated
r.li.worker (pid 29905) terminated
r.li.worker (pid 29903) terminated
r.li.worker (pid 29908) terminated
r.li.worker (pid 29906) terminated
r.li.worker (pid 29907) terminated
r.li.worker (pid 29904) terminated
r.li.worker (pid 29911) terminated

Also 6.4:
GRASS 6.4.0svn (nc_spm_08):~ > r.li.patchnum landuse96_28m conf=mov
output=test --o
r.li.worker (pid 30035) terminated
r.li.worker (pid 30034) terminated
r.li.worker (pid 30029) terminated
r.li.worker (pid 30030) terminated
r.li.worker (pid 30033) terminated
r.li.worker (pid 30037) terminated
r.li.worker (pid 30038) terminated
r.li.worker (pid 30032) terminated
r.li.worker (pid 30036) terminated
r.li.worker (pid 30031) terminated

It works on Linux but apparently the map name gets lost in the r.li daemon
on MacOSX.

I am afraid that only debugging on Mac helps. The easiest is perhaps
to add G_debug() statements if you don't want/cannot use a gdb debugger -
to figure out in which code area of r.li.daemon or r.li.patchnum the name
disappears.

Markus
_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/

"Those people who most want to rule people are, ipso-facto, those least suited to do it."

- A rule of the universe, from the HitchHiker's Guide to the Galaxy

15

On Mon, Aug 17, 2009 at 2:59 AM, Nathan Lemoine<lemoine.nathan@gmail.com> wrote:

I've tried running gdb on the r.li.patchnum program, but I have no debugging
or programming experience, so I can only report the error messages I've
received. running the program normally, without of gdb, gets me the error:

Illegal filename. Character <> not allowed.
Illegal filename. Character <> not allowed.
Illegal filename. Character <> not allowed.
WARNING: Unable to open header file for raster map <@(null)>
CHILD[pid = 326]: unable to open mask ... continue without!!!

this error message typically just repeats itself.

Did you compile yourself? If yes, could you update from SVN
and recompile r.li*? I added a debug statement which you
can activate like this:

g.gisenv set=DEBUG=1

Then it should say more about this config file and its path.

running the program with gdb gets me:

Starting program:
/Applications/GRASS-6.4.app/Contents/MacOS/bin/r.li.patchnum .li.patchnum
map=northrast conf=whole out=test

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000008
0x00007fff806b0964 in strcmp ()

and if I backtrace:

(gdb) bt
#0 0x00007fff806b0964 in strcmp ()
#1 0x000000010005bc63 in parseSetup ()
#2 0x000000010005c899 in calculateIndex ()
#3 0x00000001000008c8 in start ()

It might come from the conf file not found.

that's as much as I've been able to learn so far given my limited skills at
this.

We are getting closer... :slight_smile:

Markus

16

Nathan Lemoine wrote:

I've tried running gdb on the r.li.patchnum program, but I have no
debugging or programming experience, so I can only report the
error messages I've received. running the program normally, without
of gdb, gets me the error:

Illegal filename. Character <> not allowed.
Illegal filename. Character <> not allowed.
Illegal filename. Character <> not allowed.
WARNING: Unable to open header file for raster map <@(null)>
CHILD[pid = 326]: unable to open mask ... continue without!!!

this error message typically just repeats itself.

....

running the program with gdb gets me:

Starting program:
/Applications/GRASS-6.4.app/Contents/MacOS/bin/r.li.patchnum .li.patchnum
map=northrast conf=whole out=test

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000008
0x00007fff806b0964 in strcmp ()

and if I backtrace:

(gdb) bt
#0 0x00007fff806b0964 in strcmp ()
#1 0x000000010005bc63 in parseSetup ()
#2 0x000000010005c899 in calculateIndex ()
#3 0x00000001000008c8 in start ()

you've done well with the backtrace Nathan, after so many months we
finally know where this bug is. I think Paolo might buy you a beer.
(gdb on Linux didn't give me much to go on, only that it finished
with error code 1)

see https://trac.osgeo.org/grass/ticket/718#comment:16

r.li.daemon is using strtok() in its multi-thread code, but that function
is not safe to use with threads and so the jobs collide and the program
breaks. Because r.li.daemon always starts 10 jobs, it breaks even if you
don't have a multi-processor CPU.

"The strtok() function uses a static buffer while parsing, so it's
not thread safe."

It doesn't look like it will be very hard to fix, but it's slightly
beyond my talents to do so.

Hamish

ps- for future reference, if you use "bt full" in gdb you get the value
of all variables, and if you type "l" you see which line in the source
code it got to. http://grass.osgeo.org/wiki/Bugs#Using_GDB

17

per Hamish I used some more gdb commands and got some more information:

(gdb) r.li.patchnum map=northrast conf=whole output=test
Starting program: /Applications/GRASS-6.4.app/Contents/MacOS/bin/r.li.patchnum .li.patchnum map=northrast conf=whole output=test
Reading symbols for shared libraries .++++++. done

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000008
0x00007fff806b0964 in strcmp ()
(gdb) bt full
#0 0x00007fff806b0964 in strcmp ()
No symbol table info available.
#1 0x000000010005bc63 in parseSetup ()
No symbol table info available.
#2 0x000000010005c899 in calculateIndex ()
No symbol table info available.
#3 0x00000001000008c8 in start ()
No symbol table info available.
(gdb) l
1 /var/tmp//cc9BQQ7d.s: No such file or directory.
  in /var/tmp//cc9BQQ7d.s
(gdb) frame 2
#2 0x000000010005c899 in calculateIndex ()
(gdb) l
1 in /var/tmp//cc9BQQ7d.s

it looks like this is the file where the information is getting lost. i hope this helps a bit more.

On Aug 17, 2009, at 2:35 AM, Hamish wrote:

Nathan Lemoine wrote:

I've tried running gdb on the r.li.patchnum program, but I have no
debugging or programming experience, so I can only report the
error messages I've received. running the program normally, without
of gdb, gets me the error:

Illegal filename. Character <> not allowed.
WARNING: Unable to open header file for raster map <@(null)>
CHILD[pid = 326]: unable to open mask ... continue without!!!

this error message typically just repeats itself.

....

running the program with gdb gets me:

Starting program:
/Applications/GRASS-6.4.app/Contents/MacOS/bin/r.li.patchnum .li.patchnum
map=northrast conf=whole out=test

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000008
0x00007fff806b0964 in strcmp ()

and if I backtrace:

(gdb) bt
#0 0x00007fff806b0964 in strcmp ()
#1 0x000000010005bc63 in parseSetup ()
#2 0x000000010005c899 in calculateIndex ()
#3 0x00000001000008c8 in start ()

you've done well with the backtrace Nathan, after so many months we
finally know where this bug is. I think Paolo might buy you a beer.
(gdb on Linux didn't give me much to go on, only that it finished
with error code 1)

see https://trac.osgeo.org/grass/ticket/718#comment:16

r.li.daemon is using strtok() in its multi-thread code, but that function
is not safe to use with threads and so the jobs collide and the program
breaks. Because r.li.daemon always starts 10 jobs, it breaks even if you
don't have a multi-processor CPU.

"The strtok() function uses a static buffer while parsing, so it's
not thread safe."

It doesn't look like it will be very hard to fix, but it's slightly
beyond my talents to do so.

Hamish

ps- for future reference, if you use "bt full" in gdb you get the value
of all variables, and if you type "l" you see which line in the source
code it got to. http://grass.osgeo.org/wiki/Bugs#Using_GDB