Hello,
my Mutt from hg tip hangs while reading the headers of [1]this message,
printing
Fetching message headers... 0/15 (0%)
and using up almost all the CPU time.
Running Mutt with -d2 prints:
[...]
4< * 2 FETCH (FLAGS () UID 1498 INTERNALDATE "17-Nov-2008 03:43:15 +0100"
RFC822.SIZE 5687 BODY[HEADER.FIELDS (DATE FROM SUBJECT TO CC MESSAGE-ID
REFERENCES CONTENT-TYPE CONTENT-DESCRIPTION IN-REPLY-TO REPLY-TO LINES
LIST-POST X-LABEL)] {345}
imap_read_literal: reading 345 bytes
4< )
parse_parameters: `boundary="===============3605358539010039876=="'
parse_parameter: `boundary' = `===============3605358539010039876=='
and then Mutt hangs.
Tracing Mutt reveals that after parsing the boundary of the multiplart
message, it repeatedly calls mremap(2), increasing the size of the
mapped range at every call:
[...]
24323 1 mutt CALL write(3,0xbfbfaa30,0x44)
24323 1 mutt GIO fd 3 wrote 68 bytes
"parse_parameters: `boundary=\"===============3605358539010039876==\"\
'\n"
24323 1 mutt RET write 68/0x44
24323 1 mutt CALL write(3,0xbfbfaa30,0x45)
24323 1 mutt GIO fd 3 wrote 69 bytes
"parse_parameter: `boundary' = `===============3605358539010039876=='\
\n"
24323 1 mutt RET write 69/0x45
[...]
24323 1 mutt CALL open(0xbfbf8278,0,0x80e6d98)
24323 1 mutt NAMI "/usr/share/i18n/esdb/esdb.dir.db"
24323 1 mutt RET open 8
24323 1 mutt CALL fcntl(8,2,1)
24323 1 mutt RET fcntl 0
24323 1 mutt CALL __fstat30(8,0xbfbf81d8)
24323 1 mutt RET __fstat30 0
24323 1 mutt CALL mmap(0,0x3080,1,2,8,0,0,0)
24323 1 mutt RET mmap -1153204224/0xbb438000
24323 1 mutt CALL close(8)
24323 1 mutt RET close 0
24323 1 mutt CALL munmap(0xbb438000,0x3080)
24323 1 mutt RET munmap 0
24323 1 mutt CALL mmap(0,0x100000,3,0x14001002,0xffffffff,0,0,0)
24323 1 mutt RET mmap -1154482176/0xbb300000
24323 1 mutt CALL mmap(0,0x100000,3,0x14001002,0xffffffff,0,0,0)
24323 1 mutt RET mmap -1155530752/0xbb200000
24323 1 mutt CALL mmap(0,0x100000,3,0x14001002,0xffffffff,0,0,0)
24323 1 mutt RET mmap -1156579328/0xbb100000
24323 1 mutt CALL munmap(0xbb200000,0x100000)
24323 1 mutt RET munmap 0
24323 1 mutt CALL mremap(0xbb100000,0x100000,0,0x200000,0x14000000)
24323 1 mutt RET mremap -1156579328/0xbb100000
24323 1 mutt CALL mremap(0xbb100000,0x200000,0,0x300000,0x14000000)
24323 1 mutt RET mremap -1159725056/0xbae00000
24323 1 mutt CALL mremap(0xbae00000,0x300000,0,0x400000,0x14000000)
24323 1 mutt RET mremap -1159725056/0xbae00000
24323 1 mutt CALL mremap(0xbae00000,0x400000,0,0x500000,0x14000000)
24323 1 mutt RET mremap -1159725056/0xbae00000
24323 1 mutt CALL mremap(0xbae00000,0x500000,0,0x600000,0x14000000)
24323 1 mutt RET mremap -1166016512/0xba800000
24323 1 mutt CALL mremap(0xba800000,0x600000,0,0x700000,0x14000000)
24323 1 mutt RET mremap -1166016512/0xba800000
24323 1 mutt CALL mremap(0xba800000,0x700000,0,0x800000,0x14000000)
24323 1 mutt RET mremap -1166016512/0xba800000
24323 1 mutt CALL mremap(0xba800000,0x800000,0,0x900000,0x14000000)
24323 1 mutt RET mremap -1166016512/0xba800000
24323 1 mutt CALL mremap(0xba800000,0x900000,0,0xa00000,0x14000000)
24323 1 mutt RET mremap -1166016512/0xba800000
24323 1 mutt CALL mremap(0xba800000,0xa00000,0,0xb00000,0x14000000)
24323 1 mutt RET mremap -1166016512/0xba800000
24323 1 mutt CALL mremap(0xba800000,0xb00000,0,0xc00000,0x14000000)
24323 1 mutt RET mremap -1178599424/0xb9c00000
[...]
Is anybody able to reproduce this? Or is anybody able to read [1]this
message with the latest Mutt? (I just want to make sure it's not a OS
problem before sending a bug report. This is NetBSD/i386 5.99.01, BTW.)
Regards, Jukka
[1] http://salmi.ch/~jukka/mutt/hang.message
--
bashian roulette:
$ ((RANDOM%6)) || rm -rf ~