discuss-gnustep
[Top][All Lists]
Advanced

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

Re: clang / libobjc2 stability / crashes


From: Riccardo Mottola
Subject: Re: clang / libobjc2 stability / crashes
Date: Wed, 18 Apr 2012 14:56:34 +0200
User-agent: Mozilla/5.0 (X11; FreeBSD i386; rv:11.0) Gecko/20120414 Firefox/11.0 SeaMonkey/2.8

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 address@hidden:address@hidden, selector has address@hidden:address@hidden
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



reply via email to

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