2011/3/12 Iskren Chernev :
> Well, with your patch it doesn't seem to crash. There is also no list
> corruption, as far as I could test it :)
Excellent, thanks for tracking this down.
Kristian
> Regards,
> Iskren
>
> 2011/3/13 Kristian Høgsberg
>>
>> On Fri, Mar 11, 2011 at 7:32 PM, Iskren Cher
Those are all good fixes, thanks.
Kristian
On Fri, Mar 11, 2011 at 10:24 AM, Iskren Chernev
wrote:
> Ooops I didn't sent you the latest version of the final patch :)
>
> On Fri, Mar 11, 2011 at 4:54 PM, Iskren Chernev
> wrote:
>>
>> Some resources were not freed if the create function exited ea
Well, with your patch it doesn't seem to crash. There is also no list
corruption, as far as I could test it :)
Regards,
Iskren
2011/3/13 Kristian Høgsberg
> On Fri, Mar 11, 2011 at 7:32 PM, Iskren Chernev
> wrote:
> > Hello,
> > I found a bug and fixed it with the patch :)
> > to reproduce:
>
On Fri, Mar 11, 2011 at 7:32 PM, Iskren Chernev
wrote:
> Hello,
> I found a bug and fixed it with the patch :)
> to reproduce:
Hi,
I wasn't able to reproduce it immediately, but I know that there's a
crasher in there somewhere. I think the real fix is the patch I've
attached, could you give it
Ok, so I applied the attached patch for debugging, and here is the output:
# move mouse IN flower
XXX surface NULL # move mouse OUT of flower
XXX Prevented BAD THINGS FROM HAPPENING # move mouse IN flower again
XXX surface NULL # move mouse OUT of flower
XXX Prevented BAD THING
In my opinion the problem is this:
The code to remove the element from the list is called every time, and the
code to insert it is called only when 'surface'. So in case surface is NULL
the item won't be added, but will be removed next time the function is
entered. Isn't that the case?
I don't hav
On 03/12/2011 02:20 PM, Bill Spitzak wrote:
> On 03/12/2011 04:28 AM, Marty Jack wrote:
>> I have never encountered a system where it was believed to be desirable to
>> allow something to be removed twice. It is important to keep data
>> structures clean. If anything you would be more likely
On 03/12/2011 02:20 PM, Bill Spitzak wrote:
> On 03/12/2011 04:28 AM, Marty Jack wrote:
>> I have never encountered a system where it was believed to be desirable to
>> allow something to be removed twice. It is important to keep data
>> structures clean. If anything you would be more likely
On 03/12/2011 04:28 AM, Marty Jack wrote:
I have never encountered a system where it was believed to be desirable to
allow something to be removed twice. It is important to keep data structures
clean. If anything you would be more likely to see a debugging mode where the
lists were fully che
Second try.
Regards,
Iskren
On Sat, Mar 12, 2011 at 2:28 PM, Marty Jack wrote:
> I have never encountered a system where it was believed to be desirable to
> allow something to be removed twice. It is important to keep data
> structures clean. If anything you would be more likely to see a deb
I have never encountered a system where it was believed to be desirable to
allow something to be removed twice. It is important to keep data structures
clean. If anything you would be more likely to see a debugging mode where the
lists were fully checked after every insert or remove to make su
Well, the actual problem is that something was removed twice. And I know
where this place is, but I couldn't know if you would like to remove
elements multiple times with no problems, or treat the list very carefully
and remove elements only once. But then there should be a way to know if an
elemen
On 03/11/2011 07:32 PM, Iskren Chernev wrote:
> Hello,
>
> I found a bug and fixed it with the patch :)
>
> *to reproduce:*
> run compositor on top of x11
>
> repeat
>run flower
>drag & drop it a little
>move the pointer in and out of the compositor/flower
>Ctrl+C the flower cl
13 matches
Mail list logo
