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
Item Group:  Bug Status:  None
Privacy:  Public Assigned to:  None
Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

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

 

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

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

CC list is empty

 

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.

 

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.13-02a9.
Corresponding source code