Re: clang / libobjc2 stability / crashes

[David Chisnall]

On 18 Apr 2012, at 10:58, Riccardo Mottola wrote:

> Hi all,
> 
> having put FreeBSD 9 on my laptop, which removes obj-c from gcc and uses gcc 
> only for legacy purposes until the clang switch, I need had to switch to 
> clang.
> - x86-32
> - clang 3.0
> - libobjc2 (from our source)
> 
> I have an essentially unusable GNUstep system and ask if other experience 
> similar problems.
> Some information:
> * tried switch ARC on and off, no help

The ARC autorelease pool is new (and potentially buggy!) code and Banlu has 
reported a problem with it when the NSRunLoop autorelease pool is recreated, so 
I'll try to track that down.  Disabling it for now is a good idea just to 
eliminate one potential source of bugs - the old code has been very well tested 
so should be reliable.

> * compiling the application with debug=yes seems to solve the problem

This implies a problem in optimisation.  The question is whether it is a 
compiler bug (performing an unsafe transform) or a GNUstep bug (compiler doing 
a transform it's allowed, but which was not expected).

> * I compiled base with/wthout optimizations, no help. I fail to compile gui 
> without for the reasons mentioned in another email

debug=yes should be turning off optimisation.  If it isn't and the presence of 
debug information is changing the program semantics, that is really weird...

> The applications which do crash, crash consistently and upon user action:
> * FTP, connect to a server (e.g. ftp.gnustep.org, anonymously)
> * PRICE, run the Curves filter
> * GWorkspace: try to start an application by double-clicking

If it's a user action, then it may be related to FFI / invocation stuff.  

> GSPdf doesn't crash, but on exit it prints out:
> Calling [GSPdf -applicationShouldTerminate:] with incorrect signature.  
> Method has C12@0:4@8, selector has i12@0:4@8

That's just a warning.  Justing just pointed out that my ifdef was the wrong 
way around so I'm not disabling these warnings in release mode.  It just means 
that the GSPdf's -applicationShouldTerminate: method returns BOOL, but the 
caller expects int (actually an NSApplicationTerminateReply).  Since you're the 
GSPdf maintainer, you can make this go away by changing the type of the method 
to NSApplicationTerminateReply and the return value to either NSTerminateCancel 
or NSTerminateNow.

> Other applications instead seem to work and I couldn't get them to crash, 
> like Ink.

Not being able to get applications to crash is usually a good thing....

> David is kindly helping me debugging this, but we made little progress. 
> valgrind shows an error in GSFFIInvocation:
> 
> ==4553== Source and destination overlap in memcpy(0x3975f40, 0x3975f40, 24)
> ==4553==    at 0x5E5B5: memcpy (in 
> /usr/local/lib/valgrind/vgpreload_memcheck-x86-freebsd.so)
> ==4553==    by 
> 0xA8FD7D:_i_GSFFIInvocation__initWithCallback_values_frame_signature_  
> (GSFFIInvocation.m:380)
> 
> 
> Since the application then hangs inside valgrind, there is no further output.
> 
> But I put an if() code to print out the size when src and dst are the same, 
> it never gets reached (and the warning goes away).
> 
> I don't include stacktrace because I do not want to spam with a long message.
> 
> I did run the base tests and there is nothing really suspicious (see other 
> email).
> 
> Somebody notices the same? Or has some ideas

I vaguely remember seeing this before, but having now looked at the code, it 
seems correct.  The memcpy call is copying between a buffer allocated by an 
NSMutableData and the FFI buffer, so they should be non-overlapping.  I 
suggested changing this to a memmove() when I saw the valgrind error, but I 
think that this would just hide a real error.  

David

-- Sent from my STANTEC-ZEBRA