Re: GWorkspace hangs on first exit attempt. Remote objects problem?

[Sebastian Reitenbach]

On Saturday, March 9, 2013 15:44 CET, Richard Frith-Macdonald 
<richard@tiptree.demon.co.uk> wrote: 
 
> 
> On 9 Mar 2013, at 12:20, Fred Kiefer wrote:
> >> 
> >> here I checked:
> >> (gdb) p [invocation->_sig isOneway]
> >> $7 = 1 '\001'
> >> 
> >> so it appears that the information about oneway is properly passed, right?
> >> (gdb) p invocation->_sig->_methodTypes
> >> $9 = 0x17a9c30 "Vv24@0:8@16"
> >> 
> >> Is this enough? In case not you need to tell me which part to inspect.
> > 
> > 
> > I think the interesting stuff happens in frame 4. There we end up in the 
> > needsResponse == YES branch, which seems wrong for a one way method call. 
> > You should have a look at the block from line 2016 to 2039 and find out why 
> > needsResponse gets set to YES. Most likely the method type gets compute 
> > wrongly. We seem to get these strange results sometimes from libobjc2.
> 
> Yes ... I can't reproduce  the problem on any system I have apaer from the 
> debian 64bit one where I recently installed using llvm/clang and libobjc2.
> So this seems to be either an llvm/clang specific issue or a libobjc2 
> specific issue, with the code going wrong later on (ie the invocation itsself 
> seems fine).

I also see the problem on my macppc, using libobjc2 but compiled with gcc 4.2.1.

As Fred

      needsResponse = NO;
      flags = objc_get_type_qualifiers(type);
NSLog(@"flags: %d", flags);
      if ((flags & _F_ONEWAY) == 0)
        {
NSLog(@"here setting YES");
          needsResponse = YES;
        }

prints out:
2013-03-09 16:26:14.759 GWorkspace[30760] flags: 1024
2013-03-09 16:26:14.759 GWorkspace[30760] here setting YES

So I tried to figure out where type comes from, so added this
some lines before:

  type = [[inv methodSignature] methodType];
NSLog(@"got type: %d, %c", type, type);

which prints:

2013-03-09 16:26:14.758 GWorkspace[30760] got type: 214276192, `

But the numbers I get here seem to be different when I try it multiple times.
Shouldn't this give me always the same?

Sebastian


> Unfortunately, llvm/clang produces output here that gdb on debian stable 
> won't handle, so while I can reproduce the exception I can't debug it ...
> I'm going to try finding a backport of a very recent gdb, or failing that, 
> build gdb from source, to see if it can tell me where the compiler/runtime is 
> producing an unexpected result.

Have the same problem with the system gdb on OpenBSD, luckily there is gdb 
7.5.1 in ports 
which can deal with that.

> _______________________________________________
> Discuss-gnustep mailing list
> Discuss-gnustep@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnustep