Compiler problem....unique to C or compiler???

[mdh]

I am working on 5.11 ( once again).
So, just stepping through code in the debugger, and get this...and
cannot proceed. Have posted to the Xcode forum, but my guess is the
real gurus are here in C!! Not sure if this is a strict "C" issue,
but I am sure you will let me know !!

The code is simply this, with 2 command line arguments:

#include <stdio.h>

int astrcomp(const char *, const char *);

int main (int argc, const char * argv[]) {
int i;
i = astrcomp(argv[1], argv[2]);
if ( i == 0)
printf(" \"%s\" equals \"%s\" ", argv[1], argv[2] );
else if ( i > 0 )
printf(" \"%s\" is greater than \"%s\" ", argv[1], argv[2] );
else if ( i < 0 )
printf(" \"%s\" is less than \"%s\" ", argv[1], argv[2] );

return 0;
}


int astrcomp(const char *s, const char *t){
for (; *s == *t ; s++, t++)
if ( *s == 0)
return 0;
return (*s - *t);
}


Pending breakpoint 1 - ""main.c:3" resolved
gdb stack crawl at point of internal error:
[ 0 ] /Developer/usr/libexec/gdb/gdb-i386-apple-darwin (align_down
+0x0) [0x11d2ff]
[ 1 ] /Developer/usr/libexec/gdb/gdb-i386-apple-darwin
(step_into_current_inlined_subroutine+0x109) [0x6d5b2]
[ 2 ] /Developer/usr/libexec/gdb/gdb-i386-apple-darwin
(inlined_function_update_call_stack+0x154a) [0x6ebbe]
[ 3 ] /Developer/usr/libexec/gdb/gdb-i386-apple-darwin
(handle_inferior_event+0xbfe) [0x68332]
[ 4 ] /Developer/usr/libexec/gdb/gdb-i386-apple-darwin
(fetch_inferior_event+0x125) [0x6abda]
[ 5 ] /Developer/usr/libexec/gdb/gdb-i386-apple-darwin
(inferior_event_handler+0xd0) [0x7e9c4]
[ 6 ] /Developer/usr/libexec/gdb/gdb-i386-apple-darwin
(handle_file_event+0x159) [0x7c8ac]
[ 7 ] /Developer/usr/libexec/gdb/gdb-i386-apple-darwin (process_event
+0x81) [0x7c49e]
[ 8 ] /Developer/usr/libexec/gdb/gdb-i386-apple-darwin
(gdb_do_one_event+0x46a) [0x7d33c]
[ 9 ] /Developer/usr/libexec/gdb/gdb-i386-apple-darwin (catch_errors
+0x4d) [0x77487]
[ 10 ] /Developer/usr/libexec/gdb/gdb-i386-apple-darwin
(start_event_loop+0x52) [0x7c4fd]
[ 11 ] /Developer/usr/libexec/gdb/gdb-i386-apple-darwin
(captured_command_loop+0x12) [0x7821e]
[ 12 ] /Developer/usr/libexec/gdb/gdb-i386-apple-darwin (catch_errors
+0x4d) [0x77487]
/SourceCache/gdb/gdb-768/src/gdb/inlining.c:1742: internal-error:
step_into_current_inlined_subroutine: Assertion
`current_inlined_subroutine_call_stack_start_pc() == stop_pc' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
The Debugger has exited with status 1.The Debugger has exited with
status 1.


Any insight is, as always , appreciated.

 

[jacob navia]

mdh wrote:
[snip]

A problem internal to GDB has been detected,
further debugging may prove unreliable.

Can you read?

A problem in the debugger logic (the debugger has crashed)
happens. This may or may not have anything to do with your program.

Solutions:

1) Use another debugger and development system that has less bugs
2) Go to the GDB support groups and ask for help. You may find
someone that is willing to help you.
3) Search in google and other engines about your bug in gdb.
4) Download the sources of gdb for your OS and gix the bug.

 

[Tor Rustad]

I am working on 5.11 ( once again).
So, just stepping through code in the debugger, and get this...and
cannot proceed. Have posted to the Xcode forum, but my guess is the
real gurus are here in C!! Not sure if this is a strict "C" issue,
but I am sure you will let me know !!

The code is simply this, with 2 command line arguments:

#include <stdio.h>

int astrcomp(const char *, const char *);

int main (int argc, const char * argv[]) {

What is the const doing there?

int i;
i = astrcomp(argv[1], argv[2]);

What was argc before doing that call astrcomp()?

if ( i == 0)
printf(" \"%s\" equals \"%s\" ", argv[1], argv[2] );

Here and below, the \n is missing e.g.:

printf(" \"%s\" equals \"%s\" \n", argv[1], argv[2]);

else if ( i > 0 )
printf(" \"%s\" is greater than \"%s\" ", argv[1], argv[2] );
else if ( i < 0 )
printf(" \"%s\" is less than \"%s\" ", argv[1], argv[2] );

return 0;
}


int astrcomp(const char *s, const char *t){
for (; *s == *t ; s++, t++)
if ( *s == 0)

if (*s == '\0')

return 0;
return (*s - *t);

return type of astrcomp() is int, not char.

 

[Richard Heathfield]

mdh said:

#include <stdio.h>

int astrcomp(const char *, const char *);

int main (int argc, const char * argv[]) {
int i;
i = astrcomp(argv[1], argv[2]);

If I were you my first step would be to ensure that argc > 2 before calling
astrcomp with argv[1] and argv[2] as arguments.

 

[mdh]

Thank you for going through the code. That is not really what I
expected...I was hoping someone would be able to say...oh...the debug
message means this ( because it is unique to C, not the compiler) ,
it is corrected like this, and then I would be able to do what you
did...
But, thank you anyway.

 

[mdh]

i = astrcomp(argv[1], argv[2]);

If I were you my first step would be to ensure that argc > 2 before calling
astrcomp with argv[1] and argv[2] as arguments.

Richard, thank you. I did change that but get the same result...but
your point is well taken. The compiler has significantly changed since
the introduction of 10.5 ( Apple) and so I am looking there for a
fix.

 

[jacob navia]

Thank you for going through the code. That is not really what I
expected...I was hoping someone would be able to say...oh...the debug
message means this ( because it is unique to C, not the compiler) ,
it is corrected like this, and then I would be able to do what you
did...
But, thank you anyway.

Impossible to tell if the debugger crashes because of your program or
because some other reason without knowing the debugger in detail. In
this group we discuss the C language and not really gdb.

But you could try to debug another program to see if the debugger
crashes in the other program. If it crashes in the other program too,
you have surely a faulty debugger. If it doesn't crash in the new
program you have a debugger that crashes sometimes and could be used to
debug some programs and not others.

For instance write
#include <stdio.h>
int main(void) { printf("hello\n");}

Compile that program and:

1) does the debugger crashes when you try to debug that?
2) recompiler again your program with the same options. Does it work?


But this is long and boring work: debugging a debugger. I would just
stop and get a working compilation system first.

 

[jacob navia]

i = astrcomp(argv[1], argv[2]);

If I were you my first step would be to ensure that argc > 2 before calling
astrcomp with argv[1] and argv[2] as arguments.

Richard, thank you. I did change that but get the same result...but
your point is well taken. The compiler has significantly changed since
the introduction of 10.5 ( Apple) and so I am looking there for a
fix.

There is nothing in the user program that should make the debugger CRASH.
When the debugger crashes (as gdb says explicitly in the part you did
not read) there is not a lot that a user can do, and saying him that
should improve this or that in his program will not change the
debugger error.

> A problem internal to GDB has been detected,
> further debugging may prove unreliable.

This means that the debugger has an error, not the user program

 

[Walter Roberson]

mdh wrote:

if (*s == '\0')

That's equivilent. '\0' is defined to be 0. And char is
an integral type, so it doesn't make any difference whether
you use '\0' or 0 for the comparison.

return type of astrcomp() is int, not char.

*s is a char and *t is a char, and when char are used in arithmetic
expressions, they are widened to int (or, I suppose in theory
it could be unsigned int, if the implementation defaulted to
unsigned char and sizeof(unsigned char) == sizeof(int) ).

 

[mdh]

oops...missed that. Thanks for your input. My level of knowledge of C,
though growing steadily, does not even have compilers on the remote
horizon.

 

[James Kuyper]

That's equivilent. '\0' is defined to be 0. And char is
an integral type, so it doesn't make any difference whether
you use '\0' or 0 for the comparison.

Agreed; but I prefer to use '\0' in a character context, even though
it's not strictly needed, just to remind myself that it is a character
context.

 

[vippstar]

That's equivilent. '\0' is defined to be 0. And char is
an integral type, so it doesn't make any difference whether
you use '\0' or 0 for the comparison.

Correct, '\0' is equivalent to 0.
However, '\0' is of type 'int' and not 'char'.

*s is a char and *t is a char, and when char are used in arithmetic
expressions, they are widened to int (or, I suppose in theory
it could be unsigned int, if the implementation defaulted to
unsigned char and sizeof(unsigned char) == sizeof(int) ).

Incorrect, please take a look to n1124.pdf 6.3.1.1

 

[James Kuyper]

jacob navia wrote:
....

There is nothing in the user program that should make the debugger CRASH.

Ideally, no. However, if there is a bug in the debugger itself, whether
or not the debugger's bug is triggered will usually depend upon the code
being debugged.

When the debugger crashes (as gdb says explicitly in the part you did
not read) there is not a lot that a user can do, and saying him that
should improve this or that in his program will not change the
debugger error.

Not necessarily. The debugger error might be related to the code error.
Cleaning up the problems with the code may either help avoid the
debugger error, or help demonstrate that the debugger error is
independent of the code error. And, finally, cleaning up the problems
with the code is a good idea in itself, regardless of anything else.

 

[Tor Rustad]

That's equivilent. '\0' is defined to be 0. And char is
an integral type, so it doesn't make any difference whether
you use '\0' or 0 for the comparison.

Yes, the null character happens to be defined in C as a byte with all
bits 0. Once there was another standards Committee asking for this
requirement to be removed from C, this proposal was indeed rejected.

I still prefer

if (*s == '\0')

since it helps readability.

*s is a char and *t is a char, and when char are used in arithmetic
expressions, they are widened to int (or, I suppose in theory

Ooops, yes the expression will be promoted to signed int.

it could be unsigned int, if the implementation defaulted to
unsigned char and sizeof(unsigned char) == sizeof(int) ).

Really? Doesn't that imply signed preserving promotion rules??

void foo(unsigned char u)
{
int i = -1;

if (u > i)
printf("Value preserving: u to signed int\n");
else
printf("Signed preserving: i to unsigned int\n");
}

 

[Charlie Gordon]

Yes, the null character happens to be defined in C as a byte with all bits
0. Once there was another standards Committee asking for this requirement
to be removed from C, this proposal was indeed rejected.

I still prefer

if (*s == '\0')

since it helps readability.
Absolutely!


Ooops, yes the expression will be promoted to signed int.

They are 'widened' to int if int can represent all values of char. In the
special case where char is unsigned by default and has the same size as int,
they are promoted to unsigned int.

Really? Doesn't that imply signed preserving promotion rules??

No, it implements value preserving promotion.

void foo(unsigned char u)
{
int i = -1;

if (u > i)
printf("Value preserving: u to signed int\n");
else
printf("Signed preserving: i to unsigned int\n");
}

Your interpretation is not correct: if unsigned char has the same size as
unsigned int, you are indeed comparing an int and an unsigned int. The
standard mandates that the int be converted to unsigned int and the
comparison be performed on unsigned ints. The result is surprising, but
precisely defined in the standard.

 

[Charlie Gordon]

Correct, '\0' is equivalent to 0.
However, '\0' is of type 'int' and not 'char'.

Incorrect, please take a look to n1124.pdf 6.3.1.1

Please expand on this, I don't see how the language of 6.3.1.1 leads to this
conclusion.
Also please refer to the most up to date version of the Standard, namely
n1256.pdf

 

[CBFalconer]

.... snip ...

Also please refer to the most up to date version of the Standard,
namely n1256.pdf

That makes very little difference, as there are few changes between
N869, N1124, and N1256. The great advantage of N869 is that it is
available in text format, and is formatted to be compatible with
Usenet quoting, etc. I have a suitable version, bzip2 compressed,
available on my download section.

 

[James Kuyper]

Please expand on this, I don't see how the language of 6.3.1.1 leads to this
conclusion.

It doesn't, 6.3.1.1 clearly supports the assertion made by Walter
Roberson and labeled as "incorrect" by vippstar.