«

hello doctor
hello honorable

I work on a small project in c.
this my code
https://github.com/fakessh/openproje...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

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/openproje...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 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/openproje...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

On 2012-06-05, fakessh @ <> wrote:
> this my code
> https://github.com/fakessh/openproje...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.

"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

Ike Naar wrote:

> On 2012-06-05, fakessh @ <> wrote:
>> this my code
>>
https://github.com/fakessh/openproje...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