On 11.09.2011 14:03, Riccardo Mottola wrote:
On the infamous OpenBSD/sparc computer I get now.
2011-09-11 13:58:38.068 Terminal[24493] NSConnection.m:2601 Assertion
failed in -[NSConnection(Private) _service:forwardForProxy:]. Invalid
parameter not satisfying: type
2011-09-11 13:59:14.192 Vespucci[31124] NSConnection.m:2601 Assertion
failed in -[NSConnection(Private) _service:forwardForProxy:]. Invalid
parameter not satisfying: type
Could you please explain in details what you did to trigger this error?
Are these messages triggered when you tried to use service menu items
from GWorkspace or did you get them from the specific applications
(Terminal, Vespucci) directly and if so, what where you doing there?
The basic problem reported here is that a method signature doesn't have
type information attached to it. This gets detected in line 2601 of the
file NSConnection.m. There we also have some addition error reporting in
place. Could you please run your service applications with
--GNU-Debug=dflt. It would also be interesting to get even more
information from this method. What object are we trying to access (I
think it should be the GSServiceManager) and is the service method found
on the object?
Of course you should recompile Terminal and Vespucci first, just to make
sure they get linked against the current version of base.
I don't quite understand why the code in NSConnection does all the type
extraction by itself. To me it looks like we should reuse the code from
[NSObject -methodSignatureForSelector:] here and get the type
information from the NSMethodSignature. I think the main difference will
be in the case where the local object wont implement the method in
question. But exactly in that case it would be better to ask the object
for the method signature then to invent the type information locally.
David, Richard, you two should understand a lot more about this than me.
Is this reasoning correct and if so, do you think it is safe to replace
the code that close to release?
_______________________________________________
Gnustep-dev mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/gnustep-dev
