HDTenEightyP/NetNews huggingface dataset:
From: davea@quasar.mti.sgi.com (David B.Anderson)
Newsgroups: comp.sys.sgi.bugs
Subject: Re: bug in syms.h (building SPIM)?
Date: 12 Jan 93 17:12:09 GMT
Organization: Silicon Graphics, Inc.  Mountain View, CA

In article <1993Jan12.131934.20309@shannon.ee.wits.ac.za> philip@concave.cs.wits.ac.za (Philip Machanick) writes:
>I tried compiling a public domain MIPS architecture (SPIM), and ran
>into several problems. Here is one that appears to be a bug in an
>SGI header file, syms.h (4.0.5F; in 4.0.1, the "__mips" is replaced by
>"mips"):
>
>There is a line
>
>#if __mips
>
>followed a few lines down by
>
>#else  /* !defined(__mips) */
>
>Surely "#if X" is not the same as "#if defined(X)" - so either the
>"#if" or the comment is wrong.

This appears in several files. Ugh.  I fixed this just now
for the next major release. Thanks for noticing the (minor) ugliness..

The compiler driver does -D__mips, which has the same meaning as
-D__mips=1.  Since the value of __mips is 1, the result is the same, so
you need not change anything (unless you wish to).  Changed to
#ifdef __mips for the next major release for readability.

>More important - between the "#if" and the "#else" is
>
>#include "cmplrs/stsupport.h"
>
>which header file doesn't exist (nor does the directory cmplrs).

cmplrs headers are not installed by default, but they are on the
compilers installation media for the machine.

Install
        dev.cmplrs_hdr.internal
Or if the compilers on that machine came from a 'maint' tape install:
        maint_dev.dev_cmplrs_hdr.internal

Either of those will get you cmplrs/stsupport.h

Use
        versions -I
to see what is currently installed.


>Any hints on how to work around this would be welcome. I would rather
>not patch the header file unless reassured that this won't break
>anything else.

Fixing the .h files won't break anything.

>For that matter if anyone has built SPIM or any other architecture
>simulator it would be useful for a course I am giving soon.

Someone else will have to deal with this one.

Regards,
[ David B. Anderson             (415)390-4263             davea@sgi.com ]
Newsgroups: comp.sys.sgi.bugs
From: sandrock@aries.scs.uiuc.edu (Mark Sandrock)
Subject: f77 uopt hangs on g92 file
Organization: University of Illinois at Urbana
Distribution: usa
Date: Wed, 6 Jan 1993 22:39:00 GMT

I am trying to build Gaussian 92 on a Crimson here, but the build gets
stucks on the file 'prism.F'. Installing the new (3.10) compilers did
not clear this problem. The file will compile with -O0 or -O1 but not
with -O2 (-O). I can work around it of course, but it seems that this
bug should have been detected/corrected by now -- after all, I'm far
from the first person to build G92 on an IP17, etc. So I'm wondering,
could there be something about our system that could be causing this
problem? It's hard to imagine what, but I thought I'd ask...

Thanks,

Mark Sandrock
-- 
Univ of Illinois at Urbana-Champaign	  'The measure of mental health
Chemical Sciences Computing Services	  is the disposition to find good
505 S. Mathews Ave./Urbana, IL 61801	  everywhere.'
Email: sandrock@aries.scs.uiuc.edu		       -RWE
From: hoesel@igc.ethz.ch (Frans van Hoesel)
Newsgroups: comp.sys.sgi.bugs
Subject: splft2 or interp weirdness
Date: 11 Jan 93 14:03:16 GMT
Organization: University of Groningen, the Netherlands


        - splft2 *or* interp does not work. Make a interpl window while using
          mwm instead of 4Dwm) of size 870*580 pop up the colormap, select
          color #3 (green) for the left color in interp and color #4 (yellow)
          for the rigth color. In the lower left corner of interp blue
          pixels will show up (color #5). The problem does not depend on mwm
          or 4Dwm, but does depend on the window size.


	  looking into the code of interp, this bug is most likely in splft2
	  because the argument to splft2 in interp are:

    intens[0] = startcolor;
    intens[1] = startcolor;
    intens[2] = endcolor;
    intens[3] = endcolor;

    parray[0][0] = MINX+1.0;
    parray[0][1] = MINY+1.0;
    parray[1][0] = MINX+1.0;
    parray[1][1] = MINY-1.0+(MAXY-MINY)*0.25;
    parray[2][0] = MAXX-1.0;
    parray[2][1] = MINY-1.0+(MAXY-MINY)*0.25;
    parray[3][0] = MAXX-1.0;
    parray[3][1] = MINY+1.0;

    splf2(4, parray, intens);

	  the float arguments must be exactly on a perfect rectangle, but
	  for some reason the result is wrong.

--frans
-- 
--    ==============================================================    --
----  ===  frans van hoesel             hoesel@igc.ethz.ch       ===  ----
--    ==============================================================    --
Newsgroups: comp.sys.sgi.bugs,comp.sys.sgi.hardware
From: acas@cgl.citri.edu.au (Andrew Cassin)
Subject: IRIX 4.0.5F/RE/FDDI on a 340
Summary: A possible inst or inst image bug?
Keywords: see subject
Organization: Collaborative Information Technology Research Institute
Date:  8 Jan 93 08:20:09 GMT


Hi,
	Today we had a RE (1 pipeline) installed on a 340. After upgrading
	to 4.0.5F, we (meaning the SGI SE and myself) suddenly found
	that the kernel would not link as a symbol "ipg_type" was not
	defined in any of the files in /usr/sysgen/boot. We were running
	4.0.5A before the RE upgrade.
	
	Moving the driver /usr/sysgen/boot/if_ipg.o to /usr/sysgen 
	caused the kernel to link and run successfully but we have 
	no FDDI connectivity as this driver  is no longer part of the 
	running kernel.

	Disk space was not a problem, the installs went fairly smoothly
	(once we sorted out the tftp perms :), and the RE is successfully
	running, at the expense of FDDI. The Service Engineer suspected
	that the maintenance images were not quite right for our system, 
	but that is a preliminary observation.

	Any ideas dave/SGI? I would be happy to send
	more detailed information (CD part #'s etc...) if required.

Andrew Cassin
RMIT Advanced Computer Graphics Centre
email address: acas@godzilla.cgl.citri.edu.au

PS. Some information after the 4.0.5F software install was complete:

godzilla 56% df
Filesystem                 Type  blocks     use   avail %use  Mounted on
/dev/root                   efs   31482   22608    8874  72%  /
/dev/dsk/lv1                efs 5742126 5201449  540677  91%  /usr2
/dev/usr                    efs  573672  488313   85359  85%  /usr
/dev/dsk/dks0d4s7           efs 1975100 1004978  970122  51%  /usr/scratch
manda:/usr/appl             nfs 1834496 1581568  252928  86%  /usr/appl

godzilla 57% hinv -v
4 33 MHZ IP7 Processors
FPU: MIPS R2010A/R3010 VLSI Floating Point Chip Revision: 3.0
CPU: MIPS R2000A/R3000 Processor Chip Revision: 2.0
On-board serial ports: 2 per CPU board
Data cache size: 64 Kbytes
Instruction cache size: 64 Kbytes
Secondary data cache size: 256 Kbytes
Main memory size: 64 Mbytes
I/O board, slot F: IO3
IEEE-488 bus controller 0
RealityEngine Graphics option installed
Tape drive: unit 6 on SCSI controller 1: 8mm cartridge
Disk drive: unit 2 on SCSI controller 1
Disk drive: unit 1 on SCSI controller 1
Integral SCSI controller 1: Version WD33C93A
Tape drive: unit 7 on SCSI controller 0: QIC 150
Disk drive: unit 4 on SCSI controller 0
Disk drive: unit 3 on SCSI controller 0
Disk drive: unit 2 on SCSI controller 0
Disk drive: unit 1 on SCSI controller 0
Integral SCSI controller 0: Version WD33C93A

godzilla 59% uname -a
IRIX godzilla 4.0.5F 08280217 IP7

Newsgroups: comp.sys.sgi.bugs
From: u8013033@cc.nctu.edu.tw (   Kuo Jang Ju)
Subject: test
Organization: National Chiao Tung University
X-Newsreader: TIN [version 1.1 PL6]
Date: Fri, 8 Jan 1993 06:55:06 GMT



--

 +------------------------------------------------------------------------+
 |                           U       |   Dept.  Communication        |
 |----------------------------------------|   National Chiao Tung Univ.   |
 |                                        |   1001 Ta Hsueh Rd.           |
 |    ;   ,,,,  ,,,,   :      :''':  :    |   Hsinchu,  Taiwan, R.O.C.    |
 | ''''''':  '     ' '':'':   :   :,,:,,, |   qj  qHt        |
 |  :''': : '     ' ,,,:,,:,  :,,,:  :  ; |   sj1001          |
 |  :,,,; :`     `     :  ;   :   :  ;  ; |-------------------------------|
 |  ,,,,, : `     `  '':'''   :   :  ;  ; |   Addr.: 2nd fl. 16, 193 ?    |
 |     ;  :  '     : ,,:,,,   :,,,:  ;  ; |          Kong  Wen  Rd.       |
 | '''';'':  '     ,   :      :   :  ;  ; |       Hsinchu, Taiwan, R.O.C. |
 |     ;  :`'   ` , ''':''''  :  ,;  ;  ; |   s193162    |
 |   . ;  :      ;`.   :      :,'    '  ; |                               |
 |    ;   :     ,   `......' ,'     ' `.' |@ Tel. : (035) 281733         |
 |----------------------------------------+-------------------------------|
 |    K u o     J a n g  -  J u    (KJJ)  |Email: u8013033@cc.nctu.edu.tw |
 +------------------------------------------------------------------------+

Newsgroups: comp.sys.sgi.bugs
From: scottm@maui.corp.sgi.com (Scott Machtmes)
Subject: Re: Soundfiler kills all of my windows
Organization: Silicon Graphics, Inc.
Date: Wed, 6 Jan 1993 18:21:00 GMT

I am running 4.0.5F on my indigo and also use soudfiler in my .chestrc.
My soundfiler works perfectly. However, 4.0.5F is not supported on Personal
Iris's. Probably have to wait for the next rev.
-- 

  ---------------------------------------------------------------- 
Scott Machtmes, System Support Engineer, Mt.View,CA,Silicon Graphics.
    Internet         : scottm@sgi.com
    UUCP             : {sun,decwrl,pyramid,ucbvax}!sgi!scottm
    Telephone        : (415) 390-3913
    US Mail          : 2171 Landings Drive, Mountain View, CA 94043
    FAX              : (415) 960-3393
    SGI office mail  : Mail Stop DWR-275
Newsgroups: comp.sys.sgi.bugs
From: wes@uf.msc.edu (Wes Barris)
Subject: Bug in ipastelrw.c
Reply-To: wes@msc.edu
Organization: AHPCRC, Minnesota Supercomputer Center
Date: Mon, 11 Jan 1993 18:40:50 GMT

The following lines are found in
/usr/people/4Dgifts/iristools/imgtools/ipaste.lrw.c

/* allocate the memory for the pixel data to be then fed to lrectwrite */
    imgbuf = (unsigned long *) malloc(xsize*ysize*sizeof(long));
    imgbuf = (unsigned long *) longimagedata(argv[1]);

However, in /usr/people/4Dgifts/iristools/libgutil/imgread.c the imgbuf
is malloced for you.

    base = (long *)malloc(image->xsize*image->ysize*sizeof(long));

As a result, the malloc line in ipastelrw.c is not necessary and should
be removed.

===============================================================================
Wes Barris                                                   PH: (612) 626-8090
Minnesota Supercomputer Center, Inc.                         Email: wes@msc.edu
Newsgroups: comp.sys.sgi.bugs
From: benoist@netcom.com (Tom Benoist)
Subject: libimage iopen() bug
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
Date: Wed, 6 Jan 1993 20:02:47 GMT

Some wont consider this a bug.
I also understand that 4Dgifts is officially unsupported demoware.
Anyway, the problem:

/usr/people/4Dgifts/iristools/libimage/open.c

If iopen() fails because its not sent a readable file
in the proper format, it returns without:
1. Freeing up Memory it allocates using calloc
2. closing the file descriptor  

The result is that using this code in an app that queries the
user for filenames, you run the good chance of eventually
running over the Max Limit of 100 for open files.  As we all
know, after that point File IO basically stops working and
your app becomes "quite impotent"

Considering the assumed usage of the library for command line
image apps and of course the other amazing gifts brought to us
from Mr Haeberli, all is forgiven.

Anyway, this one bit me, so I thought it should be mentioned.


-Tom Benoist
benoist@netcom.netcom.com

Newsgroups: comp.sys.sgi.bugs
From: pwhite@pyrite.chem.unc.edu (Peter S. White)
Subject: Possible Fortran Xlib conflict
Organization: UNC-CH
Date: Thu, 7 Jan 1993 17:15:45 GMT

I have recently been moving my graphics code to Silicon Graphics
machines, I have tried this on several all running the latest OS
version.  The code is all written in FORTRAN with the exception
of some routines in C which make calls to Xlib.  This all works
well on my DECstation, but when I run the code on SG machines after
calling the X initialization routines the FORTRAN I/O routines
have a wierd bug.  The first newline character for each formatted
WRITE is missing.

My question is has anyone else seen this?  I can't find any errors
in my code but it is entirely possible that I am doing something
to overwrite a flag.  This occurs in several programs where the same
graphics package is used and I am worried that there is some sort of
conflict between the C and FORTRAN runtime routines.

Peter S. White                            pwhite@pyrite.chem.unc.edu
Department of Chemistry
University of North Carolina
Chapel Hill, NC
Newsgroups: comp.sys.sgi.bugs
From: guy@wmsg02.wm.estec.esa.nl (Guy Brooker)
Subject: Re: Soundfiler kills all of my windows
Organization: ESA/Estec/WMS, Noordwijk, The Netherlands
Date: Mon, 4 Jan 1993 10:27:45 GMT

In article <1992Dec29.151037.253@uc.msc.edu>, wes@uf.msc.edu (Wes Barris) writes:
 > I have the following line in my .chestrc file:
 > 
 >     "SoundFiler"        f.checkexec "/usr/sbin/soundfiler"
 > 
 > This way I can use the toolchest to start this program.  If I do so, then
 > use the "Quit" button to terminate it, all of my xwshs are removed as well!
 > 
 > This only happens if the soundfiler program is started as shown above.  If
 > I start it by typing "soundfiler" in a window, I can terminate it without
 > disasterous results.
 > 
 > I am running IRIX 4.0.5 on a 4D/35.
 > 
 > -- 
 > ===============================================================================
 > Wes Barris                                                   PH: (612) 626-8090
 > Minnesota Supercomputer Center, Inc.                         Email: wes@msc.edu

The same happens if you start it from WorkSpace...
Nasty isn't it..

Guy

-- 

-------------------------------------        	Guy Brooker
Internet: guy@wm.estec.esa.nl        		European Space Research and
	  guy@wmsg02.dnet.estec.esa.nl		Technology Centre (ESTEC)
	  gbrooker@estec.esa.nl
Bitnet  : gbrooker@estec.bitnet		SPAN    : ESTERS::GUY
Phone	: +31-1719-83611		Fax	: +31-1719-85617
Mail	: ESTEC JW/WMS, Keplerlaan 1, 2200AG NOORDWIJK, The Netherlands

Newsgroups: comp.sys.sgi.bugs
From: mguttman@scholia.wbme.jhu.edu (Mike Guttman)
Subject: Problem running CaseVision remotely
Reply-To: mguttman@scholia.wbme.jhu.edu
Organization: Johns Hopkins University, Dept. of Biomedical Engineering
Date: Thu, 7 Jan 1993 22:31:03 GMT


I have a problem running CaseVision remotely on workstations
if they are not on the same sub-net.  I get the error, "Cannot
attach to process xxxx," after the run key is pressed.

Anybody know how to do this correctly?

- Mike

Newsgroups: comp.sys.sgi.bugs
From: guy@wmsg02.wm.estec.esa.nl (Guy Brooker)
Subject: imgworks and Greyscale TIFF
Organization: ESA/Estec/WMS, Noordwijk, The Netherlands
Date: Fri, 8 Jan 1993 10:48:56 GMT

Perhaps this is a bug in the ImageVision Library. If you load a grey
scale Tiff into imgworks, and save it as an SGI file, one gets garbage
out. imgworks seems to consider it is working with a colour dataset rather
than monochrome, as various operations behave in a bizare manner. Infact
loading and manipulating the grey scale image, after working with a colour
tiff, causes imgworks to crash.

A workaround is to restart before using the grey scale image, immediately
use the function 'Colour to Greyscale' which seems to invert the image (?),
then 'Invert' to return to normal. From then on its OK, and recognised as
Grey Scale. Saveing as an SGI image then works correctly....

Guy

-- 

-------------------------------------        	Guy Brooker
Internet: guy@wm.estec.esa.nl        		European Space Research and
	  guy@estwm0.dnet.estec.esa.nl		Technology Centre (ESTEC)
	  gbrooker@estec.esa.nl
Bitnet  : gbrooker@estec		SPAN    : ESTERS::GUY
Phone	: +31-1719-83611		Fax	: +31-1719-85617
Mail	: ESTEC JW/WMS, Keplerlaan 1, 2200AG NOORDWIJK, The Netherlands
From: dong@umiacs.umd.edu (Dong Chen)
Newsgroups: comp.sys.sgi.bugs
Subject: How to check and change swapspace (was Re: panic faulting when
Date: 6 Jan 93 09:19:24 GMT
Distribution: usa
Organization: UMIACS, University of Maryland, College Park, MD 20742

In article <uh43lv0@zuni.esd.sgi.com> olson@anchor.esd.sgi.com (Dave Olson) writes:
>
>It isn't an out of swap problem at all.  There is a disk error
>of some kind, *or* you have somehow configured the system to believe
>that there is more swap space than will fit on that partition.
>
Sorry this is a FAQ, but I cann't find it from my saved old news files.

How do you check the swap space and change it ?
Also, is there a way to make sure weather it's a disk error or just swap.
Thanks,
Newsgroups: comp.sys.sgi.bugs
From: mike@research
Subject: Picking Splines
Organization: Animal Logic Research, Sydney Australia
Date: Wed, 30 Dec 1992 01:27:30 GMT


We have had trouble picking splines using gselect.
We are using an Indigo XS24 R4000 running IRIX4.0.5F.

Starting with ~4Dgifts/examples/grafix/select1.c we replaced the
call to drawplanet() with the following piece of code.
The picking works fine on the curve hull (drawn with bgnline,endline)
but not with the actual curve (drawn with crv ).

------ cut here -----------------
static Boolean init_basis = TRUE;
short BEZIER_ID = 1;
const float bezier_basis[4][4] = {
  {-1.0,  3.0, -3.0, 1.0},
  { 3.0, -6.0,  3.0, 0.0},
  {-3.0,  3.0,  0.0, 0.0},
  { 1.0,  0.0,  0.0, 0.0}
};
const float FPS = 30.0;


void drawplanet()
{
 float X1 = 200.0;
 float Y1 = 200.0;
 float X2 = 400.0;
 float Y2 = 300.0;

  float geom[4][3];

  if(init_basis) 
  {
    init_basis = FALSE;
    defbasis(BEZIER_ID, bezier_basis);
  }

  color( 2 );

  curvebasis(BEZIER_ID);
  curveprecision((short)FPS);

  geom[0][2] = geom[1][2] = geom[2][2] = geom[3][2] = 0.0;

  geom[0][0] = X1; geom[0][1] = Y1;
  geom[1][0] = X1; geom[1][1] = Y2;
  geom[2][0] = X2; geom[2][1] = Y1;
  geom[3][0] = X2; geom[3][1] = Y2;

  crv(geom);

  bgnline();
  v3f(geom[0]);
  v3f(geom[1]);
  v3f(geom[2]);
  v3f(geom[3]);
  endline();

}
----- end cut --------------

Our email address is a bit wonky at the moment so could replies please
be posted to this newsgroup.

Thanks,
Mike Murray
Newsgroups: comp.sys.sgi.bugs
From: bobg@rains.wpd.sgi.com (Bob Green)
Subject: Re: libgl_s.a does not exist
Reply-To: bobg@rains.wpd.sgi.com (Bob Green)
Organization: sgi
Distribution: comp.sys.sgi.bugs
Date: Wed, 6 Jan 93 16:59:23 GMT

In article <ITKIN.93Jan6094833@jade.itd.nrl.navy.mil>, itkin@jade.itd.nrl.navy.mil (David Itkin) writes:
|> Hello,
|>    On an Indigo running 4.0.5 the /usr/lib/libgl_s.a file is missing.  There 
|> is a /usr/lib/libgl_s, but this is not an archive file.
|>   Why is there not libgl_s.a?  Why is there a /usr/lib/libgl_s?  Any help 
|> would be appreciated.
|> 
|> 	David Itkin
|> 	Jade Simulations
|> 	itkin@jade.itd.nrl.navy.mil

Sounds like an installation problem.  The typical cause is that you
have not yet loaded the "maintenance" CD.  Since libgl_s.a is machine
configuration specific and the original Iris Developer's Option (where
libgl_s.a lives) was released before 4.0.5, it is found in the maintenance
products.
 

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
	Bob Green
	Silicon Graphics Computer Systems
	2011 N. Shoreline Blvd.
	Mountain View, CA 94039

	Email: bobg@sgi.com
	Phone: (415) 390-3438
From: scottm@maui.corp.sgi.com (Scott Machtmes)
Newsgroups: comp.sys.sgi.bugs
Subject: Re: panic faulting when out of memory
Date: 6 Jan 93 18:25:31 GMT
Distribution: usa
Organization: Silicon Graphics, Inc.

In article <uh43lv0@zuni.esd.sgi.com>, olson@anchor.esd.sgi.com (Dave Olson) writes:
|> In <Jan05.220529.70886@yuma.ACNS.ColoState.EDU> jamison@yuma.ACNS.ColoState.EDU (Jamie Gulden) writes:
|> 
|> 
|> | This probably isn't a bug but...
|> | 
|> | Does IRIX (4.0.4) normally panic fault if it runs out of swap
|> | space?  I've got a short 5-7 line program that I try to find
|> | out how much memory I can allocate and it keeps panic faulting.
|> | 
|> | The syslog has a bunch of these:
|> | 
|> | Jan  5 13:52:35 nagel unix: dks0d3s1: Swap out failed blkno 0x3C514 (page still in memory)
|> | Jan  5 13:52:35 nagel unix: 
|> | Jan  5 13:52:35 nagel unix: dks0d3s1: Swap out failed blkno 0x3C834 (page still in memory)
|> | Jan  5 13:52:35 nagel unix: 
|> | Jan  5 13:52:35 nagel unix: dks0d3s1: Swap out failed blkno 0x3CA9C (page still in memory)
|> | Jan  5 13:56:53 nagel syslogd: restart
|> | 
|> | 
|> | And then the system comes up with this:
|> | 
|> | Jan  5 13:57:04 nagel syslogd: restart
|> | Jan  5 13:57:05 nagel savecore: reboot after panic: 
|> | Jan  5 13:57:05 nagel PANIC: swapoutpts - i/o error in swap
|> | 
|> | 
|> | So, is there a disk I/O problem, did we tell it to use more blocks
|> | than there actually are, or something else I'm missing.
|> 
|> It isn't an out of swap problem at all.  There is a disk error
|> of some kind, *or* you have somehow configured the system to believe
|> that there is more swap space than will fit on that partition.
|> 
|> There are a couple of places in the swapping code where the system
|> is fully committed, and can't recover on an error; in most cases it
|> will just kill the process that it was trying to swap (or retry it
|> later).
|> --

I also had a customer that had added more swap using the " swap -a " command and
had set the swap boundary's slightly overlapping on another partition causing 
the very same symptoms.

  ---------------------------------------------------------------- 
Scott Machtmes, System Support Engineer, Mt.View,CA,Silicon Graphics.
    Internet         : scottm@sgi.com
    UUCP             : {sun,decwrl,pyramid,ucbvax}!sgi!scottm
    Telephone        : (415) 390-3913
    US Mail          : 2171 Landings Drive, Mountain View, CA 94043
    FAX              : (415) 960-3393
    SGI office mail  : Mail Stop DWR-275
From: ciemo@bananapc.csd.sgi.com (Dave Ciemiewicz)
Newsgroups: comp.sys.sgi.bugs
Subject: Re: PIOCPSINFO (proc) always EINVAL
Keywords: PIOCPSINFO proc debug
Date: 6 Jan 93 23:07:05 GMT
Organization: Silicon Graphics, Customer Support Division

In article <1993Jan6.181444.26115@pixar.com>, brighton@pixar.com (Bill Carson) writes:
|> Has anyone had any luck with the PIOCPSINFO ioctl?
|> According to the 4.0.5 proc(4) man page:
|> 
|> >          void *p;
|> >          retval = ioctl(fildes, code, p);
|> >
|> >     The argument p is a generic pointer whose type depends on the specific
|> >     ioctl code.  Where not specifically mentioned below, its value should be
|> >     zero.  <sys/procfs.h> contains definitions of ioctl codes and data
|> >     structures used by the operations.
|> > ...
|> >   PIOCPSINFO
|> >     This returns miscellaneous process information such as that reported by
|> >     ps(1).  p is a pointer to a prpsinfo structure containing at least the
|> >     following fields:
|> >

Unfortunately, the PIOCPSINFO ioctl is currently unimplemented, thus the
EINVAL error.  This will be remedied in the next major operating system
release but there are currently no plans to have it implemented as part
of the 4.0.5 series.
Newsgroups: comp.sys.sgi.bugs
From: almgren@math.uchicago.edu (Robert Almgren)
Subject: C++ and -mips2
Keywords: C++, mips2
Reply-To: almgren@math.uchicago.edu
Organization: The University of Chicago, Department of Mathematics
Date: Sat, 9 Jan 1993 15:39:35 GMT


The program below compiles and runs properly with

    CC -o prog prog.C

but dumps core, apparently on the assignment, when compiled with

    CC -mips2 -o prog prog.C

It does the same with the -v2 flag.

Am I overlooking something obvious, or is something wrong with the
compiler?  (System is Crimson R4000; compilers are 3.10 release).

					Robert Almgren

					University of Chicago
					almgren@math.uchicago.edu

=====================================================================
			File "prog.C"

#include <stdlib.h>
#include <stdio.h>

main()
{
	printf("Beginning of program; allocating d\n");

	double *d = new double[3];
	printf("d has been allocated; setting d[0]\n");

	d[0] = 1.;
	printf("d[0] has been set; quitting\n");
}

=====================================================================
Newsgroups: comp.sys.sgi.bugs