Re: [bug #25037] gorm not correctly working on openbsd 4.3 sparc64

[Richard Frith-Macdonald]

On 28 Dec 2008, at 19:17, Sebastian Reitenbach wrote:

> Follow-up Comment #12, bug #25037 (project gnustep):
>
> gdnc doesn't crash anymore,

Great ... I'll close that bug then.

> but the test nsinvocation is segfaulting:

<snip>

> Expect: {99,large,99.99}, invoke: {99,large,99.99} forward:  
> {99,large,99.99}
>
> Program received signal SIGSEGV, Segmentation fault.
> memcpy (dst0=0x4ec86778, src0=0x800000000000009, length=0) at
> /usr/src/lib/libc/string/bcopy.c:91
> 91      /usr/src/lib/libc/string/bcopy.c: No such file or directory.
>        in /usr/src/lib/libc/string/bcopy.c

It would be nice to fix that, but the passing of large structures has  
always been problematic on many architectures ... so no software that  
I know of uses that feature, and it can be considered a very minor  
issue.

The length argument for the copy is clearly wrong (the size must be  
greater than zero) and the source pointer looks wrong too.

If you would like to try to figure out what's going on, the best thing  
would be to hack the nsinvocation.m test program to do the large  
structure test first, then run under gdb and set a breakpoint in  
gs_objc_msg_forward2() (the function the runtime calls when it needs  
to do forwarding) and step through looking at what is going on.  My  
suspicion is that the cifframe_t structure is being incorrectly  
initialised in cifframe_from_info() ... but that's only a guess.