Rt-mailgate exiting with status 11

Hi,

I’ve got issues with RT’s mail gateway occasionally going into a death
spiral with messages (generally seems to be ones with attachments). I’ve
done some googling on the problem, however didn’t find a definitive
answer.

I’m running the Debian packaged version 2.0.14-1 against a remote (Debian)
PostgreSQL (7.2.1-2woody2) server. Locally on the RT box I have libpgsql2
7.2.1-2woody2 installed and libdbd-pg-perl 1.22-1 installed.

I’m planning on upgrading it all to a 7.3 version of PostgreSQL, but would
like to avoid the heartache if I can and it’s something else simple.

regards

Andrew

Andrew Pollock wrote:

Subject: [rt-users] rt-mailgate exiting with status 11

status 11, or signal 11?

There should be no way that rt-mailgate can exit with status
11. However, if it’s signal 11 instead, you might have bad
hardware; see the Sig11 FAQ at The SIG11 problem
for possible enlightenment.
�|� Request Tracker... So much more than a help desk — Best Practical Solutions – Trouble Ticketing. Free.

Andrew Pollock wrote:

Subject: [rt-users] rt-mailgate exiting with status 11

status 11, or signal 11?

There should be no way that rt-mailgate can exit with status
11. However, if it’s signal 11 instead, you might have bad
hardware; see the Sig11 FAQ at The SIG11 problem
for possible enlightenment.

“mailer prog died with signal 11”

So for some reason mail with attachments is causing the rt-mailgate to seg
fault.

How can I best debug this further to determine what it’s doing at the
point it segfaults? Being a Perl script, running strace over it when
sendmail tries to run the queue results in a lot of output, partly
sendmail, a lot of Perl initialisation…

Andrew

Hi,

I’ve got issues with RT’s mail gateway occasionally going into a death
spiral with messages (generally seems to be ones with attachments). I’ve
done some googling on the problem, however didn’t find a definitive
answer.

I’m running the Debian packaged version 2.0.14-1 against a remote (Debian)
PostgreSQL (7.2.1-2woody2) server. Locally on the RT box I have libpgsql2
7.2.1-2woody2 installed and libdbd-pg-perl 1.22-1 installed.

I’m planning on upgrading it all to a 7.3 version of PostgreSQL, but would
like to avoid the heartache if I can and it’s something else simple.

I’ve done some debugging on this and gotten to the point where I don’t
understand the internals of RT enough to continue.

rt-mailgate is segfaulting inside RT::Attachment::Create

I’ve done some debugging on this and gotten to the point where I don’t
understand the internals of RT enough to continue.

rt-mailgate is segfaulting inside RT::Attachment::Create

From what I can determine, this gets called for each part of a multi-part
MIME message.

I’m testing it with a message that contains a PDF attachment. I’m not sure
about the structure of a multi-part MIME message, but if I look at the
file, I see the boundary appear once at the start of the message, once at
the start of the attachment and once at the end.

From the debugging code I’ve inserted, I’m seeing RT::Attachment::Create
called three times, and it’s within the third call, where it appears about
to call RT::Attachment::Create for a fourth time, that it seems to be
segfaulting.

Should it be being called this many times? Has it lost the plot about how
many parts there are in the message, and is why it’s segfaulting?

Furthermore, I just figured out how all that SUPER stuff works, and it
appears to be inside DBIx::SearchBuilder::Record::Cachable (or something
along those lines) that’s falling over. Sheesh, this is a voyage of
discovery…

Andrew

I’ve done some debugging on this and gotten to the point where I don’t
understand the internals of RT enough to continue.

Its easy. Simply invite the author of RT for dinner, slurp out his brain,
and you’re done. Best to put one back in or otherwise he might notice.

From the debugging code I’ve inserted, I’m seeing RT::Attachment::Create
called three times, and it’s within the third call, where it appears about
to call RT::Attachment::Create for a fourth time, that it seems to be
segfaulting.

Furthermore, I just figured out how all that SUPER stuff works, and it
appears to be inside DBIx::SearchBuilder::Record::Cachable (or something
along those lines) that’s falling over. Sheesh, this is a voyage of
discovery…

Before scrounging around in DBIx::SB, you probably want to see the size of
the attachment that its about to create (and whether all arguments to
Create are defined etc) to see if you’re running into, say, packet size
problems with MySQL.

You might also want to inspect the MySQL query log, and see how much of
the query is getting there (ie, segfault before or after it invokes the
update?).

                         Bruce Campbell                            RIPE
               Systems/Network Engineer                             NCC
             www.ripe.net - PGP562C8B1B             Operations/Security