Thomas Fricke posted on Sun, 07 Jun 2015 21:56:14 +0200 as excerpted: > sorry for the late response. Evolution really does not like your message > somehow. If I hit the reply button it segfaults right away :-)
Hmm... interesting. As you can see from my headers if you check (or if you have the user-agent header displayed if included, as pan does), I'm actually posting with pan, via gmane.org's list2news service. So evolution doesn't like something from one of: a) the pan post itself, as sent b) one of the headers (like received) that's routinely inserted by mail servers as they process the mail c) one of the headers the gmane list2news (or here, the reverse, news2list) service inserts, as it processes the news post and forwards it as mail to the list d) one of the headers (like list-help) the list-serve inserts... tho in this case you probably couldn't reply to other list posts either. e) some corruption introduced somewhere along the way f) something else I've not thought to mention in the above list. I've actually seen pan have similar issues, except on display of the post, not on reply. Because of the way pan works, storing the individual messages as files, I have been able to actually bisected the problem down to a single line and often to a single character, in several cases. Basically, I find the file in pan's cache, then make a good copy of it to restore as I need to while I experiment. I'll often start by replacing most of the body with say a single "Body" word, then trying to load the post in pan. If that works while it didn't originally, I know the problem is in the body. If it doesn't, I know it's in the headers. If it's in the body, I can simply bisect the body, trying one half and seeing if it works, then either adding or deleting half of the problem half, repeatedly, until I get to an individual line or at least an individual sentence or paragraph. With a bit of experience, I've learned to scan the problem text from there, looking for a non-standard character, perhaps a non-break-blank-space or some such, that doesn't fit in the claimed charset or that pan is otherwise likely to choke on. Usually I can find it, then confirm by replacing that character with something else and verifying that pan no longer chokes on it. If it's in the headers, I similarly bisect and scan them for something that doesn't look correct, except header formatting is much stricter than body formatting, so it's often easier to spot, and even if not, there's usually far fewer header lines than body, making bisecting a faster process. FWIW, one problem pan still has, AFAIK, is that if the MIME headers say there is supposed to be an attachment and it's missing, say because it was malware and was thus stripped, but leaving in place the header that claims it's there, pan can segfault on that. I thought I had filed a bug on it, and certainly reported it on the pan-dev list and kept a reproducer, but I don't see the bug filed now, so maybe I didn't. I'll have to check a bit better and do so if I haven't... Meanwhile, regardless of what evolution is fed, it shouldn't /segfault/. I'd strongly suggest doing a similar bisect and report, preferably first testing with a current version if yours isn't, just in case it's already fixed, because segfault bugs, particularly on applications that process untrusted incoming data such as mail, are a strong indication of a possible security issue (segfaults with accidentally bad data can often be turned into execute-arbitrary-badguy-code bugs with more deliberately exploitable bad data), and should be treated as such until they are either fixed or at least inspected by experts who can figure out whether they're a security issue or not. (Generally, it's just easier to fix them, once a reliable reproducer is found so the bug can actually be traced. This is the approach the Linux kernel folks normally take, for instance, fixing the bug without actually determining whether it is a security issue, thus the standard "all users must upgrade" advice on stable kernel releases.) And of course if the problem is in an original header that pan produced or in the body as posted, then filing a pan bug on it as well, should be considered, since in that case pan's output may not be standards compliant, or it may be standards compliant but still not recommended output, given the number of would-be readers/repliers that may have problems with the post. One other possibility. What version of gmime are you running? I traced one originally pan problem to a bug in the gmime library, versions 2.6.16-2.6.18. 2.6.15 didn't have the buggy code yet, and 2.6.19 fixed the bug, but if you have one of the versions in the affected range installed, that's almost certainly the problem right there. File a bug with your distro and have gmime upgraded to 2.6.19 or later. (FWIW, I now have 2.6.20 installed here, on gentoo/~amd64, ~ indicating testing, so normally reasonably new versions.) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman _______________________________________________ Pan-users mailing list Pan-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/pan-users
