SMTP returns "read function returned funny values" for large attachments.

[mwt Bigpond]

Hi,

I'm using libcurl C library, to build a fairly simple SMTP client to
send emails with any number of attachments. I expect the attachments
to be a reasonable size (less that 2 Mb) and I hold the MIME record
sequence in memory during the mailing process. I could change this if
necessary, and use a temporary file.

I have a read callback function, with CURLOPT_READFUNCTION and READDATA
options set in the email function.

Attaching any number of small files works fine. If I attach a larger
file (I think 16 Kb might be the limit) the program crashes with a Curl
message "read function returned funny values", immediately after the
base64 string containing the attached file has been returned to Curl
through the read callback.

INFILESIZE has been set to the total length of the MIME records. The
read callback returns the correct number of characters for each call,
including the last one that causes the crash.

During the read callback call to memcpy handling the big base64 string,
it seems that an "Invalid write of size 1" occurs, and one end of the
*bufptr or the other (it varies), followed by an "Invalid write of size
4" in curl_easy_perform. These errors do not occur sending smaller
files.

I've looked at BUFFERSIZE, but this appears to apply to write callbacks.
I've looked at transfer.c in libcurl where the message is generated, and
can't see any solution there. Searches on "read buffer size" don't
seem to help either.

Is there something simple that I've overlooked? I'd appreciate your
help.

Regards

Mark.



-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html

[Steve Holme]

Hi Mark,

Post by mwt Bigpond
I'm using libcurl C library, to build a fairly simple SMTP client to
send emails with any number of attachments. I expect the attachments
to be a reasonable size (less that 2 Mb) and I hold the MIME record
sequence in memory during the mailing process. I could change this if
necessary, and use a temporary file.
I have a read callback function, with CURLOPT_READFUNCTION and
READDATA options set in the email function.

This mechanism is good and there shouldn't be any need to use a temporary
file. I've been using libcurl to do this for nearly 2 years now to send
emails with file attachments of varying sizes.

Post by mwt Bigpond
Attaching any number of small files works fine. If I attach a larger
file (I think 16 Kb might be the limit) the program crashes with a Curl
message "read function returned funny values", immediately after
the base64 string containing the attached file has been returned to
Curl through the read callback.
INFILESIZE has been set to the total length of the MIME records. The
read callback returns the correct number of characters for each call,
including the last one that causes the crash.

I don't know of any issues in libcurl and just double checking the code in
transfer.c, to refresh my memory , I would say you are returning a size from
your read function larger than the size * nmemb.

This is typically 1 * BUFSIZE and as such you should only at maximum this
amount of data in each call from libcurl to your callback. Without seeing
your code it feels like you are returning the whole of your MIME buffer at
this point and not chunking it into smaller amounts?

BUFSIZE is defined as CURL_MAX_WRITE_SIZE which in turn is defined as 16384
so that will confirm the 16k theory ;-)

Post by mwt Bigpond
Is there something simple that I've overlooked? I'd appreciate your
help.

Are you able to post your callback function for us to take a look at?

Additionally, what version of libcurl on what platform are you working with?

Kind Regards

Steve

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html