Ignore memory leaks reported for some libc-client functions

[cmb69]

At least on Windows, some static variables are lazily initialized
during mail_open() and mail_lsub(), which are reported as memory
leaks. We suppress these false positives.

[cmb69]

BTW, is it sufficient to document that ext/imap is not thread-safe?

[Girgias]

BTW, is it sufficient to document that ext/imap is not thread-safe?

Isn't this how other extensions deal with it? Or do they fail during configuration is the build is a ZTS build?

[cmb69]

Isn't this how other extensions deal with it? Or do they fail during configuration is the build is a ZTS build?

Well, I think that most extensions are thread-safe. If there is no better solution, you can always deploy synchronization primitives to enforce thread-safety. I doubt that it's worth to bother with this regarding libc-client, though.

[Girgias]

Isn't this how other extensions deal with it? Or do they fail during configuration is the build is a ZTS build?

Well, I think that most extensions are thread-safe. If there is no better solution, you can always deploy synchronization primitives to enforce thread-safety. I doubt that it's worth to bother with this regarding libc-client, though.

Yeah I agree, we probably should attempt to get IMAP out of php-src as it's kinda on life-support from what I see. :-/

[cmb69]

See https://bugs.php.net/bug.php?id=78572.

[nikic]

We do seem to have at least one extension that checks for ZTS in config.m4:

php-src/ext/session/config.m4

Lines 34 to 37 in 12f33a3

	if test "$enable_zts" = "yes"; then
	dnl The mm library is not thread-safe, and mod_mm.c refuses to compile.
	AC_MSG_ERROR(--with-mm cannot be combined with --enable-zts)
	fi

[cmb69]

We do seem to have at least one extension that checks for ZTS in config.m4

Not sure if we should stop shipping ext/imap for ZTS on Windows in stable releases. I'll ask PHPonWindows team.

[nikic]

@cmb69 Do you have any further info on the thread-safety issues? Were there any bugs reported with regard to that?

[cmb69]

I'm not aware of any reported bugs in this regard, but libc-client has a lot of global state which appear to be read and written without any guards, and apparently there is no init() called in MINIT. The docs (doc/internal.txt) only mention:

Any multi-threaded application should test stream->lock prior to calling any c-client stream functions. Any attempt to call a mail_xxx() function while one is already in progress on the same stream will cause the application to fail in unpredictable ways.

Note that this check is insufficient in a preemptive-scheduling multi-tasking application due to the possibility of a timing race. Such applications must be written so that only one process accesses the stream, or to have a higher level lock.

Since MAIL operations will not finish until they are completed, a single-tasking application does not have to worry about this problem, except in the callback invoked from MAIL (e.g. mm_exists(), etc.) in which case the stream is always locked.

AIUI, that shouldn't be an issue, since the streams are not shared.

However, the lazily initialized functions statics (which have been reported as mem-leaks) could likely cause issues (excerpt from c-client/ip_nt.c):

  static struct addrinfo *hints;
  if (!hints) {			/* hints set up yet? */
    hints = (struct addrinfo *) /* one-time setup */
      memset (fs_get (sizeof (struct addrinfo)),0,sizeof (struct addrinfo));
				/* allow any address family */
    hints->ai_family = AF_UNSPEC;
    hints->ai_socktype = SOCK_STREAM;
				/* need canonical name */
    hints->ai_flags = AI_CANONNAME;
  }