Re: [Evolution-hackers] bugs.
Andre, On Thu, 2007-03-01 at 04:09 +0100, Andre Klapper wrote: > > can evolution developers please run their desktops with accessibility > enabled, to also run into this issue 5 times a day, like i do? > srini, can the patch please go in for 2.10? As, I have commented on the bug itself. It just avoids the crash and can go in. I have updated bugzilla also now to commit_now. -Srini ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] bugs.
now that i have found out the aim of the 2.9.x evo series (= stability), i'd love to present you a list of crasher reports. it is also available at http://bugzilla.gnome.org/duplicates.cgi?sortby=count&reverse=1&maxrows=50&openonly=1&product=Evolution Evolution crashes when closing main window http://bugzilla.gnome.org/show_bug.cgi?id=334966 174 duplicates. NEEDINFO state. crash in camel-mime-part-utils.c:71 http://bugzilla.gnome.org/show_bug.cgi?id=352284#c8 93 duplicates, and an inviting stacktrace. http://bugzilla.gnome.org/show_bug.cgi?id=348149#c79 82 duplicates. can somebody (varadhan? sankar?) please comment on comment 79? Crash in ETable a11y code http://bugzilla.gnome.org/show_bug.cgi?id=330728 61 duplicates. can evolution developers please run their desktops with accessibility enabled, to also run into this issue 5 times a day, like i do? srini, can the patch please go in for 2.10? and of course there are lots of crashers with good traces available, e.g. 387143, 271693, 411018, 410750, 349913, 411885, 412582, 412565, 405777, to list only a few. would be nice to fix some of them before branching for evolution 2.19 (we will switch to the gnome version naming system to reduce confusion, won't we? ;-) harish, can i get a "new features in 2.10"-list and a "really definitely(TM) planned stuff for 2.20"-list? (...nagging...) thanks a lot folks, andre -- mailto:[EMAIL PROTECTED] | failed! http://www.iomc.de/ | http://blogs.gnome.org/portal/aklapper signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Memory management in mail message formatting
Riccardo, IIRC while solving some inline image crashes, I came across a similiar issue. For that I added a free function to the puri, which gets called when the puri is freed. You can see em-format.h:119 You can use this to achieve what you need. -Srini On Wed, 2007-02-28 at 19:54 +0100, Riccardo Lancellotti wrote: > Hi. > I am working on the next release of the patch to show the contact photo > of the "from:" address in the mail messages (bug #360184). > > I have some doubt about how memory is managed during mail message > formatting. > If I am not wrong, the formatting of single elements such as icons is > asynchronous and is managed through em_format_add_puri(), where > em_format_add_puri requests a CamelMimePart object as a parameter > > Now the critical question: I create a CamelMimePart object from a memory > buffer obtained from e-d-s interaction (the contact photo from the > addressbook). The EContactPhoto is not a GObject, but just a struct that > I must free on my own (no g_objet_unref magic can help me). > > The problem is that I have not a clear idea on *when* g_free must be > called. > Freeing memory in the main thread is not a good idea and leads to random > crashes (especially when reading mailing lists in digest mode -- tried > on the currently available patch). > *Not* freeing memory seems to be even worse because it looks like a > memory leak. > > Is there some document that helps me understand the inner details of > mail message formatting? Do you have any advice? > > ___ > Evolution-hackers mailing list > Evolution-hackers@gnome.org > http://mail.gnome.org/mailman/listinfo/evolution-hackers ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Memory management in mail message formatting
Hi. I am working on the next release of the patch to show the contact photo of the "from:" address in the mail messages (bug #360184). I have some doubt about how memory is managed during mail message formatting. If I am not wrong, the formatting of single elements such as icons is asynchronous and is managed through em_format_add_puri(), where em_format_add_puri requests a CamelMimePart object as a parameter Now the critical question: I create a CamelMimePart object from a memory buffer obtained from e-d-s interaction (the contact photo from the addressbook). The EContactPhoto is not a GObject, but just a struct that I must free on my own (no g_objet_unref magic can help me). The problem is that I have not a clear idea on *when* g_free must be called. Freeing memory in the main thread is not a good idea and leads to random crashes (especially when reading mailing lists in digest mode -- tried on the currently available patch). *Not* freeing memory seems to be even worse because it looks like a memory leak. Is there some document that helps me understand the inner details of mail message formatting? Do you have any advice? -- Best regards, Riccardo signature.asc Description: Questa รจ una parte del messaggio firmata digitalmente ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
