discuss-gnustep
[Top][All Lists]
Advanced

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

Re: gworkspace / clang / libobjc2 hang problem


From: David Chisnall
Subject: Re: gworkspace / clang / libobjc2 hang problem
Date: Thu, 25 Dec 2014 11:15:11 +0100

On 25 Dec 2014, at 11:08, Riccardo Mottola <riccardo.mottola@libero.it> wrote:

> Hi,
> 
> Riccardo Mottola wrote:
>> 
>> The patch seems to work with one or more operations on both gcc computers.
>> However on NetBSD with clang, on copy I get a hang even with at the first 
>> copy operation! Why? nothing meaningful should change. Is my new code buggy? 
>> Or does it trigger some runtime bug?
>> 
> I rewrote a simpler version of the patch: it is esentially the original code 
> "fixed" not to give an array-bounds-exception.
> 
> I think that both versions however should return NSZeroRect in case there are 
> no other file operations in queue! This second patch doesn't hang with 
> clang/libobjc2
> 
> (However it does also work worse: sometimes the next operation window 
> overlaps with the previous and doesn't get the right offset, very strange).

I haven't seen enough of the code to be sure, but two things to be aware of:

1) There is a difference between clang and gcc in the implementations of 
messages that return NSRect sent to nil.  GCC will return an undefined rect, 
clang will return a 0 rect.

2) It is *not* safe to pass an NSInvocation constructed with 
-forwardInvocation: that returns an NSRect between threads.  Doing so will 
corrupt the stack in the caller context.  It may work due to timing sometimes, 
but it should never be relied upon.  The argframe contains a pointer to the 
caller's stack where the result will be written.

David

-- Sent from my Difference Engine






reply via email to

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