[GRASS5] bug reports for GRASS 5.7

GRASS GRASS developer
1

The developer tools include the standard GNU tools, including gdb, the debugger.

So you start the program within the debugger using

gdb program_name (which is the full path to the grass module, in this case probably something like /usr/local/grass57-13_02_2004/bin/g.mapsets)

which will put you in to a gdb prompt. From there, enter
run -l

to start the program with -l as the argument. When you get to the error, it will put you back at the gdb prompt, and you can enter the command "where" to get a traceback of where it happened in the program. Use "quit" to get out to your shell.

Actually, you can probably skip all that, because I decided to test my instructions before sending, and my machine generates the error too. So keep this for future reference, and Glynn, here are the results, I wish they meant something to me:

(gdb) run -l
Starting program: /usr/local/grass57-13_02_2004/bin/g.mapsets -l
Reading symbols for shared libraries +++.. done

Program received signal SIGTRAP, Trace/breakpoint trap.
0x8fe1a528 in __dyld__dyld_start ()
(gdb) where
#0 0x8fe1a528 in __dyld__dyld_start ()
warning: ppc_frame_chain_valid: stack pointer from 0xbffffab4 to 0x1000 grows upward; assuming invalid

#1 0x00000000 in ?? ()

On Apr 2, 2004, at 15:01, Michael Barton wrote:

On Friday, April 2, 2004, at 12:54 PM, Glynn Clements wrote:

Can you run "g.mapsets -l" under a debugger and get a backtrace?

Probably.

I'm copying this to Scott Mitchell who may have a suggestion along these lines. I have all the Apple developer tools installed. So this means that I certainly have access to debugging tools. I simply don't know what they are. If you know of any generic ones for BSD Unix and/or tcshell, I will give them a try.

Michael
______________________________
Michael Barton, Professor & Curator
Department of Anthropology
Arizona State University
Tempe, AZ 85287-2402
USA

voice: 480-965-6262; fax: 480-965-7671

----
Scott Mitchell, Assistant Professor, Carleton University
Department of Geography & Environmental Studies, Loeb A209
Mailing: Loeb B349, 1125 Colonel By Dr., Ottawa, ON K1S 5B6 Canada
1-613-520-2600 x2695 Fax: 613-520-4301 Scott_Mitchell@carleton.ca

2

Scott Mitchell wrote:

So you start the program within the debugger using

gdb program_name (which is the full path to the grass module, in this
case probably something like
/usr/local/grass57-13_02_2004/bin/g.mapsets)

The actual program would be in etc/bin/cmd, e.g.

  /usr/local/grass57-13_02_2004/etc/bin/cmd/g.mapsets

Almost everything in the bin directory is a hard link to
etc/front.end.

which will put you in to a gdb prompt. From there, enter
run -l

to start the program with -l as the argument. When you get to the
error, it will put you back at the gdb prompt, and you can enter the
command "where" to get a traceback of where it happened in the program.
  Use "quit" to get out to your shell.

Actually, you can probably skip all that, because I decided to test my
instructions before sending, and my machine generates the error too.
So keep this for future reference, and Glynn, here are the results, I
wish they meant something to me:

(gdb) run -l
Starting program: /usr/local/grass57-13_02_2004/bin/g.mapsets -l
Reading symbols for shared libraries +++.. done

Program received signal SIGTRAP, Trace/breakpoint trap.
0x8fe1a528 in __dyld__dyld_start ()

This is a red herring; can you continue until you get the actual
SIGBUS signal?

--
Glynn Clements <glynn.clements@virgin.net>

3

On Friday, Apr 2, 2004, at 17:53 Canada/Eastern, Glynn Clements wrote:

Scott Mitchell wrote:

So you start the program within the debugger using
...

The actual program would be in etc/bin/cmd, e.g.
  /usr/local/grass57-13_02_2004/etc/bin/cmd/g.mapsets
Almost everything in the bin directory is a hard link to
etc/front.end.

Oof, I knew I was forgetting something...

...

(gdb) run -l
Starting program: /usr/local/grass57-13_02_2004/bin/g.mapsets -l
Reading symbols for shared libraries +++.. done

Program received signal SIGTRAP, Trace/breakpoint trap.
0x8fe1a528 in __dyld__dyld_start ()

This is a red herring; can you continue until you get the actual
SIGBUS signal?

Aha ! Now this is more useful, even I can see that:

(gdb) run -l
Starting program: /usr/local/grass57-13_02_2004/etc/bin/cmd/g.mapsets -l
Reading symbols for shared libraries +++++.. done

Program received signal EXC_BAD_ACCESS, Could not access memory.
0x90006f40 in strlen ()
(gdb) where
#0 0x90006f40 in strlen ()
#1 0x0022f100 in G_store (s=0x0) at store.c:16
#2 0x0000280c in get_available_mapsets () at get_maps.c:14
#3 0x00001ff4 in main (argc=2, argv=0xbffffa3c) at main_cmd.c:68

------
Scott W. Mitchell Scott_Mitchell@carleton.ca
Department of Geography and Environmental Studies
Carleton University, B349 Loeb Building
Ottawa, ON Canada
+1-613-520-2600 ext 2695

4

Scott Mitchell wrote:

> > (gdb) run -l
> > Starting program: /usr/local/grass57-13_02_2004/bin/g.mapsets -l
> > Reading symbols for shared libraries +++.. done
> >
> > Program received signal SIGTRAP, Trace/breakpoint trap.
> > 0x8fe1a528 in __dyld__dyld_start ()
>
> This is a red herring; can you continue until you get the actual
> SIGBUS signal?

Aha ! Now this is more useful, even I can see that:

(gdb) run -l
Starting program: /usr/local/grass57-13_02_2004/etc/bin/cmd/g.mapsets -l
Reading symbols for shared libraries +++++.. done

Program received signal EXC_BAD_ACCESS, Could not access memory.
0x90006f40 in strlen ()
(gdb) where
#0 0x90006f40 in strlen ()
#1 0x0022f100 in G_store (s=0x0) at store.c:16
#2 0x0000280c in get_available_mapsets () at get_maps.c:14
#3 0x00001ff4 in main (argc=2, argv=0xbffffa3c) at main_cmd.c:68

That makes sense. In the loop:

    while ( ms[nmapsets] )
        mapset_name[nmapsets++] = G_store (ms[nmapsets]);

it is undefined as to whether the value of nmapsets on the RHS is the
old value or the updated value. In your case, it happens to be the
updated value. I've committed an updated version which uses a for
loop:

    for (nmapsets = 0; ms[nmapsets]; nmapsets++)
        mapset_name[nmapsets] = G_store (ms[nmapsets]);

--
Glynn Clements <glynn.clements@virgin.net>

5

Great, thanks. I was just looking at it too, in an effort to start "thinking in C" again and get more familiar with GRASS code now that term is ending. I had got as far as to figure out that the error was happening was the routine got to the end of the list of mapsets, but then got stuck as to the cause. Your explanation is "illuminating" as usual.

Cheers,
Scott

On Friday, Apr 2, 2004, at 18:57 Canada/Eastern, Glynn Clements wrote:

Scott Mitchell wrote:

(gdb) run -l
Starting program: /usr/local/grass57-13_02_2004/bin/g.mapsets -l
Reading symbols for shared libraries +++.. done

Program received signal SIGTRAP, Trace/breakpoint trap.
0x8fe1a528 in __dyld__dyld_start ()

This is a red herring; can you continue until you get the actual
SIGBUS signal?

Aha ! Now this is more useful, even I can see that:

(gdb) run -l
Starting program: /usr/local/grass57-13_02_2004/etc/bin/cmd/g.mapsets -l
Reading symbols for shared libraries +++++.. done

Program received signal EXC_BAD_ACCESS, Could not access memory.
0x90006f40 in strlen ()
(gdb) where
#0 0x90006f40 in strlen ()
#1 0x0022f100 in G_store (s=0x0) at store.c:16
#2 0x0000280c in get_available_mapsets () at get_maps.c:14
#3 0x00001ff4 in main (argc=2, argv=0xbffffa3c) at main_cmd.c:68

That makes sense. In the loop:

    while ( ms[nmapsets] )
        mapset_name[nmapsets++] = G_store (ms[nmapsets]);

it is undefined as to whether the value of nmapsets on the RHS is the
old value or the updated value. In your case, it happens to be the
updated value. I've committed an updated version which uses a for
loop:

    for (nmapsets = 0; ms[nmapsets]; nmapsets++)
        mapset_name[nmapsets] = G_store (ms[nmapsets]);

--
Glynn Clements <glynn.clements@virgin.net>

------
Scott W. Mitchell Scott_Mitchell@carleton.ca
Department of Geography and Environmental Studies
Carleton University, B349 Loeb Building
Ottawa, ON Canada
+1-613-520-2600 ext 2695