Re: clang / libobjc2 stability / crashes

[Riccardo Mottola]

Hi,
> 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.
my libffi is the package of FreeBSD:
libffi-3.0.9        Foreign Function Interface

> > * 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).
sometimes unoptimized code hides memory access errors, I have been hit 
by that more than once. Off-by array accesses, etc...
> > * 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...
Well, as I wrote in the other post, I get with several -Ox flags, added 
by the libpng config program which gets queried. This is a make 
problem... I got no reply yet.
> > 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.
my FFI version is 3.0.9, just for the record
> > 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.
Uh, this changed then. We should update our online reference too then.
A  quick fix, thanks.
> > 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....
Yes, but it is added information: If every application did crash, it 
could have been a different bug, like an NSApp initialization problem. 
Which could of course still be, just that the problem created remains 
hidden.
> > 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)
> 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.
I wonder how something like this:
+      if (f->values[i] ==  vals[i])
+       fprintf(stderr, "size: %lu\n", (long unsigned) 
f->arg_types[i]->size);
       memcpy(f->values[i], vals[i], f->arg_types[i]->size);

Doesn't trap it.

Riccardo