|
From: | Richard Frith-Macdonald |
Subject: | Re: [bug #25037] gorm not correctly working on openbsd 4.3 sparc64 |
Date: | Mon, 29 Dec 2008 13:34:22 +0000 |
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.
[Prev in Thread] | Current Thread | [Next in Thread] |