gcb output

[Florian Quetting]

Hello.

I wrote a litte program, that generates a SIGSEGV after a while.
parse_umfeld is my method. It runs through about 330 times without error,
but the next time, call to strlen (from within parse_umfeld) generates a
SIGSEGV.

How could I find out, why exactly the problem occures?

gdb bt gives:

Program received signal SIGSEGV, Segmentation fault.
0xb7e30173 in strlen () from /lib/tls/i686/cmov/libc.so.6
(gdb) bt
#0 0xb7e30173 in strlen () from /lib/tls/i686/cmov/libc.so.6
#1 0x0804a20a in c_Parser:arse_umfeld (this=0x8050050,
buffer=0x8053c8b
"<Feld><Boden>Rasen</Boden><Ameise><Typ>Rot</Typ><ID>1</ID><Blickrichtung>NO</Blickrichtung><Angegriffen>0</Angegriffen></Ameise></Feld><Feld><Boden>Rasen</Boden></Feld><Feld><Boden>Rasen</Boden></Feld"...)
at c_Parser.cpp:69
<snip>

What does entry #0 mean?

Regards,
Flo

 

[Karl Heinz Buchegger]

Hello.

I wrote a litte program, that generates a SIGSEGV after a while.
parse_umfeld is my method. It runs through about 330 times without error,
but the next time, call to strlen (from within parse_umfeld) generates a
SIGSEGV.

The problem with things like that is, that the actual program crash
is only lousy connected with the real problem. In other words: you
see the symptoms, but not the cause. You can bet your ass, that
nothing is wrong with strlen, but with the pointer you feed
to it.

How could I find out, why exactly the problem occures?

gdb bt gives:

Program received signal SIGSEGV, Segmentation fault.
0xb7e30173 in strlen () from /lib/tls/i686/cmov/libc.so.6
(gdb) bt
#0 0xb7e30173 in strlen () from /lib/tls/i686/cmov/libc.so.6
#1 0x0804a20a in c_Parser:arse_umfeld (this=0x8050050,
buffer=0x8053c8b
"<Feld><Boden>Rasen</Boden><Ameise><Typ>Rot</Typ><ID>1</ID><Blickrichtung>NO</Blickrichtung><Angegriffen>0</Angegriffen></Ameise></Feld><Feld><Boden>Rasen</Boden></Feld><Feld><Boden>Rasen</Boden></Feld"...)
at c_Parser.cpp:69
<snip>

What does entry #0 mean?

Forget it.
Concentrate on the string you feed to strlen().
It obviously is not '\0' terminated. The question is: Why?
You need to start with that problem. Eg. you could:
for testing purposes assume that this string is never longer
then eg. 1024 characters. You then could write your own
version of strlen, which checks for that and alert you.

Things like that are hard to diagnose. This is why professionals
recommend a different way of development: development in small
steps. Only add small code sections at a time and test them until
you are very certain that they work ok. If you discover a bug you
can be very sure that it is somehow related to the last additions
you made. Since the last additions are relatively small (remember:
small steps), it is far easier to find the problem.

Also: Why are you using C-style strings instead of std::string ?

Also: You are aware that there are working XML readers available
for free?

 

[Mark P]

Hello.

I wrote a litte program, that generates a SIGSEGV after a while.
parse_umfeld is my method. It runs through about 330 times without error,
but the next time, call to strlen (from within parse_umfeld) generates a
SIGSEGV.

How could I find out, why exactly the problem occures?

gdb bt gives:

Program received signal SIGSEGV, Segmentation fault.
0xb7e30173 in strlen () from /lib/tls/i686/cmov/libc.so.6
(gdb) bt
#0 0xb7e30173 in strlen () from /lib/tls/i686/cmov/libc.so.6
#1 0x0804a20a in c_Parser:arse_umfeld (this=0x8050050,
buffer=0x8053c8b
"<Feld><Boden>Rasen</Boden><Ameise><Typ>Rot</Typ><ID>1</ID><Blickrichtung>NO</Blickrichtung><Angegriffen>0</Angegriffen></Ameise></Feld><Feld><Boden>Rasen</Boden></Feld><Feld><Boden>Rasen</Boden></Feld"...)
at c_Parser.cpp:69
<snip>

What does entry #0 mean?

Regards,
Flo

You should find some gdb references online that explain this in more
detail. Briefly, as your program runs, the function main() runs, which
calls other functions, which may in turn call still other functions, and
so forth. #0 shows where the error occured: strlen(), #1 shows where
the call was made to strlen() in parse_umfeld, #2 shows where
parse_umfeld was called, and so forth. You can use the gdb commands
"up" and "down" to move between these "frames" and, within any given
frame, you can examine variables with the "print" command.

Like I said, though, you'll probably need to find some sort of tutorial
to get you started using gdb effectively.