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

Discussion in 'C Programming' started by mdh, Nov 18, 2007.

  1. mdh

    mdh Guest

    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.
    mdh, Nov 18, 2007
    1. Advertisements

  2. mdh

    jacob navia Guest

    mdh wrote:
    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.


    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.
    jacob navia, Nov 18, 2007
    1. Advertisements

  3. mdh

    Tor Rustad Guest

    What is the const doing there?
    What was argc before doing that call astrcomp()?
    Here and below, the \n is missing e.g.:

    printf(" \"%s\" equals \"%s\" \n", argv[1], argv[2]);
    if (*s == '\0')
    return type of astrcomp() is int, not char.
    Tor Rustad, Nov 18, 2007
  4. mdh said:
    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 Heathfield, Nov 18, 2007
  5. mdh

    mdh Guest

    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
    But, thank you anyway.
    mdh, Nov 18, 2007
  6. mdh

    mdh Guest

    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
    mdh, Nov 18, 2007
  7. mdh

    jacob navia Guest

    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, Nov 18, 2007
  8. mdh

    jacob navia Guest

    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.
    This means that the debugger has an error, not the user program
    jacob navia, Nov 18, 2007
  9. 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.

    *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) ).
    Walter Roberson, Nov 18, 2007
  10. mdh

    mdh Guest

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

    James Kuyper Guest

    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
    James Kuyper, Nov 19, 2007
  12. mdh

    vippstar Guest

    Correct, '\0' is equivalent to 0.
    However, '\0' is of type 'int' and not 'char'.
    Incorrect, please take a look to n1124.pdf
    vippstar, Nov 19, 2007
  13. mdh

    James Kuyper Guest

    jacob navia wrote:
    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.
    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.
    James Kuyper, Nov 19, 2007
  14. mdh

    Tor Rustad Guest

    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.
    Ooops, yes the expression will be promoted to signed 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");
    printf("Signed preserving: i to unsigned int\n");
    Tor Rustad, Nov 20, 2007
  15. 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.
    No, it implements value preserving promotion.
    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, Nov 30, 2007
  16. Please expand on this, I don't see how the language of leads to this
    Also please refer to the most up to date version of the Standard, namely
    Charlie Gordon, Nov 30, 2007
  17. mdh

    CBFalconer Guest

    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.
    CBFalconer, Nov 30, 2007
  18. mdh

    James Kuyper Guest

    It doesn't, clearly supports the assertion made by Walter
    Roberson and labeled as "incorrect" by vippstar.
    James Kuyper, Nov 30, 2007
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.