[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Gorm segfault on exit

From: Fred Kiefer
Subject: Re: Gorm segfault on exit
Date: Mon, 25 Feb 2013 09:15:36 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3

As I wrote I had to do this over twenty times to be able to reproduce the issue. Just keep on trying :-)

But being able to reproduce the problem wont help much. Riccardo has it all the time and still he cannot find out much more about it.

I had a look at the code of the class, that was reported as a zombie and there I found this comment:

 * The setFirstResponder method is used in this editor to allow it to
 * respond to messages forwarded to the window appropriately.
 * Unfortunately, once it's set to something, it cannot be set to nil.
 * This method allows us to set it to nil, thus preventing a memory leak.

I would start off from here and look for a specific case, where the first responder isn't cleared, even though the editor was released. The code that is used here only makes sure that the initial first responder is cleared, but it does not check, whether the actual first responder is the same and needs to be cleaned as well. I would suggest to just add this code to the unsetInitialFirstResponder method and let Riccardo test again.

As this is in no way connected to gui or any of the changes that happened there. This problem wont stop a gui release and I will drop out of this conversation.


On 25.02.2013 07:43, Gregory Casamento wrote:
I just opened and closed (in various ways) MDIndexer.gorm and I can't seem
to make this happen even once.

I have no doubt you're seeing it, but it's difficult to reproduce.

Am I missing a step to recreate the issue?


On Sun, Feb 24, 2013 at 6:43 PM, Riccardo Mottola <
address@hidden> wrote:

On 02/22/13 21:50, Fred Kiefer wrote:

The simplest way to find out is to run Gorm with Zombies turned on and
see which class gets that call. As I need too long to reproduce the issue,
it would be best if your did those checks.
After that we will know whether the issue is in Gorm or in gui code and
maybe we even have an idea on how to fix it.

  Indeed, Zombies help.

2013-02-25 00:19:24.328 Gorm[3852] *** -[GormWindowEditor
respondsToSelector:]: message sent to deallocated instance 0xba7923f4

I somehow remember it should drop into gdb by itself... but it doesn't,
where do I need to put a breakpoint to actually be able to get a stacktrace
and the responder information you ask for?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]