Bug #55336 [Opn->Fbk]: mail() function is not thread safe for Windows builds

From: Date: Sun, 28 Aug 2011 21:29:51 +0000
Subject: Bug #55336 [Opn->Fbk]: mail() function is not thread safe for Windows builds
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-162993@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=55336&edit=1

 ID:                 55336
 Updated by:         pajoye@php.net
 Reported by:        grabli_2005 at mail dot ru
 Summary:            mail() function is not thread safe for Windows
                     builds
-Status:             Open
+Status:             Feedback
 Type:               Bug
 Package:            Network related
 Operating System:   Windows
 PHP Version:        5.4.0alpha2
-Assigned To:        
+Assigned To:        pajoye
 Block user comment: N
 Private report:     N

 New Comment:

Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php
for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php
for Win32

Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.

Would rock if you can provide one.


Previous Comments:
------------------------------------------------------------------------
[2011-08-28 20:16:31] grabli_2005 at mail dot ru

Yep, I`ve got buffer corruption and socket leak under threading.
There no need of TSRM code, socket handle and buffer can be allocated on stack, it`s not so big
(4kb).

------------------------------------------------------------------------
[2011-08-22 14:51:22] kalle@php.net

Have you encountered any issues specific to this finding? I suppose we could make a new globals,
like PW32G for SendMail and stash the variables in there.

------------------------------------------------------------------------
[2011-08-03 18:20:59] grabli_2005 at mail dot ru

switch status to open, see details in previous comment

------------------------------------------------------------------------
[2011-08-01 13:40:27] grabli_2005 at mail dot ru

I`ve provide this patches as reference only, not as product quality code replacement.
The only difference that I note since 5.3.0 is FormatEmailAddress function, that omits <>
around emails.

You can check my statment:
look at /ext/standard/mail.c function php_mail
Here nix path: 	sendmail = popen(sendmail_cmd, "w");
Here win32 path: if (TSendMail(INI_STR("SMTP"), &tsm_err, &tsm_errmsg, hdr,
subject, to, message, NULL, NULL, NULL TSRMLS_CC) == FAILURE) {

TSendMail located in win32\sendmail.c
here global variables:

#ifndef THREAD_SAFE
char Buffer[MAIL_BUFFER_SIZE];

/* socket related data */
SOCKET sc;
#ifndef NETWARE
WSADATA Data;
struct hostent *adr;
int WinsockStarted;
/* values set by the constructor */
char *AppName;
#endif	/* NETWARE */
SOCKADDR_IN sock_in;
char MailHost[HOST_NAME_LEN];
char LocalHost[HOST_NAME_LEN];
#endif

It`s placed under #ifndef THREAD_SAFE, but THREAD_SAFE not defined anywhere even when compile with
ZTS. More often _THREAD_SAFE used around the code.
If you define THREAD_SAFE it`s break sendmail.c compilation, because rest of code uses this
variables without any define switch.

You can simply debug or place debug printf() in TSendMail and see that this code executed and uses
global variables.

win32\time.c have same issue.

------------------------------------------------------------------------
[2011-08-01 12:55:11] pajoye@php.net

Please provide a patch against 5.3 and 5.4.

Also I'm not sure about your statement.

------------------------------------------------------------------------


The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at

    https://bugs.php.net/bug.php?id=55336


-- 
Edit this bug report at https://bugs.php.net/bug.php?id=55336&edit=1


Thread (11 messages)

« previous php.bugs (#162993) next »