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

Group
 
 

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

Submitter:  Sebastian Reitenbach <buzzdee>
Submitted:  Mon 08 Dec 2008 06:12:06 AM UTC
   
 
Category:  Gorm Severity:  3 - Normal
Item Group:  Bug Status:  Duplicate
Privacy:  Public Assigned to:  gcasa
Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

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>
Group 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>
Group 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>
Group 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>
Group 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>
Group 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>
Group 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>
Group 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>
Group 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>
Group 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>
Group 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>
Group 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>
Group 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>
Group 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>
Group 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>
Group 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>
Group 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>
Group 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>
Group 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>
Group 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>
Group administrator
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>
Group Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

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
  • -email is unavailable- added by CaS (Posted a comment)
  • -email is unavailable- added by FredKiefer (Posted a comment)
  • -email is unavailable- added by rmottola (Posted a comment)
  • -email is unavailable- added by gcasa (Posted a comment)
  • -email is unavailable- added by buzzdee (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 11 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2010-07-23 rmottola Open/ClosedOpen Closed
    2009-01-08 buzzdee Attached File- Added nsundomanager.logoutput, #17226
    2009-01-04 buzzdee Attached File- Added gnustep-base-testsuite.output, #17212
    2009-01-04 buzzdee Attached File- Added patch.GSFFIInvocation.m, #17211
    2008-12-13 FredKiefer StatusIn Progress Duplicate
        Dependencies- Depends on bugs #25033
    2008-12-10 buzzdee Attached File- Added tests.log, #17020
    2008-12-08 gcasa StatusNone In Progress
        Assigned toNone gcasa
    2008-12-08 buzzdee Attached File- Added gorm1.png, #17003
        Attached File- Added gorm2.png, #17004

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code