bugGNUstep - Bugs: bug #25037, gorm not correctly working on...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

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

Submitted by:  Sebastian Reitenbach <buzzdee>
Submitted on:  Mon 08 Dec 2008 06:12:06 AM UTC  
 
Category: GormSeverity: 3 - Normal
Item Group: BugStatus: Duplicate
Privacy: PublicAssigned to: Gregory John Casamento <gcasa>
Open/Closed: Closed

(Jump to the original submission Jump to the original submission)

Fri 23 Jul 2010 11:03:35 AM UTC, comment #20:

Things for work me on sparc with gcc 2.95 (32bit though). There were many fixes and there have been no new reports on this bug. The related bug was closed. IN case, open a new bug with current, detailed information.

Riccardo Mottola <rmottola>
Project Member
Thu 08 Jan 2009 06:37:40 AM UTC, comment #19:

I added a lot of NSLog statements to NSUndoManager.m and nsundomanager.m, but I do not yet figured out what the problem is. appended is the NSLog output. nsudndomanager is run from within gdb, the output is from on the sparc64.

The same done on i386, the only difference is that the setState immediately after continuing the running program after the breakpoint, is set to 1 instead to 0 on the sparc64 box.

either the problem is there in undoing the thing, or it happened before, when putting the 1 on the undo stack. right now I have the feeling the undo would work, if there would have been the right stuff on the undo stack before, at least I can see, the setState gets called via the NSInvocation.m from the NSUndoManager.m.
I did not figured out yet, where it actually stored the stuff for later undo on that undo stack, and what it actually did put onto it.
Or, when I take a look at the backtrace, maybe a bug in libffi on sparc64?

(file #17226)

Sebastian Reitenbach <buzzdee>
Project Member
Mon 05 Jan 2009 11:35:20 AM UTC, comment #18:

On your tests ...

1. 'Unable to detach thread' ... that means the runtime failed to create a thread ... most likely your objc runtime is built without threading support and you need to rebuild with thread support. The other option is that there's a bug in the obc runtime thread support for your platform and you need to look at what might be wrong with it.
Either way, you need to go back to gcc as this is not a gnustep issue as such.

2. 'thread' does not terminate ... that's ok ... but I've changed it in trunk so it should.

3. diningPhilosophers dies not terminate ... that's normal.

4. nsfilehandle ... thaqt's normal too.

5. nsundomanager ... that would seem to show a bug

6. basic ... yes, that tests an uncaught exception.

So, of these it looks like (1) a problem with your libobjc and (5) a bug in NSUndoManager or something (quite possibly the invocation code) that it uses, or (possibly) a bug in the test program on 64bit systems.

For 5 it would be good to add some diagnostics and try to figure out what's wrong on your system.

Richard Frith-Macdonald <CaS>
Project Member
Sun 04 Jan 2009 08:56:15 PM UTC, comment #17:

In the hope that it might help I ran all the tests in the Testsuite on OpenBSD 4.4, i386 and sparc64.

the output where the tests fail, or where I'm not so sure whether is is a wanted result, is in the attached file.

(file #17212)

Sebastian Reitenbach <buzzdee>
Project Member
Sun 04 Jan 2009 06:55:46 PM UTC, comment #16:

I applied the changes to base-1.18.0. The testsuite/nsinvocation is working fine now. Also Ink is not crashing anymore (see bug #25040). However, drag 'n drop from elements of the palette into the window in Gorm doesn't work, and cut 'n paste in Ink does still not work too.

Sebastian Reitenbach <buzzdee>
Project Member
Sun 04 Jan 2009 05:08:45 PM UTC, comment #15:

Thanks ... that's certainly not the right fix (as it would break all other systems), but it might be a partial fix for your system.

If you need to have MFRAME_STRUCT_BYREF defined to 0 rather than 1 on your processor/operatingsystem in that file, then it probably need it defined that way in all files, and the place to do it is in base/Source/mframe.

That directory contains various configuration files in different subdirectories and a configure.ac fiel used to generate a configure file which selects which of the files from the subdirectories to use.

My guess is that you need to make a sparc64 subdirectory and copy the sparc/generic file into it, then copy sparc64/generic to sparc64/openbsd, edit it to change value of MFRAME_STRUCT_BYREF, and change configure.ac to use that file. At the moment your system is probably using the sparc/generic mframe configuration.

I've guessed at the changes needed, and made them to svn trunk. Please could you test and see if I got it right.

Richard Frith-Macdonald <CaS>
Project Member
Sun 04 Jan 2009 02:59:54 PM UTC, comment #14:

Hi,

after a bit debugging session, I found a way to make the nsinvocation test work.

Appended patch to GSFFInvocation.m (against base-1.18.0) fixes the crasher in frame#1 in the backtrace in comment #12:

(gdb) frame 1
#1 0x00000000478bce4c in -[GSFFIInvocation initWithCallback:returnp:values:frame:signature:] (self=0x4bc1bf10,
_cmd=0x47c88680, cif=0x4bd0da00, retp=0xfffffffffffd92f0, vals=0xfffffffffffd9200, frame=0x4bd0da00, aSignature=0x43bb9b90)
at GSFFIInvocation.m:284
284 memcpy(((cifframe_t *)_cframe)->values[i], vals[i],
(gdb) list
279 memcpy(((cifframe_t )_cframe)->values[i], (void **)vals[i],
280 ((cifframe_t *)_cframe)->arg_types[i]->size);
281 }
282 else
283 {
284 memcpy(((cifframe_t *)_cframe)->values[i], vals[i],
285 ((cifframe_t *)_cframe)->arg_types[i]->size);
286 }
287 }
288 #else

I fear the patch might break things on other systems, as it is very rude ;) therfore its only for reference to show what I did.

With the patch, nsinvocations works well:
# ./obj/nsinvocation
Starting
Calling proxy
Testing NS_MESSAGE ... ERROR ... expecting 6,6 and got 0,6
Testing NS_INVOCATION ... ERROR ... expecting 8,8 and got 0,8
Expect: 99, invoke: 0 forward: 0
Expect: 12345, invoke: 0 forward: -10240
Expect: 123456, invoke: 0 forward: 55296
Expect: 123456, invoke: 123456 forward: 123456
Expect: 123456, invoke: 123456 forward: 123456
Expect: 123.456, invoke: 123.456 forward: 123.456
Expect: 123.456, invoke: 123.456 forward: 123.456
Expect: 0x4a57f2f0, invoke: 0x4a57f2f0 forward: 0x4a57f0b0
Expect: 'string', invoke: 'string' forward: 'string'
Expect: 1, invoke: 0 forward: 0
Expect: 2, invoke: 0 forward: -10240
Expect: 3, invoke: 0 forward: 55296
Expect: 4, invoke: 4 forward: 4
Expect: 4, invoke: 4 forward: 4
Expect: 5.0, invoke: 5.0 forward: 5.0
Expect: 6.0, invoke: 6.0 forward: 6.0
Expect: 6.0, forward: 6.0
Expect: 0x4a57f1b0, invoke: 0x4a57f1b0 forward: 0x4a57f670
Expect: 'Hello', invoke: 'Hello' forward: 'Hello'
called multi argument method
Expect: {11,22}, invoke: {11,22} forward: {11,22}
Expect: {99,large,99.99}, invoke: {99,large,99.99} forward: {99,large,99.99}
Expect: {8,9}, invoke: {8,9} forward: {8,9}
Expect: {1,hello,1.23}, invoke: {1,hello,1.23} forward: {1,hello,1.23}
Expect: {8,9}, invoke: {8,9} forward: {8,9}
Expect: {1,hello,1.23}, invoke: {1,hello,1.23} forward: {1,hello,1.23}

Sebastian

Sebastian Reitenbach <buzzdee>
Project Member
Tue 30 Dec 2008 07:53:14 AM UTC, comment #13:

Richard suggested to tweak the nsinvocation to get the retLarge as the first, and research, why it is crashing from withing gdb. However, nsinvocation is actually not crashing in loopLarge, or retLarge, but in loopSmall (see stacktrace in last comment):

(gdb) list nsinvocation.m:490
485 printf("Expect: {99,large,99.99}, ");
486 [inv getReturnValue: &la];
487 printf("invoke: {%d,%s,%.2f} ", la.i, la.s, la.f);
488 la = [p retLarge];
489 printf("forward: {%d,%s,%.2f}\n", la.i, la.s, la.f);
490
491 SETUP(loopSmall:);
492 printf("Expect: {8,9}, ");
493 [inv setArgument: &tmpsm atIndex: 2];
494 [inv invokeWithTarget: t];
(gdb) list nsinvocation.m:497
492 printf("Expect: {8,9}, ");
493 [inv setArgument: &tmpsm atIndex: 2];
494 [inv invokeWithTarget: t];
495 [inv getReturnValue: &sm];
496 printf("invoke: {%d,%d} ", sm.c, sm.i);
497 sm = [p loopSmall: tmpsm];
498 printf("forward: {%d,%d}\n", sm.c, sm.i);
499
500 SETUP(loopLarge:);
501 printf("Expect: {1,hello,1.23}, ");

had no time yet to look, why the things happen, probably next year ;)

thanks
Sebastian

Sebastian Reitenbach <buzzdee>
Project Member
Sun 28 Dec 2008 07:17:52 PM UTC, comment #12:

gdnc doesn't crash anymore, but the test nsinvocation is segfaulting:
# gdb obj/nsinvocation
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "sparc64-unknown-openbsd4.4"...
(gdb) r
Starting program: /usr/ports/x11/gnustep/base/w-gnustep-base-1.18.0p0/gnustep-base-1.18.0/Testing/obj/nsinvocation
Starting
Calling proxy
Testing NS_MESSAGE ... ERROR ... expecting 6,6 and got 0,6
Testing NS_INVOCATION ... ERROR ... expecting 8,8 and got 0,8
Expect: 99, invoke: 0 forward: 0
Expect: 12345, invoke: 0 forward: -10240
Expect: 123456, invoke: 0 forward: 55296
Expect: 123456, invoke: 123456 forward: 123456
Expect: 123456, invoke: 123456 forward: 123456
Expect: 123.456, invoke: 123.456 forward: 123.456
Expect: 123.456, invoke: 123.456 forward: 123.456
Expect: 0x42789010, invoke: 0x42789010 forward: 0x427890b0
Expect: 'string', invoke: 'string' forward: 'string'
Expect: 1, invoke: 0 forward: 0
Expect: 2, invoke: 0 forward: -10240
Expect: 3, invoke: 0 forward: 55296
Expect: 4, invoke: 4 forward: 4
Expect: 4, invoke: 4 forward: 4
Expect: 5.0, invoke: 5.0 forward: 5.0
Expect: 6.0, invoke: 6.0 forward: 6.0
Expect: 6.0, forward: 6.0
Expect: 0x42788f30, invoke: 0x42788f30 forward: 0x42789330
Expect: 'Hello', invoke: 'Hello' forward: 'Hello'
called multi argument method
Expect: {11,22}, invoke: {11,22} forward: {11,22}
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
(gdb) bt
#0 memcpy (dst0=0x4ec86778, src0=0x800000000000009, length=0) at /usr/src/lib/libc/string/bcopy.c:91
#1 0x0000000049134e4c in -[GSFFIInvocation initWithCallback:returnp:values:frame:signature:] (self=0x4bc33e90, _cmd=0x49500680, cif=0x4ec86700, retp=0xfffffffffffc6b30,
vals=0xfffffffffffc6a40, frame=0x4ec86700, aSignature=0x4f0a5d90) at GSFFIInvocation.m:284
#2 0x00000000491356bc in GSFFIInvocationCallback (cif=0x4ec86700, retp=0xfffffffffffc6b30, args=0xfffffffffffc6a40, user=0x4ec86700) at GSFFIInvocation.m:531
#3 0x0000000043c5b1bc in ffi_closure_sparc_inner_v9 (closure=0x4c312000, rvalue=0xfffffffffffc6b30, gpr=0xfffffffffffc6c50, fpr=0xfffffffffffc6b50) at src/sparc/ffi.c:606
#4 0x0000000043c5b538 in ffi_closure_v9 () from /usr/local/lib/libffi.so.0.0
#5 0x0000000000105d2c in gnustep_base_user_main () at nsinvocation.m:497
#6 0x0000000000100c38 in _start ()
#7 0x0000000000100c38 in _start ()
Previous frame identical to this frame (corrupt stack?)
(gdb) quit

Sebastian Reitenbach <buzzdee>
Project Member
Sun 28 Dec 2008 03:49:33 PM UTC, comment #11:

> I'd say, libffi seems to work fine on openbsd sparc64


Does that mean that bug #23039 is fixed with that libffi then?
Does the base/Testing/nsinvocation.m test work?

Richard Frith-Macdonald <CaS>
Project Member
Sun 28 Dec 2008 03:18:11 PM UTC, comment #10:

updated to libff1-3.0.8, and openbsd 4.4, and latest stable of -make, -base, -gui, -back. the problem persists.
I still use the system compiler gcc-3.3.5. Together with help on the libffi mailing list I got the testsuite running with nearly no error anymore (only 2 compilation warnings, but no runtime errors). Therefore I'd say, libffi seems to work fine on openbsd sparc64.

Sebastian Reitenbach <buzzdee>
Project Member
Sat 13 Dec 2008 04:04:19 PM UTC, comment #9:

Marked this bug report as a duplicate of #25033 to reduce the noice level.

Fred Kiefer <FredKiefer>
Project Member
Thu 11 Dec 2008 06:31:13 AM UTC, comment #8:

I also ran the libffi testsuite, and posted the output to libffi-discuss. there were some unexpected failures, but all are syntax errors in the testsuite, because of old compiler.
As it doesn't seem that they care about to fix it, I'll try to install gcc-4.3, and recompile everything with that one.

Sebastian Reitenbach <buzzdee>
Project Member
Wed 10 Dec 2008 07:22:42 PM UTC, comment #7:

I did ran the base tests from the testsuite, logfile attached.

(file #17020)

Sebastian Reitenbach <buzzdee>
Project Member
Tue 09 Dec 2008 07:35:44 PM UTC, comment #6:

ok, i now also linked against ffcall, and added the patches from netbsd regarding sparc64. There gdnc crashes crashes on application connection, see bug #23039 but drag 'n drop is working there in gorm.

I'll go and recompile again, linking against libffi, and try again to drag 'n drop, without gdnc running, just to make sure that not gdnc causes the trouble.

Sebastian Reitenbach <buzzdee>
Project Member
Mon 08 Dec 2008 11:17:01 PM UTC, comment #5:

I link against ffcall. Check if you can get the patches which netbsd has, it needs some to the configure script for sparc and I don't rememerb tehm off-head.

Riccardo Mottola <rmottola>
Project Member
Mon 08 Dec 2008 08:44:50 PM UTC, comment #4:

Did you link -base against libffi or ffcall on your system? I linked against libffi.

Ink is crashing, when I enter a letter, or when I try to import a file, I'll open a different bug report for it.

Therefore I started gpbs with the following parameters:
--verbose --no-fork

and started ProjectCenter, but there cut 'n paste did not worked, and produced no output on the console of gpbs.
It did not matter whether I marked sth. with keyboard or mouse, and then pressed Alt-c. In the ProjectCenter menu I could see that Edit Copy got highlighted, also when I afterwards pressed ctrl-v to release it, I saw it highlighted but nothing on the console of gpbs. I also tried to release the text with the third mouse button, but with the same result.

However, when I drag 'n drop elements from the palette to the window, I see some output on the console of gpbs, e.g.:

2008-12-08 21:27:47.248 gpbs[20491] <PasteboardObject: 0x4a2b5450> declare types '(IBViewPboardType)' version 5
2008-12-08 21:27:47.254 gpbs[20491] <PasteboardObject: 0x4a2b5450> set data for type 'IBViewPboardType' version 0
2008-12-08 21:27:49.845 gpbs[20491] <PasteboardObject: 0x4a2b5450> get data for type 'IBViewPboardType' version 5
2008-12-08 21:27:49.846 gpbs[20491] get data for 0x49a827d0

The first two lines show up, when I press the mouse button, the other two, when I release it.

Sebastian Reitenbach <buzzdee>
Project Member
Mon 08 Dec 2008 06:07:57 PM UTC, comment #3:

I have an OpenBSD/sparc32 system and I just tested Gorm.
(that means I don't have any major troubles).
I do have troubles whith some of the daemons not starting up automatically sometimes or if, they are unreliable.
starting up gdomap, gdnc, gpbs manually and then starting gorm yields me a working gorm, I can drag items fine.

Before debugging drag-and-drop (where you could test if dragging files in GWorkspace works) you could try the pasteboard alone
compile a fresh copy of Ink from the examples, type some text, copy, paste. It should work flawlessy. If not, try starting gpbs manually. I need that on some computers (also depending on the speed/load of the machine). If that works, then we get back to drag-and-drop.

My openbsd box is running a sligtly older version, I use, maybe try that too.

Riccardo Mottola <rmottola>
Project Member
Mon 08 Dec 2008 05:56:04 PM UTC, comment #2:

Hi,

I restarted gpbs, and attached gdb to it.
Then I started Gorm again, opened a new application document, and tried again dragging elements from the palette into the mywindow, but the problem persists.

its a sparc64 system, not a sparc. On my sparc there I even face more trouble. Even simple tools from base, like defaults, are segfaulting.

You could send me a public ssh key, and I can setup an account for you on that box, if that would help.

Or let me know anything I could do to debug the problem, and I'll report back.

thanks
Sebastian

Sebastian Reitenbach <buzzdee>
Project Member
Mon 08 Dec 2008 01:19:02 PM UTC, comment #1:

This could very well be a problem with gpbs. Usually problems dragging and dropping are. :) Try starting the daemon explicitly from the command line and see if you can do it then (after also restarting the application) and let me know what happens.

Unfortunately, I don't have a sparc with OpenBSD on it, so I can't test this directly at the moment. The only functioning sparc I currently have has Solaris.

Gregory John Casamento <gcasa>
Project AdministratorIn charge of this item.
Mon 08 Dec 2008 06:12:06 AM UTC, original submission:

on OpenBSD 4.3, installed these packages:
libffi-3.0.7
gnustep-make-2.0.6
gnustep-base-1.16.5
gnustep-gui-0.14.0
gnustep-back-0.14.0
gnustep-gorm-1.2.6

# gcc -v
Reading specs from /usr/lib/gcc-lib/sparc64-unknown-openbsd4.3/3.3.5/specs
Configured with:
Thread model: single
gcc version 3.3.5 (propolice)

the drag 'n drop of items from palettes into e.g. the application window doesn't work. It is possible to start dragging, but when releasing the mouse button, the item from the palette is not added to the window.

a second thing is a problem with the classes outline view.
the first screenshot is when opening the classes outline view the first time. NSObject is "invisible", only when clicking on it, the text will become visible. The second screenshot shows, when clicking on each of the classes in the hierarchy, the class where clicked before, becomes "invisible". In the second screenshot I clicked on all the classes from the top to the bottom, up to the class higlighted right now.

Sebastian Reitenbach <buzzdee>
Project Member

 

Attached Files
file #17226:  nsundomanager.logoutput added by buzzdee (5KiB - text/plain)
file #17211:  patch.GSFFIInvocation.m added by buzzdee (371B - text/x-objcsrc)
file #17020:  tests.log added by buzzdee (461KiB - text/x-log)
file #17003:  gorm1.png added by buzzdee (12KiB - image/png - screenshots of classes outline view)
file #17004:  gorm2.png added by buzzdee (11KiB - image/png - screenshots of classes outline view)

 

Digest:
   bug dependencies.

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by CaS (Posted a comment)
  • -unavailable- added by FredKiefer (Posted a comment)
  • -unavailable- added by rmottola (Posted a comment)
  • -unavailable- added by gcasa (Posted a comment)
  • -unavailable- added by buzzdee (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 11 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Fri 23 Jul 2010 11:03:35 AM UTCrmottolaOpen/ClosedOpen=>Closed
    Thu 08 Jan 2009 06:37:40 AM UTCbuzzdeeAttached File-=>Added nsundomanager.logoutput, #17226
    Sun 04 Jan 2009 08:56:14 PM UTCbuzzdeeAttached File-=>Added gnustep-base-testsuite.output, #17212
    Sun 04 Jan 2009 03:01:36 PM UTCbuzzdeeAttached File-=>Added patch.GSFFIInvocation.m, #17211
    Sat 13 Dec 2008 04:04:19 PM UTCFredKieferStatusIn Progress=>Duplicate
      Dependencies-=>Depends on bugs #25033
    Wed 10 Dec 2008 07:22:42 PM UTCbuzzdeeAttached File-=>Added tests.log, #17020
    Mon 08 Dec 2008 01:19:20 PM UTCgcasaStatusNone=>In Progress
      Assigned toNone=>gcasa
    Mon 08 Dec 2008 06:12:06 AM UTCbuzzdeeAttached File-=>Added gorm1.png, #17003
      Attached File-=>Added gorm2.png, #17004

    Back to the top


    Powered by Savane 3.1-cleanup1