« Return to Thread: clang / libobjc2 stability / crashes
Re: clang / libobjc2 stability / crashes
by Riccardo Mottola-5
::
Rate this Message:
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
_______________________________________________
Discuss-gnustep mailing list
Discuss-gnustep@...
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
> 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.
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.
>
+ 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
_______________________________________________
Discuss-gnustep mailing list
Discuss-gnustep@...
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
« Return to Thread: clang / libobjc2 stability / crashes
| Free embeddable forum powered by Nabble | Forum Help |
