[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: clang / libobjc2 stability / crashes
Re: clang / libobjc2 stability / crashes
Wed, 18 Apr 2012 14:56:34 +0200
Mozilla/5.0 (X11; FreeBSD i386; rv:11.0) Gecko/20120414 Firefox/11.0 SeaMonkey/2.8
On 18 Apr 2012, at 10:58, Riccardo Mottola wrote:
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.
- clang 3.0
- libobjc2 (from our source)
I have an essentially unusable GNUstep system and ask if other experience
* 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
sometimes unoptimized code hides memory access errors, I have been hit
by that more than once. Off-by array accesses, etc...
* 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).
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.
* 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.
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
Uh, this changed then. We should update our online reference too then.
A quick fix, thanks.
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
Other applications instead seem to work and I couldn't get them to crash, like
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
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)
memcpy(f->values[i], vals[i], f->arg_types[i]->size);
Doesn't trap it.