Bug 3084

http://www.thewildbeast.co.uk/claws-mail/bugzilla/page.cgi?id=bug-writing.html

Sorry to hear that you are not interested in problem reports and that you consider them as not helpful. I will refrain from forwarding further bug report then and unsubscribe from the Fedora watchbugzilla acl, too.

Michael, I don't recall saying "not interested", I'm just suggesting that you can provide more information, such as what the bug is and the steps to reproduce it.

I had hoped that a Claws Mail developer would have a theory about what may have gone wrong or what could be ruled out. Even negative acknowledgement or a theory that the crash might be just a side-effect would have been more encouraging than pointing me at the bug-writing instructions.

There is a detailed backtrace attached to those tickets, but for several crashes of Claws Mail its users do not know how to reproduce the crash. Sometimes all they can tell is that they have had it crash more than once. 

When it crashes spontaneously, perhaps only as a side-effect (IMAP access instabilities e.g.), the users receive notification by the Automatic Bug Reporting Tool, which they use to submit the bug reports in Fedora bugzilla. We can't do much with those reports, if there are no steps on how to reproduce a problem. And we don't forward each report anyway. For instance, if Claws Mail is taken down in glibc memory management due to heap corruption (or double-free, whatever) and the user tries to perform the same actions, but cannot reproduce the problem, there is nothing we can do other than telling the user to run memtest86+, be more careful when using the UI, or that networking problems can crash CM during IMAP access. Eventually we receive a report about the same/similar crash again, and if there isn't an upstream ticket about it yet, what to do then?

For now I've lost interest in learning about crash reports in Claws Mail. I had hoped that a report such as bug 2769 would be useful, would be responded to, and might lead to finding something (such as not resetting ptrs to NULL after a free(), for example). Or that a report like bug 2398 would ever be responded to by a developer.

Hi Michael,

This class of bugs are as you say, old and their seemingly random appearance point at some memory corruption that is difficult to pinpoint.

Sadly these stacktraces, while technically good, full with symbols available, are just the picture of the "exit wound", and I never could find what triggers the corruption. Running under valgrind 24/7 until it happens would help, but it is really difficult and nobody has had the courage to do it until now.

I remember trying hard to reproduce this kind of bug, and I myself sometimes have faced it, but never when running valgrind, and at work, where I have other priorities. So I did not manage to understand it.

You say "a class of bugs". I don't know whether this particular crash is only a side-effect.

But what several other crash reports have in common is that they are related to losing/interrupting an IMAP connection due to networking troubles or using the "go offline" button or trying to close a busy Claws Mail.

That's exactly why I had thought that bug 2769 would be relevant and interesting, since it contains steps on how to reproduce it and results in crashing Claws Mail in random places such as memory management.

Is it wrong to assume that a developer, who is familiar with the design of the software, could proof-read the "go offline" feature and figure out why/where it crashes Claws Mail by forcefully interrupting an active IMAP connection? Isn't that very similar to the crashes users encounter when facing interruptions of their networking connection during IMAP access? Is there a thread that continues working with pointers to deallocated structures, for instance?

From the perspective of a bug-triager, my hands are empty if you've given up.