[GRASS-user] r.li help

[Nathan Lemoine]

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