> 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.