Fixed crash in fastcgi due startup order...
SIGG() were being used before tsrm_startup().
2011/6/4 Felipe Pena felipe...@gmail.com
Fixed invalid sigaction() call passing NSIG as signal number.
- for (signo = 1; signo = NSIG; ++signo) {
+ for (signo = 1; signo NSIG; ++signo) {
Detected
Fixed invalid sigaction() call passing NSIG as signal number.
- for (signo = 1; signo = NSIG; ++signo) {
+ for (signo = 1; signo NSIG; ++signo) {
Detected by Valgrind:
==4577== Warning: bad signal number 65 in sigaction()
2011/6/3 Ilia Alshanetsky i...@prohost.org
The crash is now fixed as
The crash is now fixed as well.
On Fri, Jun 3, 2011 at 2:41 AM, Felipe Pena felipe...@gmail.com wrote:
2011/6/2 Felipe Pena felipe...@gmail.com
Hi,
2011/6/2 Michael Maclean mich...@no-surprises.co.uk
On 02/06/11 18:20, Gustavo Lopes wrote:
Em Thu, 02 Jun 2011 18:10:50 +0100, Ilia
hi Ilia,
I would suggest to kill the TSRMLS_FETCH while being at it. They are
horribly slow and a couple of them can be replaced by the
TSRMLS_DC/CC, if I'm not mistaken.
For the windows side, I do not have the time to do the equivalent, so
if you commit the patch to trunk first so I can fix the
On 05/31/2011 03:30 PM, Ilia Alshanetsky wrote:
Since we are on the topic of reviewing past RFCs for 5.4, can we take
another look at the Zend Signals RFC:
https://wiki.php.net/rfc/zendsignals
The patch is solid (have been using it in production for quite some
time) and improvement is quite
Killing TSRMLS_FETCH is a noble goal, but let's keep it to once patch
at a time please ;-) And for the record I am all for killing
TSRMLS_FETCH.
On Thu, Jun 2, 2011 at 6:04 PM, Pierre Joye pierre@gmail.com wrote:
hi Ilia,
I would suggest to kill the TSRMLS_FETCH while being at it. They are
On Thu, Jun 2, 2011 at 7:10 PM, Ilia Alshanetsky i...@prohost.org wrote:
Killing TSRMLS_FETCH is a noble goal, but let's keep it to once patch
at a time please ;-)
I mean in this patch only. This patch adds a couple, so it can be done
at the same time (afair these functions are not used heavily
Em Thu, 02 Jun 2011 18:10:50 +0100, Ilia Alshanetsky i...@prohost.org
escreveu:
Killing TSRMLS_FETCH is a noble goal, but let's keep it to once patch
at a time please ;-) And for the record I am all for killing
TSRMLS_FETCH.
Is there any advantage in killing it as opposed to simply not use
On 02/06/11 18:20, Gustavo Lopes wrote:
Em Thu, 02 Jun 2011 18:10:50 +0100, Ilia Alshanetsky i...@prohost.org
escreveu:
Killing TSRMLS_FETCH is a noble goal, but let's keep it to once patch
at a time please ;-) And for the record I am all for killing
TSRMLS_FETCH.
Is there any advantage in
Hi,
2011/6/2 Michael Maclean mich...@no-surprises.co.uk
On 02/06/11 18:20, Gustavo Lopes wrote:
Em Thu, 02 Jun 2011 18:10:50 +0100, Ilia Alshanetsky i...@prohost.org
escreveu:
Killing TSRMLS_FETCH is a noble goal, but let's keep it to once patch
at a time please ;-) And for the record I
2011/6/2 Felipe Pena felipe...@gmail.com
Hi,
2011/6/2 Michael Maclean mich...@no-surprises.co.uk
On 02/06/11 18:20, Gustavo Lopes wrote:
Em Thu, 02 Jun 2011 18:10:50 +0100, Ilia Alshanetsky i...@prohost.org
escreveu:
Killing TSRMLS_FETCH is a noble goal, but let's keep it to once patch
Since we are on the topic of reviewing past RFCs for 5.4, can we take
another look at the Zend Signals RFC:
https://wiki.php.net/rfc/zendsignals
The patch is solid (have been using it in production for quite some
time) and improvement is quite helpful, especially when APC is being
used. Are
Hi!
The patch is solid (have been using it in production for quite some
time) and improvement is quite helpful, especially when APC is being
used. Are there any reasons not to apply this to 5.4?
I don't know of any. Are there any issues with this change (BC, etc.)?
--
Stanislav Malyshev,
I do not believe so.
On Wed, Jun 1, 2011 at 12:35 AM, Stas Malyshev smalys...@sugarcrm.com wrote:
Hi!
The patch is solid (have been using it in production for quite some
time) and improvement is quite helpful, especially when APC is being
used. Are there any reasons not to apply this to 5.4?
Hi!
I do not believe so.
Then I guess if nobody has any objections we can do it.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 05/31/2011 03:35 PM, Stas Malyshev wrote:
Hi!
The patch is solid (have been using it in production for quite some
time) and improvement is quite helpful, especially when APC is being
used. Are there any reasons not to apply this to 5.4?
I don't know of any. Are there any issues with
How shall we continue with this patch?
Arnaud, I need an updated HEAD patch to match the changes made in 5.3.
There's valid concern about performance in ZTS, which seems hard to address
without the __thread changes. It seems you are working on to get this into
6.0.
Dmitry, Lukas, Arnaud and
On Thursday 14 August 2008 02:59:48 Arnaud Le Blanc wrote:
Hi,
I made some changes to the patch:
http://arnaud.lb.s3.amazonaws.com/php-5.3.0-alarms-0808141122.patch
- Apache effectively seems to resets the signals after MINIT, so original
handlers are now saved in RINIT in the first
Hi Lucas,
I took a look into patch and I still don't like it.
I may miss some things and make mistakes so correct me if I'm wrong.
1) It makes some slowdown for all SAPIs except Apache1, because it adds
additional block/unblock code (mainly in zend_alloc.c)
2) It makes ~10 additional
Dmitry Stogov wrote:
Hi Lucas,
I took a look into patch and I still don't like it.
I may miss some things and make mistakes so correct me if I'm wrong.
1) It makes some slowdown for all SAPIs except Apache1, because it adds
additional block/unblock code (mainly in zend_alloc.c)
This is the
Hi Rasmus,
Rasmus Lerdorf wrote:
Dmitry Stogov wrote:
Hi Lucas,
I took a look into patch and I still don't like it.
I may miss some things and make mistakes so correct me if I'm wrong.
1) It makes some slowdown for all SAPIs except Apache1, because it adds
additional block/unblock code
Dmitry Stogov wrote:
Hi Rasmus,
Rasmus Lerdorf wrote:
Dmitry Stogov wrote:
Hi Lucas,
I took a look into patch and I still don't like it.
I may miss some things and make mistakes so correct me if I'm wrong.
1) It makes some slowdown for all SAPIs except Apache1, because it adds
additional
I wasn't serious about removing them.
Anyway zend_alloc.c and zend_hash.c don't work with shared memory.
It's possible to reuse zend_alloc.c to allocate blocks from SHM, but
it's not its primary purpose. If APC don't do it I don't see how this
block/unblock code may protect SHM. It definitely
On 8/13/08 1:09 AM, Dmitry Stogov [EMAIL PROTECTED] wrote:
I took a look into patch and I still don't like it.
I may miss some things and make mistakes so correct me if I'm wrong.
1) It makes some slowdown for all SAPIs except Apache1, because it adds
additional block/unblock code (mainly in
On 8/13/08 2:10 AM, Dmitry Stogov [EMAIL PROTECTED] wrote:
I wasn't serious about removing them.
Anyway zend_alloc.c and zend_hash.c don't work with shared memory.
It's possible to reuse zend_alloc.c to allocate blocks from SHM, but
it's not its primary purpose. If APC don't do it I don't
now I see the main reason of the patch, but while APC is not a part of
PHP yet, it might be better, easer and safer to solve its issue in APC
itself (this is just a though, not a recommendation).
Anyway we need to make this patch better if we commit it, and I would
ask other community members
Hi,
On Wednesday 13 August 2008 10:09:43 Dmitry Stogov wrote:
Hi Lucas,
I took a look into patch and I still don't like it.
I may miss some things and make mistakes so correct me if I'm wrong.
1) It makes some slowdown for all SAPIs except Apache1, because it adds
additional block/unblock
Hi,
I made some changes to the patch:
http://arnaud.lb.s3.amazonaws.com/php-5.3.0-alarms-0808141122.patch
- Apache effectively seems to resets the signals after MINIT, so original
handlers are now saved in RINIT in the first request of the process.
- Removed some unneeded blocks/unblocks.
-
Arnaud Le Blanc wrote:
- Apache effectively seems to resets the signals after MINIT, so original
handlers are now saved in RINIT in the first request of the process.
Did you verify this behaviour with Apache2 as well? I've only checked
Apache1.
-Rasmus
--
PHP Internals - PHP Runtime
Hi,
On Thursday 14 August 2008 04:19:38 Rasmus Lerdorf wrote:
Arnaud Le Blanc wrote:
- Apache effectively seems to resets the signals after MINIT, so original
handlers are now saved in RINIT in the first request of the process.
Did you verify this behaviour with Apache2 as well? I've only
On 8/11/08 8:52 AM, Dmitry Stogov [EMAIL PROTECTED] wrote:
I'll try to review it on Tuesday/Wednesday.
Thanks. Dmitry.
I've just updated the patches. Only some very minor changes as discussed
before and they should cleanly apply against current cvs.
-lucas
--
PHP Internals - PHP Runtime
On 09.08.2008, at 17:42, Arnaud Le Blanc wrote:
Hi,
As Lucas said the patch seems ready now, could someone please review
the patch
for inclusion ?
http://wiki.php.net/rfc/zendsignals
Changes that have been made:
- The patch has been ported to HEAD
- The patch now supports multithreaded
I'll try to review it on Tuesday/Wednesday.
Thanks. Dmitry.
Lukas Kahwe Smith wrote:
On 09.08.2008, at 17:42, Arnaud Le Blanc wrote:
Hi,
As Lucas said the patch seems ready now, could someone please review
the patch
for inclusion ?
http://wiki.php.net/rfc/zendsignals
Changes that have
Hi,
As Lucas said the patch seems ready now, could someone please review the patch
for inclusion ?
http://wiki.php.net/rfc/zendsignals
Changes that have been made:
- The patch has been ported to HEAD
- The patch now supports multithreaded environments, and fixes many problems
on non-windows
Arnaud Le Blanc wrote:
Hi,
As Lucas said the patch seems ready now, could someone please review the patch
for inclusion ?
http://wiki.php.net/rfc/zendsignals
Changes that have been made:
- The patch has been ported to HEAD
- The patch now supports multithreaded environments, and fixes many
Votre message:
Greetings!
On 8/3/08 9:37 PM, Arnaud LB [EMAIL PROTECTED] wrote:
If sigaction is not available Zend Signal Handling will not be
enabled, so it will not be enabled on Windows (I assume sigaction is
not available on Windows, it is ?).
For pthreads and sigprocmask,
On 8/4/08 11:51 PM, Arnaud Le Blanc [EMAIL PROTECTED] wrote:
global_sigmask is initialized using sigfillset(), so it contains _all_ signals
(except SIGSEGV, etc because non-blockable or not safe to block) and there is
no need to add signals to global_sigmask it in zend_signal() /
On Tuesday 05 August 2008 12:28:19 Lucas Nealan wrote:
On 8/4/08 11:51 PM, Arnaud Le Blanc [EMAIL PROTECTED] wrote:
global_sigmask is initialized using sigfillset(), so it contains _all_
signals (except SIGSEGV, etc because non-blockable or not safe to block)
and there is no need to add
On Tuesday 05 August 2008 08:51:33 Arnaud Le Blanc wrote:
Votre message:
Greetings!
On 8/3/08 9:37 PM, Arnaud LB [EMAIL PROTECTED] wrote:
If sigaction is not available Zend Signal Handling will not be
enabled, so it will not be enabled on Windows (I assume sigaction is
not
On 8/5/08 3:45 AM, Arnaud Le Blanc [EMAIL PROTECTED] wrote:
In the case of pcntl_signal(), if it registers a handler for a signal, the
signal will be delivered to zend_signal_handler_defer(), which will call
zend_signal_handler() if not in critical section, which will call the actual
handler
Greetings!
On 8/3/08 9:37 PM, Arnaud LB [EMAIL PROTECTED] wrote:
If sigaction is not available Zend Signal Handling will not be
enabled, so it will not be enabled on Windows (I assume sigaction is
not available on Windows, it is ?).
For pthreads and sigprocmask, tsrm_sigmask() can be improved
Reviewed to my ability and will soon be posting the updated patch for 5_3
and 6 as well as wiki changes.
On 8/1/08 6:45 PM, Arnaud Le Blanc [EMAIL PROTECTED] wrote:
The ZTS-enabled version of your patch can be found at [1] :)
Changes:
Zend Signal Handling is now enabled in ZTS builds.
Should
hi!
On Sun, Aug 3, 2008 at 9:34 AM, Lucas Nealan [EMAIL PROTECTED] wrote:
Reviewed to my ability and will soon be posting the updated patch for 5_3
and 6 as well as wiki changes.
On 8/1/08 6:45 PM, Arnaud Le Blanc [EMAIL PROTECTED] wrote:
The ZTS-enabled version of your patch can be found at
On 8/3/08 3:00 AM, Pierre Joye [EMAIL PROTECTED] wrote:
We also provide binaries for non ZTS mode, so if the patch is not
ready for Windows, it should disable this feature on Windows.
I was presuming that non-zts, non-cygwin windows will not satisfy the
sigaction requirement, thus we wouldn't
Hi Lucas,
On Sun, Aug 3, 2008 at 11:06 PM, Lucas Nealan [EMAIL PROTECTED] wrote:
On 8/3/08 3:00 AM, Pierre Joye [EMAIL PROTECTED] wrote:
We also provide binaries for non ZTS mode, so if the patch is not
ready for Windows, it should disable this feature on Windows.
I was presuming that
I do not know either, only pointed that we release non ZTS windows
build as well, just in case :)
So user confusion is not an issue here?
Just asking, on account of the amount of user confusion over NTS/ZTS in
php-gtk2 history since that became an option...
- Steph
--
PHP Internals -
On Mon, Aug 4, 2008 at 1:33 AM, Steph Fox [EMAIL PROTECTED] wrote:
I do not know either, only pointed that we release non ZTS windows
build as well, just in case :)
So user confusion is not an issue here?
It is off topic yes. The only point discussed here is whether the
signal handling
On Sun, Aug 3, 2008 at 9:34 AM, Lucas Nealan [EMAIL PROTECTED] wrote:
Reviewed to my ability and will soon be posting the updated patch for 5_3
and 6 as well as wiki changes.
On 8/1/08 6:45 PM, Arnaud Le Blanc [EMAIL PROTECTED] wrote:
The ZTS-enabled version of your patch can be found at [1]
Hi,
On Friday 01 August 2008 05:39:27 Lucas Nealan wrote:
I was initially planning to implement ZTS, however the more I learned the
harder it became. The first issue being that not every scope implementing
the blocking macros has implemented or fetched TSRMLS data. Many places in
zend_alloc.c
Hi!
On 7/31/08 11:07 PM, Arnaud Le Blanc [EMAIL PROTECTED] wrote:
I worked a bit on the ZTS version, this actually fixes many problems with ZTS
on non-windows plateforms :)
[...snip...]
I will send a modified version of your patch tomorrow.
Sounds great, can't wait to see what you've got.
On Friday 01 August 2008 13:27:44 Lucas Nealan wrote:
Hi!
On 7/31/08 11:07 PM, Arnaud Le Blanc [EMAIL PROTECTED] wrote:
I worked a bit on the ZTS version, this actually fixes many problems with
ZTS
on non-windows plateforms :)
[...snip...]
I will send a modified version of your patch
On 8/1/08 6:45 PM, Arnaud Le Blanc [EMAIL PROTECTED] wrote:
Hi,
The ZTS-enabled version of your patch can be found at [1] :)
Thanks Arnaud. I've gone ahead and made the HEAD patch already, wasn't as
bad as I thought it might be. I'll review this hopefully by tomorrow and
then pull into my local
On 7/30/08 6:11 AM, Lukas Kahwe Smith [EMAIL PROTECTED] wrote:
Not so happy that it was not possible to get this committed over the
weekend. Johannes did a quick review and it seems like it has enough
support from people and is low risk enough to get committed now. Lets
hope no extension
On 7/30/08 11:54 AM, Stanisla Malyshev [EMAIL PROTECTED] wrote:
I have a couple of questions about the patch:
1. Why allocate fixed-size buffer via individual malloc's on each
activate and free it on each deactivate? Won't it be better to just
allocate it once and use it?
I'll take a look at
On 30.07.2008, at 01:58, Lucas Nealan wrote:
I've updated the patch for Zend Signal Handling, the latest version is
available on the wiki rfc page:
http://wiki.php.net/rfc/zendsignals
The update solves the reentrance issue with using the a zend linked
list in
the default signal handler.
I'll do quick review in an hour and then I'll probably commit it.
Thanks. Dmitry.
Lukas Kahwe Smith wrote:
On 30.07.2008, at 01:58, Lucas Nealan wrote:
I've updated the patch for Zend Signal Handling, the latest version is
available on the wiki rfc page:
I see several issues with the patch
1) It assumes that web server (and webserver extensions) won't setup any
signal handlers after PHP startup. This assumption may be wrong.
2) It is incompatible with ext/pcntl
3) It breaks 3 tests (in debug mode)
tests/classes/destructor_visibility_001.phpt
-DEV] [RFC] Zend Signal Handling
On Wed, Jul 23, 2008 at 7:54 PM, Stanislav Malyshev [EMAIL PROTECTED]
wrote:
Hi!
Do we really need this option?
Is someone going to disable it and why?
I see only reason to disable it if one has some weird system where
sigaction
is either absent
Dmitry Stogov wrote:
I see several issues with the patch
1) It assumes that web server (and webserver extensions) won't setup any
signal handlers after PHP startup. This assumption may be wrong.
It may be. But there is really no way around that. That's why we
talked about having an
Hi,
On Wednesday 30 July 2008 18:37:26 Dmitry Stogov wrote:
I see several issues with the patch
1) It assumes that web server (and webserver extensions) won't setup any
signal handlers after PHP startup. This assumption may be wrong.
2) It is incompatible with ext/pcntl
If zend_signal()
Arnaud Le Blanc kirjoitti:
Hi,
On Wednesday 30 July 2008 18:37:26 Dmitry Stogov wrote:
I see several issues with the patch
1) It assumes that web server (and webserver extensions) won't setup any
signal handlers after PHP startup. This assumption may be wrong.
2) It is incompatible with
Hi!
I have a couple of questions about the patch:
1. Why allocate fixed-size buffer via individual malloc's on each
activate and free it on each deactivate? Won't it be better to just
allocate it once and use it?
2. Why define own SIG_UNEXPECTED - we already have UNEXPECTED macro in
the
On Wednesday 30 July 2008 20:46:13 Jani Taskinen wrote:
Arnaud Le Blanc kirjoitti:
Hi,
On Wednesday 30 July 2008 18:37:26 Dmitry Stogov wrote:
I see several issues with the patch
1) It assumes that web server (and webserver extensions) won't setup any
signal handlers after PHP
I've updated the patch for Zend Signal Handling, the latest version is
available on the wiki rfc page:
http://wiki.php.net/rfc/zendsignals
The update solves the reentrance issue with using the a zend linked list in
the default signal handler. I've also added a debug only check, at least for
now,
I was waiting after Rasmus said he wanted to compare to the internal
Signals code they have at Yahoo before asking againd about inclusion.
Gopal is familiar with the Yahoo code as well and we're planning to
get together tomorrow and to review and make sure there aren't any
critial oversights
On Wed, Jul 23, 2008 at 7:54 PM, Stanislav Malyshev [EMAIL PROTECTED] wrote:
Hi!
Do we really need this option?
Is someone going to disable it and why?
I see only reason to disable it if one has some weird system where sigaction
is either absent or doesn't work as it should. Not that I know
On 06.07.2008, at 20:56, Lucas Nealan wrote:
Hi Internals,
I am proposing the following RFC to improve signal handling in the
Zend
Engine:
http://wiki.php.net/rfc/zendsignals
The purpose of zend internal deferred signal handling is to improve
the
stability of PHP and extensions when
On 06.07.2008 22:56, Lucas Nealan wrote:
Hi Internals,
I am proposing the following RFC to improve signal handling in the Zend
Engine:
http://wiki.php.net/rfc/zendsignals
The RFC looks really nice, but we need to make a decision on it really fast,
since 5_3 feature freeze is set for
Antony Dovgal wrote:
On 06.07.2008 22:56, Lucas Nealan wrote:
Hi Internals,
I am proposing the following RFC to improve signal handling in the Zend
Engine:
http://wiki.php.net/rfc/zendsignals
The RFC looks really nice, but we need to make a decision on it really
fast, since 5_3 feature
On 23.07.2008 15:42, Scott MacVicar wrote:
http://wiki.php.net/rfc/zendsignals
The RFC looks really nice, but we need to make a decision on it really
fast, since 5_3 feature freeze is set for tomorrow.
I believe this can should go in 5_3, any objections?
Enable it by default and change
Antony Dovgal wrote:
On 23.07.2008 15:42, Scott MacVicar wrote:
http://wiki.php.net/rfc/zendsignals
The RFC looks really nice, but we need to make a decision on it
really fast, since 5_3 feature freeze is set for tomorrow.
I believe this can should go in 5_3, any objections?
Enable it
On 23.07.2008 16:08, Scott MacVicar wrote:
Do we really need this option?
Is someone going to disable it and why?
The defines need to be there for anyone who doesn't have sigaction
available
PHP_CHECK_FUNC(sigaction) in configure.in should be enough for that.
--
Wbr,
Antony Dovgal
--
and not explicit).
Andi
-Original Message-
From: Antony Dovgal [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 23, 2008 5:20 AM
To: Scott MacVicar
Cc: Lucas Nealan; internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC] Zend Signal Handling
On 23.07.2008 16:08, Scott MacVicar wrote:
Do
Hi!
Do we really need this option?
Is someone going to disable it and why?
I see only reason to disable it if one has some weird system where
sigaction is either absent or doesn't work as it should. Not that I know
of any, but Unix variants are full of surprises.
I'd keep it enabled by
I was waiting after Rasmus said he wanted to compare to the internal
Signals code they have at Yahoo before asking againd about inclusion.
Gopal is familiar with the Yahoo code as well and we're planning to
get together tomorrow and to review and make sure there aren't any
critial
Hi Johannes,
thanks for the patch, next to platform specific stuff I'm wondering
whether the shutdown order is right:
[..snip..]
Destructors can be PHP code, as can some ob callback so I think the order
should be changed.
Yes, great catch, the order is incorrect. We use a different order
I like the idea, and I think we don't need --enable-signals options.
BTW I'm not sure about committing it into 5.3. It's a question to RM(s).
Thanks. Dmitry.
Lucas Nealan wrote:
Hi Internals,
I am proposing the following RFC to improve signal handling in the Zend
Engine:
Hi Dmitry,
I like the idea, and I think we don't need --enable-signals options.
I would like to have this enabled by default and this would be very easy to
change. We¹ve been running in production for a few months and we use the
option to make it easier to disable at build time for testing.
Hi!
I am proposing the following RFC to improve signal handling in the Zend
Engine:
http://wiki.php.net/rfc/zendsignals
Looks good. If ti works, I don't think we need two signal models - new
one would be OK. I'm not sure what happens with win32 though.
--
Stanislav Malyshev, Zend Software
Stanislav Malyshev wrote:
Hi!
I am proposing the following RFC to improve signal handling in the Zend
Engine:
http://wiki.php.net/rfc/zendsignals
Looks good. If ti works, I don't think we need two signal models - new
one would be OK. I'm not sure what happens with win32 though.
Note that
Hi Stas,
Looks good. If ti works, I don't think we need two signal models - new
one would be OK. I'm not sure what happens with win32 though.
This has not been tested on windows but it `should` be unaffacted. If built
with ZEND_MAINTAINER_ZTS or if sigaction() is not detected then ZEND_SIGNALS
Hi Internals,
I am proposing the following RFC to improve signal handling in the Zend
Engine:
http://wiki.php.net/rfc/zendsignals
The purpose of zend internal deferred signal handling is to improve the
stability of PHP and extensions when running under any forking SAPI.
Additionally heavy users
82 matches
Mail list logo
