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

 
 

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

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

Submitted by:  Riccardo Mottola <rmottola>
Submitted on:  Tue 31 May 2005 01:18:41 PM UTC  
 
Category: Base/FoundationSeverity: 3 - Normal
Item Group: BugStatus: None
Privacy: PublicAssigned to: None
Open/Closed: Closed

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>
Project 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>
Project 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>
Project 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>
Project 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>
Project 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>
Project Member

 

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

CC list is empty

 

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):

 

 

Follows 1 latest change.

Date Changed By Updated Field Previous Value => Replaced By
Sun 09 Oct 2005 10:24:32 AM UTCCaSOpen/ClosedOpen=>Closed

Back to the top


Powered by Savane 3.1-cleanup1