bugGNUstep - Bugs: bug #13237, even basic tests fail to run on...

Group
 
 

bug #13237: even basic tests fail to run on OpenBSD 3.7 / sparc

Submitter:  Riccardo Mottola <rmottola>
Submitted:  Tue 31 May 2005 01:18:41 PM UTC
   
 
Category:  Base/Foundation Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Bug
Status:  None Privacy:  Public
Assigned to:  None Open/Closed:  Closed
* Mandatory Fields

Post a Comment

Add a New Comment Rich Markup
   

Discussion

Sun 09 Oct 2005 10:24:32 AM UTC, comment #5: 

Closing this, as the problems seem to be to do with running things without having built/installed first, and there has been no further followup for months.
However, perhaps we need to do something to prevent people running the tests without having installed/built libraries and bundles used?

Richard Frith-Macdonald <CaS>
Group Member
Fri 17 Jun 2005 12:45:08 PM UTC, comment #4: 

the situation is a bit less dramatic now, i am able to start Ink.app or Price.app.
As always  dameons are not spawned automatically if they are missing. If gpbs is not running, the application core-dumps when it is trying to launch it. Furthermore gopen is prone to core-dump. but at least I see nice icons and windows on the screen :)

maybe it is time to clean up the regression suite and also try the new testcases that I have seen commited.

Riccardo Mottola <rmottola>
Group Member
Fri 10 Jun 2005 11:08:48 PM UTC, comment #3: 

I could reliably reproduce it with that code, but now with current CVS it doesn't happen anymore, I get a
2005-06-10 23:15:26.000 benchmark[23622] File NSData.m: 169. In readContentsOfFile Open (benchmark.m) attempt failed - No such file or directory

repeated hundreds of times.

I want to stress the point that this doesn't mean that gnsutp is working on openbsd. Launching any of the typical gnustep apps (with like gopen Ink.app) produces a quite immediat segmentation fault. I was trying only to reproduce the fault in the base tests to ease debugging.

CUrrently with current CVS code, behaviour did change! I can start Ink with "openapp ink". "gopen Ink.app" makes it start but gopen itself coredumps (gopen always had problems on openbsd, they just eeem to be more acute now). Startup times are long, I'd say at least triple to what I was used.. but still better

I haven't rebuilt -gui and -back...

Thus I would close this bug, I'll build more applications and rebuild the rest of core and then hope to be able to post more specific bug reports.

ah, a final note. Just typing "gmake" in base/testing fails:
Making all for test_tool nsfilehandle...
 Compiling file nsfilehandle.m ...
nsfilehandle.m:3: Foundation/NSManager.h: No such file or directory
gmake[1]: * [shared_obj/nsfilehandle.o] Error 1


Riccardo Mottola <rmottola>
Group Member
Sat 04 Jun 2005 09:17:18 AM UTC, comment #2: 

The nsbundle example behaves as described if there is no bundle to load ... (easily remedied by building the bundle).

So the only thing which looks like a problem is the virtual memory exhausted in the benchmark program.

Can you reproduce that reliably with the current code from CVS?

Richard Frith-Macdonald <CaS>
Group Member
Tue 31 May 2005 03:24:26 PM UTC, comment #1: 

FYI, basic is supposed to fail that way - those tests are just examples and you really have to look at what the proper output should be.  We need a real testsuite (I'm working on that).

Adam Fedor <fedor>
Group administrator
Tue 31 May 2005 01:18:41 PM UTC, original submission:  

Running "basic" in base/Testing produces;
./basic
2005-05-31 14:53:03.000 basic[28824] ("/", home, nicola)
2005-05-31 14:53:04.000 basic[28824] Orig: (English)
2005-05-31 14:53:04.000 basic[28824] Set: (Bletch, English)
2005-05-31 14:53:04.000 basic[28824] Set: (English)
size = 24
pos = 24
element 6687016 has offset 0, alignment 1
element 6687017 has offset 8, alignment 8
element 6687018 has offset 16, alignment 8
2005-05-31 14:53:04.000 basic[28824] {five = 4.5; four = 33; one = test; three = "2005-05-31 12:53:04 +0000"; two = YES; }
2005-05-31 14:53:04.000 basic[28824] 0
2005-05-31 14:53:04.000 basic[28824] test 1 ok
2005-05-31 14:53:04.000 basic[28824] Test 2 ok
Hello from object at 0x6ae148
./basic: Uncaught exception NSUnknownKeyException, reason: Unable to find value for key


nsarray works fine.

benchmarks run fine up to one test which exhaust my virtual emmory and then aborts.
  NSString (10 copy) <@'ConstantString'>          4.942           2.902
Virtual memory exhausted
Abort trap

nsarchiver works fine
nsinvocation works fine

nsbundle fails:
/nsbundle
  GNUstep Base Resources: /usr/GNUstep/System/Library/Libraries/Resources/gnustep-base
  gnustep-base version string = 1.10.1
  gnustep-base version number = 110.1

  Executable is in ./nsbundle
  Full directory is /usr/src/gnustep-cvs/gnustep/core/base/Testing/shared_obj/nsbundle
Looking for LoadMe bundle...
  Bundle directory is /usr/src/gnustep-cvs/gnustep/core/base/Testing

  • ERROR: Can't find LoadMe bundle


Riccardo Mottola <rmottola>
Group Member

 

Attached Files

This item currently has no attached files.

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

Attach Files:
   
   
Comment:
   

 

Dependencies

This item does not depend on any other items.

No items depend on this one.

 

Mail Notification Carbon-Copy List

 

Votes

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.

 

History

Follows 1 latest change.

Date Changed by Updated Field Previous Value => Replaced by
2005-10-09 CaS Open/ClosedOpen Closed

Back to the top

Powered by Savane 3.16-8b18.
Corresponding source code