headers
MJ Ray | 5 Jan 2007 15:32
Gravatar

Seg fault on d * if 1 is last message

Pretty much as the subject line says: if I have a smallish mailbox and
1 is the last message in a sorted header display (shown in reply to the
h command) and I ask it to "d *" then it throws me out with a segmentation
fault.  I read mail over IMAP and autosort on subject, if that matters.

Has anyone else seen this bug or can try to reproduce it?

Thanks,
--

-- 
MJ Ray - see/vidu http://mjr.towers.org.uk/email.html
Somerset, England. Work/Laborejo: http://www.ttllp.co.uk/
IRC/Jabber/SIP: on request/peteble.

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Permalink | Reply | 5 comments |
headers
Gunnar Ritter | 5 Jan 2007 15:44
Picon
Favicon

Re: Seg fault on d * if 1 is last message

MJ Ray <mjr@...> wrote:

> Pretty much as the subject line says: if I have a smallish mailbox and
> 1 is the last message in a sorted header display (shown in reply to the
> h command) and I ask it to "d *" then it throws me out with a segmentation
> fault.  I read mail over IMAP and autosort on subject, if that matters.
>
> Has anyone else seen this bug or can try to reproduce it?

Can you give a sequence of commands to create the mailbox
and to reproduce the problem?

	Gunnar

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Permalink | Reply | 4 comments |
headers
MJ Ray | 5 Jan 2007 17:58
Gravatar

Re: Seg fault on d * if 1 is last message

Gunnar Ritter <gunnarr@...> wrote:
> Can you give a sequence of commands to create the mailbox
> and to reproduce the problem?

cd /tmp
wget http://mjr.towers.org.uk/comp/hmxsegv.gz
gunzip hmxsegv.gz
mailx # with autosort=subject for sure and probably with % on IMAP
d *
fi %
fi /tmp/hmxsegv
h
    [listing showing 1 as the last mail]
d *
    [segmentation violation]

I can copy the hmxsegv messages to an empty IMAP % and it will segv
when I d * them there, too.  I hit this bug more often on small
mailboxes, as there's a higher probability of 1 being the last
message - a good-if-painful way to stop me checking my mail too
often, although I don't think I've had it happen with a 1-message
mailbox yet.

Last few lines of a strace:

read(14, "sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp"..., 4096) = 4096
read(14, " text/plain;\n\tcharset=\"iso-8859-"..., 4096) = 3511
write(1, " O  2 unknownatt Rudy wrote:\n", 29) = 29
_llseek(14, 0, [0], SEEK_SET)           = 0
read(14, "From agnes@..."..., 4096) = 4096
(Continue reading)

Permalink | Reply | 3 comments |
headers
David Ronis | 5 Jan 2007 20:47
Picon

Strange mime problem

Hi I'm running on a Linux box, and have mailx-21.1 installed.  I have an
application that sends out e-mail reports to a list as PDF attachments
(with an empty body).  Basically, I use the command

system("mailx -r my_secretary -s "report..." -a report.pdf recipient");

within a cgi-script run by httpd.   I've been using this program for a
couple of years, but recently I've had complaints from recipients on our
exchange server: the PDF file is broken. Specifically, it looks as if
exchange has replaced unix \n's by DOS \r\n (and indeed, if I convert
them back, the PDF is viewable.  Recipients on Unix boxes are fine.

In all cases, the mail goes through several virus scanners before
getting delivered.

The problem seems to be with the mime encoding somewhere--the broken
files end up with quoted-printable and our exchange IT guys say that
that makes it "fair-game" for this kind of rewriting.

Their suggestion was to simply "tell your mailer to used base64".  I
tried adding the line:

set encoding=8bit 

to /etc/nail.rc, but it made absolutely no difference.  

What I find strange is that that I'm currently running a separate system
call for each recipient, other than their e-mail address, everything
else is the same for each call.  Shouldn't mailx generate the same mail?
[It goes to sendmail on the same machine, and then to our university's
(Continue reading)

Permalink | Reply | 3 comments |
headers
Gunnar Ritter | 6 Jan 2007 14:33
Picon
Favicon

Re: Seg fault on d * if 1 is last message

MJ Ray <mjr@...> wrote:

> Gunnar Ritter <gunnarr@...> wrote:
> > Can you give a sequence of commands to create the mailbox
> > and to reproduce the problem?
>
> cd /tmp
> wget http://mjr.towers.org.uk/comp/hmxsegv.gz
> gunzip hmxsegv.gz
> mailx # with autosort=subject for sure and probably with % on IMAP
> d *
> fi %
> fi /tmp/hmxsegv
> h
>     [listing showing 1 as the last mail]
> d *
>     [segmentation violation]

I am sorry but I am still not able to reproduce it; it just
works as it should here. Which system are you using?

	Gunnar

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Permalink | Reply | 2 comments |
headers
Gunnar Ritter | 6 Jan 2007 16:03
Picon
Favicon

Re: Strange mime problem

David Ronis <ronis@...> wrote:

> Hi I'm running on a Linux box, and have mailx-21.1 installed.  I have an
> application that sends out e-mail reports to a list as PDF attachments
> (with an empty body).  Basically, I use the command
>
> system("mailx -r my_secretary -s "report..." -a report.pdf recipient");
>
> within a cgi-script run by httpd.   I've been using this program for a
> couple of years, but recently I've had complaints from recipients on our
> exchange server: the PDF file is broken. Specifically, it looks as if
> exchange has replaced unix \n's by DOS \r\n (and indeed, if I convert
> them back, the PDF is viewable.  Recipients on Unix boxes are fine.
>
> In all cases, the mail goes through several virus scanners before
> getting delivered.
>
> The problem seems to be with the mime encoding somewhere--the broken
> files end up with quoted-printable and our exchange IT guys say that
> that makes it "fair-game" for this kind of rewriting.
>
> Their suggestion was to simply "tell your mailer to used base64".

Looking at this issue again, I must confess that I was wrong
when it was last discussed on this list in 2005. It is indeed
mailx which applies a wrong encoding here since if the message
part is not of type "text/", it could only insert a hard line
break in quoted-printable if it finds \r\n in its input. But
what it does is inserting a hard line break for \n as with
type "text/" message parts.
(Continue reading)

Permalink | Reply | 2 comments |
headers
David Ronis | 7 Jan 2007 00:29
Picon

Re: Strange mime problem

I've downloaded the CVS sources and installed.  The problem seems to be
fixed.  Thanks

David

On Sat, 2007-01-06 at 16:03 +0100, Gunnar Ritter wrote:
> David Ronis <ronis@...> wrote:
> 
> > Hi I'm running on a Linux box, and have mailx-21.1 installed.  I have an
> > application that sends out e-mail reports to a list as PDF attachments
> > (with an empty body).  Basically, I use the command
> >
> > system("mailx -r my_secretary -s "report..." -a report.pdf recipient");
> >
> > within a cgi-script run by httpd.   I've been using this program for a
> > couple of years, but recently I've had complaints from recipients on our
> > exchange server: the PDF file is broken. Specifically, it looks as if
> > exchange has replaced unix \n's by DOS \r\n (and indeed, if I convert
> > them back, the PDF is viewable.  Recipients on Unix boxes are fine.
> >
> > In all cases, the mail goes through several virus scanners before
> > getting delivered.
> >
> > The problem seems to be with the mime encoding somewhere--the broken
> > files end up with quoted-printable and our exchange IT guys say that
> > that makes it "fair-game" for this kind of rewriting.
> >
> > Their suggestion was to simply "tell your mailer to used base64".
> 
> Looking at this issue again, I must confess that I was wrong
(Continue reading)

Permalink | Reply | 0 comments |
headers
Gunnar Ritter | 7 Jan 2007 17:18
Picon
Favicon

Re: Seg fault on d * if 1 is last message

Gunnar Ritter <gunnarr@...> wrote:

> MJ Ray <mjr@...> wrote:
> > d *
> >     [segmentation violation]
>
> I am sorry but I am still not able to reproduce it; it just
> works as it should here. Which system are you using?

Fine - valgrind found the error. A fix is available in the CVS
repository. Note that it may take up to an hour from now until
it is publicly available due to SourceForge limitations.

	Gunnar

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Permalink | Reply | 1 comment |
headers
Gunnar Ritter | 7 Jan 2007 17:32
Picon
Favicon

mailx 12.2 released

Hi,

Heirloom mailx 12.2 has been released and is available from
<http://heirloom.sourceforge.net/mailx.html> as usual.

	Gunnar

[12.2] released 1/7/07
* When a MIME message part is not of the "text/" content type, always
  send it in base64 to avoid issues with CRLF conversion (David Ronis).
* Character set conversion is now also applied to attachments if they
  have the "text/" content type. This is necessary because with the
  "sendcharsets" variable, the character set declaration that becomes
  effective in the message part is otherwise unpredictable.
* Character set conversion is now only applied to message parts that
  have the "text/" content type. Previously, a message part that did
  not contain any control characters but was not of type "text/" was
  converted.
* When message file names in a maildir folder do not contain the ":2,"
  preceding the flags part, append one (Brandon Andrews).
* An invalid memory access when determining the current message in
  threaded mode has been fixed (MJ Ray).
* A "STRIP" makefile variable has been introduced to control the strip
  command at "make install".
* The "remove" command no longer causes a core dump because of a null
  pointer dereference when it is given a name with invalid shell syntax.
* Made it compile on UnixWare again (patch by Joe Julian).
* Fixes to build with more recent versions of Mozilla NSS.

-------------------------------------------------------------------------
(Continue reading)

Permalink | Reply | 0 comments |

Gmane