Hann, Brian wrote:
> I'm having a problem with a fairly simple handler eating up resources
> and I'm wondering if there's any easy way to track it down.
>
> The handler fetches data from an Oracle database and displays it
> using Template-Toolkit. Nothing fancy, just some display logic, etc.
>
>
>
Brian,
Are you trying to read the entire 8000 records into a
single array/hash? You might try splitting the record
set into pieces and reuse that array/hash.
-- Joe Palladino
"Hann, Brian" wrote:
>
> I'm having a problem with a fairly simple handler
> eating up resources and I'm wondering i
I'm having a problem with a fairly simple handler eating up resources and I'm
wondering if there's any easy way to track it down.
The handler fetches data from an Oracle database and displays it using
Template-Toolkit. Nothing fancy, just some display logic, etc.
The thing is, when I try to
>>>>> "KGM" == Keith G Murphy <[EMAIL PROTECTED]> writes:
KGM> When using a modular mod_perl, I get a huge leak if I preload the 'Pg'
KGM> driver in my startup perl script thus:
Hmmm. Interesting theory. I shall have to investigate it. I also
Juha-Mikko Ahonen wrote:
I looked into it with the following setup:
apache 1.3.26-0woody1
libapache-mod-perl 1.27-2
postgresql 7.2.1-2woody2
There was a Test.pm module handling all requests for /. It opened a
connection to the database and fetched a couple of rows.
With DBI->install_driver('Pg
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> OK, it gets weirder. The following script produces the leak. If I
> comment out the install_driver line, I get a big old segfault! Same
> if I comment out the Apache::DBI line in addition. This works with
> plain apache, or apache-ssl.
>
> #!/usr
[debian-isp readers, to recap, I'm trying to confirm a
memory-leak/segfault problem with Debian stable plus apache(-ssl) plus
libapache-mod-perl. The memory leak happens upon
/etc/init.d/apache(-ssl) reload. You can see my startup script and my
other comments below.]
Juha-Mikko A
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wednesday 16 October 2002 22:52, Keith G. Murphy wrote:
> It's not like it was an obvious problem: I only got the DSO to leak
> when loading the Pg driver. That's pretty obscure.
Have you tried to connect() without loading the Pg driver first? E.
Daniel Jacobowitz wrote:
> On Wed, Oct 16, 2002 at 02:01:33PM -0500, Keith G. Murphy wrote:
>>
>>My own bug report is now 47 days old, without apparent followup.
Hmmm, I probably should not have posted that. Sounds like a major whine.
>
>
> That's because I'm having an attack of real life. I
On Wed, Oct 16, 2002 at 02:01:33PM -0500, Keith G. Murphy wrote:
> Ged Haywood wrote:
> >Hi there,
> >
> >On Wed, 16 Oct 2002, Keith G. Murphy wrote:
> >
> >
> >>do you mean that the problems with the loadable module overall are
> >>so well-known that no one in his right mind should ever use it?
>
Ged Haywood wrote:
> Hi there,
>
> On Wed, 16 Oct 2002, Keith G. Murphy wrote:
>
>
>>>Significant improvements have been made in
>>>the reliability of mod_perl as DSO and nowadays there is much less
>>>discussion about it on this list.
>>
>>Are you sure it's not because 'most everyone has sil
Hi there,
On Wed, 16 Oct 2002, Keith G. Murphy wrote:
> > Significant improvements have been made in
> > the reliability of mod_perl as DSO and nowadays there is much less
> > discussion about it on this list.
>
> Are you sure it's not because 'most everyone has silently given up on it?
Yes,
eith G. Murphy [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, October 16, 2002 2:02 PM
> To: mod_perl Mailing List
> Subject: Re: Memory leak on reload when the 'Pg' driver is preloaded
>
>
> Ged Haywood wrote:
> > Hi there,
> >
> > On Wed, 16 Oct 2002, K
Juha-Mikko Ahonen wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Wednesday 16 October 2002 20:25, Keith G. Murphy wrote:
>
>>By "should", do you mean that the problems with the loadable module
>>overall are so well-known that no one in his right mind should ever
>>use it?
>
>
ent followup.
> If it doesn't seem
> to give you problems then stay with it.
>
> If at first you don't succeed, try again. Then give up.
Actually, that is what I have done already, several months ago. Seeing
several reports of memory leak problems in the list made me think:
"Hmmm, wonder if someone else has seen this?"
Hi there,
On Wed, 16 Oct 2002, Keith G. Murphy wrote:
> do you mean that the problems with the loadable module overall are
> so well-known that no one in his right mind should ever use it?
It's not as bad as that. Significant improvements have been made in
the reliability of mod_perl as DSO an
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wednesday 16 October 2002 20:25, Keith G. Murphy wrote:
> By "should", do you mean that the problems with the loadable module
> overall are so well-known that no one in his right mind should ever
> use it?
Yes. The problems with DSO mod_perl are w
Stathy G. Touloumis wrote:
>
>
>> Using Debian's static-mod_perled apache-perl eliminates the problem.
>
>
> Do you mean you are using the 'so' version that comes with Debian?
Yes, in the case that failed. The package is called 'libapache-mod-perl'.
>
> You
> should be using the static bui
>Using Debian's static-mod_perled apache-perl eliminates the problem.
Do you mean you are using the 'so' version that comes with Debian? You
should be using the static build of apache/mod_perl
Since memory leaks seem to be the topic du jour, I wondered if anyone
else had seen this one:
When using a modular mod_perl, I get a huge leak if I preload the 'Pg'
driver in my startup perl script thus:
#!/usr/bin/perl
use strict;
use Apache::Status ();
use Apache::DBI ();
DBI->install_driver
Hi there,
On Tue, 15 Oct 2002, Davis, Benjamin wrote:
> I'm dealing with a large code base here and I'm hoping to find out what is
> being loaded into memory to make an Apache child jump from 25mb to 145mb
http://perl.apache.org/docs/1.0/guide/debug.html
This kind of thing comes up often on th
I'm dealing with a large code base here and I'm hoping to find out what is
being loaded into memory to make an Apache child jump from 25mb to 145mb
(interestingly it seems to only affect one every now and then rather than
the whole pool) in about 10 seconds. Is there a way to have Apache dump it's
Jack Cushman wrote:
> I am having a problem with very large file uploads (eg 100 MB). While the
> files load, the apache process stays at about 12000 K (the ps VSZ size).
> When the file finishes uploading, the thread suddenly jumps to over
20.
> My guess is that something is loading the whole
Hi --
I am having a problem with very large file uploads (eg 100 MB). While the
files load, the apache process stays at about 12000 K (the ps VSZ size).
When the file finishes uploading, the thread suddenly jumps to over 20.
My guess is that something is loading the whole file into ram, but I
> "DM" == Doug MacEachern <[EMAIL PROTECTED]> writes:
DM> 1.21_01 had two dso fixes, one to close all .so's opened by DynaLoader and
DM> one to call perl_shutdown(), both of which were large leaks. with
DM> 1.25_01-dev and Perl 5.6.1 i see a 4k growth on the first kill -USR1 and
DM> no chang
On Thu, 14 Jun 2001, Paul G. Weiss wrote:
> I know that this is an ongoing problem, but I seem to remember that
> someone somewhere had a patch that reduced the size of the memory leak on
> restarts to a manageable size. Has this patch been applied to the CVS
> version? If not, c
I know that this is an ongoing problem, but I seem to remember that
someone somewhere had a patch that reduced the size of the memory leak on
restarts to a manageable size. Has this patch been applied to the CVS
version? If not, can some kind soul tell me where to find it? I've
looked a
> > script offers database search facilities on the web. If a search is
> > performed which results in many (namely 400) rows being returned, then
> > the httpd child that serves the request grows by 2 MB. Have a child
> > serve that request ten times, and its size will grow from an initial 8
> >
In case anyone is interested: the memory leak I described a week ago
turns out to be a problem of the combination of HTML::Template with
Perl 5.005_03 (probably a bug in Perl 5.005_03 memory management
triggered by HTML::Template). I upgraded to Perl 5.6.1 and now not a
single byte leaks.
My
On Mon, 28 May 2001, Matthias Hanns wrote:
> Hi,
>
> I had the same prob and lowering maxrequestsperchild helped.
>
> Are there possibilities to clean up the used mem on end of the
> mod_perl-script manually? Or have I always set maxrequestsperchild to lower
> values? If it?s possible to do it by
apache-thread in opposite of it in the manual clean-up?
Matthias
-Ursprungliche Nachricht-
Von: Ged Haywood [mailto:[EMAIL PROTECTED]]
Gesendet: Montag, 28. Mai 2001 20:08
An: Antonios Christofides
Cc: [EMAIL PROTECTED]
Betreff: Re: Memory leak
Hi there,
On Mon, 28 May 2001, Antonios
Hi there,
On Mon, 28 May 2001, Antonios Christofides wrote:
> script offers database search facilities on the web. If a search is
> performed which results in many (namely 400) rows being returned, then
> the httpd child that serves the request grows by 2 MB. Have a child
> serve that request te
Hi all. I have a huge memory leak with mod_perl.
I'm using a RedHat 6.2 Linux 2.2.14 system with Perl 5.00503, Apache
1.3.14, and mod_perl 1.23. Both Apache and mod_perl come from RedHat's
packages, and mod_perl runs as DSO.
My script uses CGI, DBI, Apache::DBI, and HTML::Template. No
Hi Mark.
On Thu, 1 Feb 2001, Mark Blythe wrote:
> I have been testing and troubleshooting this for days, and I can find no
> other answer to my problem except that DBD::mysql has a memory leak.
>
> I have narrowed it down to this small script running through
> A
I have been testing and troubleshooting this for days, and I can find no
other answer to my problem except that DBD::mysql has a memory leak.
I have narrowed it down to this small script running through
Apache::Registry:
use DBI;
use
On Fri, 8 Dec 2000, Perrin Harkins wrote:
> Unfortunately, GTop is kind of a pain to compile. It seems to depend on
> some Gnome stuff. We use Apache::SizeLimit for this reason, and it works
> well.
there's a configure --disable-gnome switch for libgtop. can still be a
pain though.
nd spend a few weeks grubbing through the
code. yechh.
-harshy
> From: Son Chang [mailto:[EMAIL PROTECTED]]
>
> I saw this fix in one of the mailing list archives and tried
> it but I'm still
> getting the memory leak.
>
> -son
>
> Quoting Harshy Wanigasekara
I saw this fix in one of the mailing list archives and tried it but I'm still
getting the memory leak.
-son
Quoting Harshy Wanigasekara <[EMAIL PROTECTED]>:
> Son Chang wrote:
> >Hi,
> >
> >I'm experiencing a memory leak with Apache 1.3.14 with mod_pe
Son Chang wrote:
>Hi,
>
>I'm experiencing a memory leak with Apache 1.3.14 with mod_perl 1.23 and
>perl5.6.0 on Windows NT4.0 and Windows2000.
>I've been running some test with a very simple ModPerl handler which just
>outputs an HTML page with hello world in it. Als
I've had memory leak issues on Linux [so I don't know how appropriate this advise is
for Windows], and the fix that worked the best for others & myself was to actually
kill the apache server & restart it. The process takes seconds, and can be automated &
scheduled for of
Hi,
I'm experiencing a memory leak with Apache 1.3.14 with mod_perl 1.23 and
perl5.6.0 on Windows NT4.0 and Windows2000.
I've been running some test with a very simple ModPerl handler which just
outputs an HTML page with hello world in it. Also, I made sure to undef all
variables that
possible to undef $a and reuse its memory (1M),
> but the right part memory (one more 1M) can be used nowhere except the
> same line of code.
>
> This is strange. I understand that it can be an optimization trick,
> but when you frequently operate with megabytes, this becomes a
> pl
it seems as if most (if not all) the techniques for checking the size of
the current process are _very_ platform specific. on linux you can use
Apache::SizeLimit::linux_size_check
which is just parsing /proc/self/status.
- mark
Stas Bekman wrote:
> On Thu, 7 Dec 2000 [EMAIL PROTECTED] wr
right part memory (one more 1M) can be used nowhere except the
same line of code.
This is strange. I understand that it can be an optimization trick,
but when you frequently operate with megabytes, this becomes a
pleasant feature which looks and behaves like a memory leak :)
Ivan
> > Th
On Fri, 8 Dec 2000, Stas Bekman wrote:
> If you have linux you have (or can have GTop), which gives you an API to
> do this and many other things. Apache::SizeLimit::linux_size_check is just
> a custom function that you cannot really re-use (unless you put it into
> some other module...
Unfortuna
On Fri, 8 Dec 2000, mark warren bracher wrote:
> it seems as if most (if not all) the techniques for checking the size of
> the current process are _very_ platform specific. on linux you can use
>
>Apache::SizeLimit::linux_size_check
If you have linux you have (or can have GTop), which gi
You probably tried this script on linux or some other not fully BSD
compartible system. We obtained same zeros on linux, where getrusage()
means something else than on FreeBSD,
but if you try measuring memory sizes with ps or top, you should
observe the mentioned leak. Please insert sleep(10)
On Thu, 7 Dec 2000 [EMAIL PROTECTED] wrote:
>
> The output I get is
>
> used memory = 0
> used memory = 0
> used memory = 0
> used memory = 0
> used memory = 0
I get the same under perl 5.6.0 on linux, looks like BSD::Resource doesn't
work there :( Anyone?
Use gtop instead (if you have it):
Hi Ivan,
It's not really mod_perl, but is relevant to people on the list I guess...
If you really play aorund with this, you'll find some interesting variations.
If I assign $cc using a for loop
my $c;
for ( 1..2000) { $cc .= 'a'; }
it's a lot slower, but only uses
On Thu, 7 Dec 2000, Ivan E. Panchenko wrote:
> Today I discovered a strange behaiviour of perl,
> and I wonder if anybody can tell me what to do with it.
>
> The matter is that perl DOES NOT REUSE MEMORY allocated for
> intermediate calculation results. This is specially harmful to
> data-inten
On Thu, 7 Dec 2000, Ivan E. Panchenko wrote:
>
>
> Today I discovered a strange behaiviour of perl,
> and I wonder if anybody can tell me what to do with it.
>
> The matter is that perl DOES NOT REUSE MEMORY allocated for
> intermediate calculation results. This is specially harmful to
> dat
The output I get is
used memory = 0
used memory = 0
used memory = 0
used memory = 0
used memory = 0
I'm interested in how many leaks are possible in mod_perl
though because my mod_perl processes are getting bigger
with time -- about 200 requests is making the process
fatter by 1mb on the aver
Today I discovered a strange behaiviour of perl,
and I wonder if anybody can tell me what to do with it.
The matter is that perl DOES NOT REUSE MEMORY allocated for
intermediate calculation results. This is specially harmful to
data-intensive modperl applications where one perl process proces
Hi again,
We managed to fix the problem described
below. The issue was the win32
porting code in perl. In the file
perl-5.6.0/win32/win32.h
commenting out the line:
#define ENV_IS_CASELESS
fixes the memory leak problem.
-harshy
> -Original Message-
> From: Harshy Waniga
Hi All,
I've looked through the maillist archives,
and FAQs and guides and docs, with no help.
I've got a memory leak problem running embedded
perl under Apache on Windows NT. I've reduced
the problem set as much as I can, to the
following Apache::Registry script:
---
Jim Turner wrote:
>
> Greetings,
>
> I am using Apache 1.3.9 on Linux kernel 2.0.36 using
> ApacheASP wrapped around my CGI scripts. I have the following
> test script which works fine unless I declare the array variable
> "v" as "my @v". This causes massive memory consumption in that
Greetings,
I am using Apache 1.3.9 on Linux kernel 2.0.36 using
ApacheASP wrapped around my CGI scripts. I have the following
test script which works fine unless I declare the array variable
"v" as "my @v". This causes massive memory consumption in that
much more memory is allocated
> -Original Message-
> From: Doug MacEachern [mailto:[EMAIL PROTECTED]]
> Sent: Monday, September 11, 2000 2:54 PM
> To: Matt Sergeant
> Cc: [EMAIL PROTECTED]
> Subject: Re: Memory leak hell...
>
>
[snip]
> look for xsubs in those modules you're using
On Sun, 10 Sep 2000, Matt Sergeant wrote:
> For 2 days solid now I've been trying to track down a very bizarre memory
> leak in AxKit.
>
> I've checked everything I can think of - all circular references are now
> gone, all closures clean up carefully after themselve
On Mon, 11 Sep 2000, Stas Bekman wrote:
> On Mon, 11 Sep 2000, Matt Sergeant wrote:
>
> > On Mon, 11 Sep 2000, Stas Bekman wrote:
> >
> > > I was thinking about going thru the symbol table and dumping all the
> > > variables. And run diff between the dumps of the two requests. Be careful
> > >
On Mon, 11 Sep 2000, Matt Sergeant wrote:
> On Mon, 11 Sep 2000, Stas Bekman wrote:
>
> > I was thinking about going thru the symbol table and dumping all the
> > variables. And run diff between the dumps of the two requests. Be careful
> > though that Devel::Peek doesn't show a complete dump fo
On Mon, 11 Sep 2000, Stas Bekman wrote:
> I was thinking about going thru the symbol table and dumping all the
> variables. And run diff between the dumps of the two requests. Be careful
> though that Devel::Peek doesn't show a complete dump for the whole
> structure, and I couldn't find the inte
On Sun, 10 Sep 2000, Matt Sergeant wrote:
> On Sun, 10 Sep 2000, Stas Bekman wrote:
>
> > On Sun, 10 Sep 2000, Matt Sergeant wrote:
> >
> > > For 2 days solid now I've been trying to track down a very bizarre memory
> > > leak in AxKit.
> > >
On Sun, 10 Sep 2000, Stas Bekman wrote:
> On Sun, 10 Sep 2000, Matt Sergeant wrote:
>
> > For 2 days solid now I've been trying to track down a very bizarre memory
> > leak in AxKit.
> >
> > I've checked everything I can think of - all circular referen
Matt Sergeant <[EMAIL PROTECTED]> writes:
> Now to the wierd bit. I could track this down if it wasn't for this:
>
> The memory leak starts after the Nth hit, usually around 35. This is
> running under httpd -X.
>
> So it goes along very happily for 35 hits - memory
Matt Sergeant wrote:
> Can anyone give me _any_ help in figuring out where this might be coming
> from?
When I'm working on problems like this, there are two basic things I
try. They're not rocket science, but they usually work. The first is
removing sections of code until the leak goes away.
On Sun, 10 Sep 2000, Matt Sergeant wrote:
> For 2 days solid now I've been trying to track down a very bizarre memory
> leak in AxKit.
>
> I've checked everything I can think of - all circular references are now
> gone, all closures clean up carefully after themselve
For 2 days solid now I've been trying to track down a very bizarre memory
leak in AxKit.
I've checked everything I can think of - all circular references are now
gone, all closures clean up carefully after themselves, and I've reduced
the usage of some external modules. But stil
On Tue, 15 Aug 2000, vegan.star wrote:
> I have some mod_perl modules. I suspect that it has a memory
> leak. I'm running that in a Sun Solaris 2.6 machine with apache
> 1.3.9. I read that exists Apache::Leak to test for leaks.
> How it works?
> I have some packages
I have some mod_perl modules. I suspect that it has a memory
leak. I'm running that in a Sun Solaris 2.6 machine with apache
1.3.9. I read that exists Apache::Leak to test for leaks.
How it works?
I have some packages and I put into them like this:
package package_name;
use Apache:
On Thu, 15 Jun 2000, gc wrote:
> I'm having a memory leak problem that I suspect comes from a mod_perl
> module of mine. The module talks to a MySQL database using DBI.
>
> I can't see any memory hogs when I check the linux box with 'top',
> but after s
I'm having a memory leak problem that I suspect comes from a mod_perl
module of mine. The module talks to a MySQL database using DBI.
I can't see any memory hogs when I check the linux box with 'top',
but after several days the computer inevitably grinds to a halt.
This
Of course, the short term fix, is to lower MaxRequestsPerChild which
will hopefully reduce the leakage but won't help performance.
Leaks in DBD::Oracle and Oracle's own libraries are not entirely rare.
You should send your simple, stand-alone example to the dbi-user's
mailing list with your exac
Has anyone else come across a problem using DBD::Oracle, where
connect() leaks approximately 80k every time it is used (which, in my
case, is with every request child processes handle)? It's negligable with
regular perl scripts, but I've seen child sizes grow to 40 megs before I
killed them all.
Hi all,
In my error_log, a few lines of
[Wed Apr 19 18:45:10 2000] null: Attempt to free unreferenced scalar.
generated during server restart and shutdown.
Is this a known potential memory leak documented anywhere?
I'm running Apache-1.3.12/Perl-5.6.0/mod_perl-1.22
mod_* is com
Doug MacEachern wrote:
> On Fri, 7 Apr 2000, Nikki Chumakov wrote:
>
> > mod_perl probaly have memory leakage during rereading configs (e.g. on
> > the apachectl graceful)
>
> do you have PerlFreshRestart On? if so, try turning it off. i think dso
> leaks on restart too, try linking static if t
On Fri, 7 Apr 2000, Nikki Chumakov wrote:
> mod_perl probaly have memory leakage during rereading configs (e.g. on
> the apachectl graceful)
do you have PerlFreshRestart On? if so, try turning it off. i think dso
leaks on restart too, try linking static if that's the problem. a static
httpd t
I have run into the same issue also both with mod_perl as a DSO module or
compiled staticly. I have tested it using apache-1.3.6 and apache-1.3.12
w/ mod_perl-1.22 and mod_perl-1.21. The memory growth also occurs if I
HUP the server rather than sending USR1. Since the problem only occurs if
mod
mod_perl probaly have memory leakage during rereading configs (e.g. on
the apachectl graceful)
My system:
RH 6.1,
linux-2.2.15pre17
glibc-2.1
apache-1.3.12
mod_ssl-2.6.2
russian patches (ftp.lexa.ru/pub/apache-rus/) PL29.4
mm-1.0.12
mod_perl-1.22
With mod_perl module enabled in httpd.conf ever
c, and use a lot of CGI and
> MySQL 3.22.25 is used with Apache::DBI.
>
> The major problem seems to be a memory leak of some sort, identical to that
> described in the "memory leak in mod_perl" thread on this list from October
> 1997 and the "httpd, mod_perl and memory con
se a lot of CGI and
> > MySQL 3.22.25 is used with Apache::DBI.
> >
> > The major problem seems to be a memory leak of some sort, identical to
that
> > described in the "memory leak in mod_perl" thread on this list from
October
> > 1997 and the "httpd, mo
> Why, reinvent the wheel? I wrote Apache::VMonitor (grab from CPAN) that
> does all this and more (all but tail -f) I use it all the time, saves me a
> lot of time, since I don't have to telnet!
Ok - I will try to look into that when I get time.
> > 2) Open up and hack Apache::SizeLimit and ha
On Sun, 9 Jan 2000, Sean Chittenden wrote:
> Yeah... two things I'd do:
>
> 1) Open two telnet sessions to the box. One for top that is
> monitoring processes for your web user (www typically) and is sorting by
> memory usage w/ a 1 second refresh. I'd change the size of the wind
n Chittenden <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED]
> Subject: Re: Memory leak/server crashes
>
> > Try using Apache::SizeLimit as a way of controlling your
> > processes. Sounds like a recursive page that performs infinite internal
> > requests.
>
> Ok,
hich are
> fairly high traffic, and use a lot of CGI and
> MySQL 3.22.25 is used with Apache::DBI.
>
> The major problem seems to be a memory leak of some sort, identical to that
> described in the "memory leak in mod_perl" thread on this list from October
> 1997 and the &
> Try using Apache::SizeLimit as a way of controlling your
> processes. Sounds like a recursive page that performs infinite internal
> requests.
Ok, sounds like a good solution, but it still seems to me I should be
eliminating the problem at the source. Any ideas as to how I could narrow
down th
t; Date: Sun, 9 Jan 2000 19:58:00 -
> From: James Furness <[EMAIL PROTECTED]>
> Reply-To: James Furness <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: Memory leak/server crashes
>
> I'm looking for some help getting apache to run reliably. Apache 1.3.9 wit
with Apache::DBI.
The major problem seems to be a memory leak of some sort, identical to that
described in the "memory leak in mod_perl" thread on this list from October
1997 and the "httpd, mod_perl and memory consumption (long)" thread from
July 1997.
The server runs normall
88 matches
Mail list logo