crash on centos 5

Discussion in 'C Programming' started by fakessh @, Jun 5, 2012.

  1. fakessh @

    fakessh @ Guest

    hello doctor
    hello honorable

    I work on a small project in c.
    this my code
    https://github.com/fakessh/openprojectssl/blob/master/smtp_openssl.c

    I am confronted with problems of execution on different
    machines
    on centos 6 no problem
    on centos 5 crash
    Here the trace

    *** glibc detected *** ./smtp_openssl: free(): corrupted
    unsorted
    chunks: 0x08064998 ***
    *** glibc detected *** ./smtp_openssl: malloc(): memory
    corruption:
    0x080682b0 ***
    ======= Backtrace: =========
    /lib/libc.so.6[0x4c899c1d]
    /lib/libc.so.6(__libc_malloc+0x67)[0x4c89b7d7]
    /lib/ld-linux.so.2[0x4c81a3dd]
    /lib/ld-linux.so.2[0x4c823c11]
    /lib/ld-linux.so.2[0x4c81ffc6]
    /lib/ld-linux.so.2[0x4c823612]
    /lib/libc.so.6[0x4c938432]
    /lib/ld-linux.so.2[0x4c81ffc6]
    /lib/libc.so.6(__libc_dlopen_mode+0x55)[0x4c9385e5]
    /lib/libc.so.6[0x4c9151b9]
    /lib/libc.so.6(backtrace+0xf3)[0x4c915353]
    /lib/libc.so.6[0x4c890be1]
    /lib/libc.so.6[0x4c898ee5]
    /lib/libc.so.6(cfree+0x59)[0x4c899329]
    /lib/libcrypto.so.6(CRYPTO_free+0x3a)[0x4a683d6a]
    /lib/libcrypto.so.6[0x4a61994b]
    /lib/libcrypto.so.6(BIO_free+0xc1)[0x4a609f81]
    /lib/libcrypto.so.6(BIO_free_all+0x34)[0x4a609fd4]
    ../smtp_openssl[0x8048e2a]
    ../smtp_openssl[0x8049409]
    ../smtp_openssl[0x8049684]
    /lib/libc.so.6(__libc_start_main+0xdc)[0x4c846e9c]
    ../smtp_openssl[0x8048b21]
    ======= Memory map: ========
    08048000-0804a000 r-xp 00000000 08:03
    45932551 /home/fakessh/smtp_openssl
    0804a000-0804b000 rw-p 00001000 08:03
    45932551 /home/fakessh/smtp_openssl
    0804b000-0806c000 rw-p 00000000 00:00 0 [heap]
    459be000-459c9000 r-xp 00000000 08:01
    5669552 /lib/libgcc_s-4.1.2-20080825.so.1
    459c9000-459ca000 rw-p 0000a000 08:01
    5669552 /lib/libgcc_s-4.1.2-20080825.so.1
    4a5b1000-4a6db000 r-xp 00000000 08:01
    5669614 /lib/libcrypto.so.0.9.8e
    4a6db000-4a6ef000 rw-p 00129000 08:01
    5669614 /lib/libcrypto.so.0.9.8e
    4a6ef000-4a6f2000 rw-p 00000000 00:00 0
    4a6f4000-4a738000 r-xp 00000000 08:01 5669617
    /lib/libssl.so.0.9.8e
    4a738000-4a73c000 rw-p 00043000 08:01 5669617
    /lib/libssl.so.0.9.8e
    4c812000-4c82d000 r-xp 00000000 08:01 5668866
    /lib/ld-2.5.so
    4c82d000-4c82e000 r--p 0001a000 08:01 5668866
    /lib/ld-2.5.so
    4c82e000-4c82f000 rw-p 0001b000 08:01 5668866
    /lib/ld-2.5.so
    4c831000-4c983000 r-xp 00000000 08:01 5669439
    /lib/libc-2.5.so
    4c983000-4c984000 ---p 00152000 08:01 5669439
    /lib/libc-2.5.so
    4c984000-4c986000 r--p 00152000 08:01 5669439
    /lib/libc-2.5.so
    4c986000-4c987000 rw-p 00154000 08:01 5669439
    /lib/libc-2.5.so
    4c987000-4c98a000 rw-p 00000000 00:00 0
    4c9b7000-4c9c9000 r-xp 00000000 08:01 5669771
    /lib/libz.so.1.2.3
    4c9c9000-4c9ca000 rw-p 00011000 08:01 5669771
    /lib/libz.so.1.2.3
    4c9cc000-4c9cf000 r-xp 00000000 08:01 5669594
    /lib/libdl-2.5.so
    4c9cf000-4c9d0000 r--p 00002000 08:01 5669594
    /lib/libdl-2.5.so
    4c9d0000-4c9d1000 rw-p 00003000 08:01 5669594
    /lib/libdl-2.5.so
    4c9ef000-4ca05000 r-xp 00000000 08:01 5669736
    /lib/libselinux.so.1
    4ca05000-4ca07000 rw-p 00015000 08:01 5669736
    /lib/libselinux.so.1
    4ca09000-4ca44000 r-xp 00000000 08:01 5669665
    /lib/libsepol.so.1
    4ca44000-4ca45000 rw-p 0003b000 08:01 5669665
    /lib/libsepol.so.1
    4ca45000-4ca4f000 rw-p 00000000 00:00 0
    4ca51000-4ca62000 r-xp 00000000 08:01 5669591
    /lib/libresolv-2.5.so
    4ca62000-4ca63000 r--p 00010000 08:01 5669591
    /lib/libresolv-2.5.so
    4ca63000-4ca64000 rw-p 00011000 08:01 5669591
    /lib/libresolv-2.5.so
    4ca64000-4ca66000 rw-p 00000000 00:00 0
    4cbea000-4cbec000 r-xp 00000000 08:01 5669750
    /lib/libcom_err.so.2.1
    4cbec000-4cbed000 rw-p 00001000 08:01 5669750
    /lib/libcom_err.so.2.1
    4cbef000-4cc15000 r-xp 00000000 08:01
    6170613 /usr/lib/libk5crypto.so.3.1
    4cc15000-4cc16000 rw-p 00025000 08:01
    6170613 /usr/lib/libk5crypto.so.3.1
    4cc33000-4cc3b000 r-xp 00000000 08:01
    6170581 /usr/lib/libkrb5support.so.0.1
    4cc3b000-4cc3c000 rw-p 00007000 08:01
    6170581 /usr/lib/libkrb5support.so.0.1
    4cc3e000-4cc6b000 r-xp 00000000 08:01
    6170863 /usr/lib/libgssapi_krb5.so.2.2
    4cc6b000-4cc6c000 rw-p 0002d000 08:01
    6170863 /usr/lib/libgssapi_krb5.so.2.2
    4cc6e000-4cd02000 r-xp 00000000 08:01 6170784
    /usr/lib/libkrb5.so.3.3
    4cd02000-4cd05000 rw-p 00093000 08:01 6170784
    /usr/lib/libkrb5.so.3.3
    4cd07000-4cd09000 r-xp 00000000 08:01 5669639
    /lib/libkeyutils-1.2.so
    4cd09000-4cd0a000 rw-p 00001000 08:01 5669639
    /lib/libkeyutils-1.2.so
    b7700000-b7721000 rw-p 00000000 00:00 0
    b7721000-b7800000 ---p 00000000 00:00 0
    b7823000-b7827000 r-xp 00000000 08:01 5669630
    /lib/libnss_dns-2.5.so
    b7827000-b7828000 r--p 00003000 08:01 5669630
    /lib/libnss_dns-2.5.so
    b7828000-b7829000 rw-p 00004000 08:01 5669630
    /lib/libnss_dns-2.5.so
    b7829000-b7833000 r-xp 00000000 08:01
    5669632 /lib/libnss_files-2.5.so
    b7833000-b7834000 r--p 00009000 08:01
    5669632 /lib/libnss_files-2.5.so
    b7834000-b7835000 rw-p 0000a000 08:01
    5669632 /lib/libnss_files-2.5.so
    b7835000-b783a000 rw-p 00000000 00:00 0
    b784b000-b784c000 rw-p 00000000 00:00 0
    bfd80000-bfda1000 rw-p 00000000 00:00 0 [stack]
    ffffe000-fffff000 r-xp 00000000 00:00 0 [vdso]
    Abandon
     
    fakessh @, Jun 5, 2012
    #1
    1. Advertising

  2. fakessh @

    James Kuyper Guest

    On 06/05/2012 05:33 PM, fakessh @ wrote:
    > hello doctor
    > hello honorable
    >
    > I work on a small project in c.
    > this my code
    > https://github.com/fakessh/openprojectssl/blob/master/smtp_openssl.c
    >
    > I am confronted with problems of execution on different
    > machines
    > on centos 6 no problem
    > on centos 5 crash
    > Here the trace


    Your code calls malloc(), and writes through the returned pointer,
    without bothering to check whether or not that pointer is null, which
    would indicate an allocation failure. I'd recommend fixing that mistake
    before checking for anything more complicated than that.
     
    James Kuyper, Jun 5, 2012
    #2
    1. Advertising

  3. fakessh @

    fakessh @ Guest

    James Kuyper wrote:

    > On 06/05/2012 05:33 PM, fakessh @ wrote:
    >> hello doctor
    >> hello honorable
    >>
    >> I work on a small project in c.
    >> this my code
    >>

    https://github.com/fakessh/openprojectssl/blob/master/smtp_openssl.c
    >>
    >> I am confronted with problems of execution on different
    >> machines
    >> on centos 6 no problem
    >> on centos 5 crash
    >> Here the trace

    >
    > Your code calls malloc(), and writes through the returned

    pointer,
    > without bothering to check whether or not that pointer is

    null, which
    > would indicate an allocation failure. I'd recommend fixing

    that mistake
    > before checking for anything more complicated than that.


    i am updated my code with CHK_NULL define
    same error
     
    fakessh @, Jun 5, 2012
    #3
  4. fakessh @

    Ike Naar Guest

    On 2012-06-05, fakessh @ <> wrote:
    > this my code
    > https://github.com/fakessh/openprojectssl/blob/master/smtp_openssl.c


    > buff = malloc(bptr->length);
    >
    > #ifdef W32_NATIVE
    > memset(buff,0,sizeof(char*));
    > memcpy(buff, bptr->data, bptr->length-1);
    > #else
    > bzero(buff, sizeof(char*));
    > sprintf(buff, "%s", bptr->data);
    > #endif
    >
    > buff[bptr->length-1] = '\0';


    What is the point of the

    memset(buff,0,sizeof(char*));

    or

    bzero(buff, sizeof(char*));

    lines? If the size of the buffer "buff" is atleast sizeof(char*),
    the zeroed memory will immediately be overwritten, so the
    zeroing make no sense. And if the size of the buffer is
    less than sizeof(char*), the zeroing will write outside
    the bounds of the buffer.

    Also, if W32_NATIVE is undefined, the sprintf call
    will write strlen(bptr->data)+1 characters into buff
    (that is, the string pointed at by bptr->data, including
    the terminating null byte).
    Is it guaranteed that strlen(bptr->data)+1 is atmost
    bptr->length, so that the sprintf call will not write
    outside the allocated space for the buffer?

    And, as mentioned elsethread, you should account for the
    possibility that malloc returns a null pointer.
     
    Ike Naar, Jun 5, 2012
    #4
  5. fakessh @

    BartC Guest

    "fakessh @" <> wrote in message
    news:jqltvr$s7l$...

    > I am confronted with problems of execution on different
    > machines
    > on centos 6 no problem
    > on centos 5 crash
    > Here the trace
    >
    > *** glibc detected *** ./smtp_openssl: free(): corrupted
    > unsorted
    > chunks: 0x08064998 ***
    > *** glibc detected *** ./smtp_openssl: malloc(): memory
    > corruption:
    > 0x080682b0 ***
    > ======= Backtrace: =========
    > /lib/libc.so.6[0x4c899c1d]
    > /lib/libc.so.6(__libc_malloc+0x67)[0x4c89b7d7]
    > /lib/ld-linux.so.2[0x4c81a3dd]

    ....

    Was it executing any particular line in your source code when it crashes?

    How far did it manage to get with the task?

    --
    Bartc
     
    BartC, Jun 5, 2012
    #5
  6. fakessh @

    fakessh @ Guest

    Ike Naar wrote:

    > On 2012-06-05, fakessh @ <> wrote:
    >> this my code
    >>

    https://github.com/fakessh/openprojectssl/blob/master/smtp_openssl.c
    >
    >> buff = malloc(bptr->length);
    >>
    >> #ifdef W32_NATIVE
    >> memset(buff,0,sizeof(char*));
    >> memcpy(buff, bptr->data, bptr->length-1);
    >> #else
    >> bzero(buff, sizeof(char*));
    >> sprintf(buff, "%s", bptr->data);
    >> #endif
    >>
    >> buff[bptr->length-1] = '\0';

    >
    > What is the point of the
    >
    > memset(buff,0,sizeof(char*));
    >
    > or
    >
    > bzero(buff, sizeof(char*));
    >
    > lines? If the size of the buffer "buff" is atleast

    sizeof(char*),
    > the zeroed memory will immediately be overwritten, so the
    > zeroing make no sense. And if the size of the buffer is
    > less than sizeof(char*), the zeroing will write outside
    > the bounds of the buffer.
    >
    > Also, if W32_NATIVE is undefined, the sprintf call
    > will write strlen(bptr->data)+1 characters into buff
    > (that is, the string pointed at by bptr->data, including
    > the terminating null byte).
    > Is it guaranteed that strlen(bptr->data)+1 is atmost
    > bptr->length, so that the sprintf call will not write
    > outside the allocated space for the buffer?
    >
    > And, as mentioned elsethread, you should account for the
    > possibility that malloc returns a null pointer.


    yes indeed it is indeed a problem of null pointer

    although by how simple base64 encoding with the openssl
    library
     
    fakessh @, Jun 6, 2012
    #6
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. rbt

    Python RPM and CentOS

    rbt, May 16, 2005, in forum: Python
    Replies:
    2
    Views:
    386
    Ken Godee
    May 17, 2005
  2. nat
    Replies:
    0
    Views:
    506
  3. CentOS and redhat

    , Jun 22, 2007, in forum: C Programming
    Replies:
    10
    Views:
    656
    Richard Tobin
    Jun 23, 2007
  4. Paul Boddie
    Replies:
    2
    Views:
    477
    Paul Boddie
    Apr 25, 2008
  5. weixiao.fan

    how to upgrade python on centOS 5.2

    weixiao.fan, Jun 28, 2008, in forum: Python
    Replies:
    0
    Views:
    441
    weixiao.fan
    Jun 28, 2008
Loading...

Share This Page