| Re: % FINDFILE: Error managing child process. [message #40226] |
Mon, 26 July 2004 07:08  |
George N. White III
Messages: 56
Registered: September 2000
|
Member |
|
|
On Sun, 25 Jul 2004, Timm Weitkamp wrote:
> On 24.07.04 at 21:21 -0500, Craig Markwardt wrote:
>
>> Timm Weitkamp <dont.try@this.address> writes:
>>> I am having an annoying problem with FINDFILE on a Sunblade with IDL 6.0
>>> (version = { sparc sunos unix Solaris 6.0 Jun 27 2003 64 64}). I run an
>>> IDL program that runs fine on other machines (PCs running Linux) and used
>>> to work on this Sunblade too, and now it stops with an error message at a
>>> call to FINDFILE. The call is alright, the problem is that FINDFILE seems
>>> to spawn an "ls" or something, because I get the same error when I spawn
>>> "ls" by hand:
>>>
>>> IDL> $ls
>>> % Error managing child process.
>>> Not enough space
>>>
>>> What is this? Bug? Feature? Memory problem? It actually occurs with *any*
>>> spawned command (I tried "cat" or even non-existent commands with the same
>>> result). Can I circumvent this somehow? Any help appreciated. Here's the
>>> system info:
>>
>> I seem to recall a friend having a problem like this. Somehow, by
>> accident, his "/tmp" scratch area was non-writeable, except by root.
>> Once we made it writeable, then all sorts of things started to work
>> again. We speculated that somehow IDL was attempting to make a
>> temporary file, which it couldn't do when permissions were wrong.
>
> Thank you for this hint, Craig, which I will keep in mind. At first
> glance, though, it doesn't exactly seem to be that (/tmp/ is writable).
> Another thing is that I now tried with different IDL releases (5.4, 5.6,
> and 6.0). The problem occurs with 5.6 and 6.0, but not with 5.4.
> Unfortunately my code relies on some functionality introduced in 5.6.
>
> Also, it only occurs after allocating a considerable bunch of memory for
> an array (something like 4 GB out of the total of 6 GB of RAM available).
> But once the bug strikes, even freeing memory with DELVAR or TEMPORARY
> does not help anymore.
The "real" unix fork of a large process requires reserving double the
memory. The IRIX documentation says:
"The IRIX system allows programs occupying more space than the system
limit to run, since each program is only partially loaded into memory
at any given time. One of the effects of this policy is that the IRIX
system has to preallocate swap space based on likely future usage, and
sometimes this prediction is incorrect. When the swap space is
actually needed, the IRIX system allocates the most convenient
available space, not the specific space allocated. So the physical
allocation is separate from the accounting allocation.
If your system preallocates all your swap space, but the space has not
yet been used, it may appear that your system is running out of swap
space when it is not. It is possible that your system has simply
preallocated the rights to future swap space to existing processes,
and no new processes can allocate space due to the strict swap space
accounting in the IRIX system."
To work around this, it is customary to add "virtual" swap space.
> I worked on other Sunblades before (albeit with more memory available) and
> never ran into this. May have to contact RSI.
RSI's documentation says:
"RSI strongly recommends the use of the FILE_SEARCH function in place of
the FINDFILE function. FILE_SEARCH is more platform-independent, provides
greater functionality, and is easier to use than FINDFILE. FILE_SEARCH is
ultimately intended as a replacement for FINDFILE."
--
George N. White III <aa056@chebucto.ns.ca>
Head of St. Margarets Bay, Nova Scotia, Canada
|
|
|
|
| Re: % FINDFILE: Error managing child process. [message #40231 is a reply to message #40226] |
Sun, 25 July 2004 15:40  |
andrew.cool
Messages: 47
Registered: July 2003
|
Member |
|
|
Timm Weitkamp <dont.try@this.address> wrote in message news:<Pine.LNX.4.44.0407251434380.21616-100000@localhost.localdomain>...
> On 24.07.04 at 21:21 -0500, Craig Markwardt wrote:
>
>> Timm Weitkamp <dont.try@this.address> writes:
>>> I am having an annoying problem with FINDFILE on a Sunblade with IDL 6.0
>>> (version = { sparc sunos unix Solaris 6.0 Jun 27 2003 64 64}). I run an
>>> IDL program that runs fine on other machines (PCs running Linux) and used
>>> to work on this Sunblade too, and now it stops with an error message at a
>>> call to FINDFILE. The call is alright, the problem is that FINDFILE seems
>>> to spawn an "ls" or something, because I get the same error when I spawn
>>> "ls" by hand:
>>>
>>> IDL> $ls
>>> % Error managing child process.
>>> Not enough space
>>>
>>> What is this? Bug? Feature? Memory problem? It actually occurs with *any*
>>> spawned command (I tried "cat" or even non-existent commands with the same
>>> result). Can I circumvent this somehow? Any help appreciated. Here's the
>>> system info:
Timm,
For what it's worth, under VMS, this error typically means that you've
run out
of disk quota, e.g. IDL is trying to create a file somewhere, and you
either don't have the physical disk space available or as Craig
suggested, you don't
have the correct permissions. Same diff I suppose.
Andrew (Who's soon to be de-VMS'd, and dragged kicking and screaming
into the
Linux universe...)
|
|
|
|
| Re: % FINDFILE: Error managing child process. [message #40234 is a reply to message #40226] |
Sun, 25 July 2004 11:23 |
R.Bauer
Messages: 1424
Registered: November 1998
|
Senior Member |
|
|
Timm Weitkamp wrote:
> On 24.07.04 at 21:21 -0500, Craig Markwardt wrote:
>
>> Timm Weitkamp <dont.try@this.address> writes:
>>> I am having an annoying problem with FINDFILE on a Sunblade with IDL
>>> 6.0 (version = { sparc sunos unix Solaris 6.0 Jun 27 2003 64 64}). I
>>> run an IDL program that runs fine on other machines (PCs running Linux)
>>> and used to work on this Sunblade too, and now it stops with an error
>>> message at a call to FINDFILE. The call is alright, the problem is that
>>> FINDFILE seems to spawn an "ls" or something, because I get the same
>>> error when I spawn "ls" by hand:
>>>
>>> IDL> $ls
>>> % Error managing child process.
>>> Not enough space
>>>
>>> What is this? Bug? Feature? Memory problem? It actually occurs with
>>> *any* spawned command (I tried "cat" or even non-existent commands with
>>> the same result). Can I circumvent this somehow? Any help appreciated.
>>> Here's the system info:
>>
>> I seem to recall a friend having a problem like this. Somehow, by
>> accident, his "/tmp" scratch area was non-writeable, except by root.
>> Once we made it writeable, then all sorts of things started to work
>> again. We speculated that somehow IDL was attempting to make a
>> temporary file, which it couldn't do when permissions were wrong.
>
> Thank you for this hint, Craig, which I will keep in mind. At first
> glance, though, it doesn't exactly seem to be that (/tmp/ is writable).
> Another thing is that I now tried with different IDL releases (5.4, 5.6,
> and 6.0). The problem occurs with 5.6 and 6.0, but not with 5.4.
> Unfortunately my code relies on some functionality introduced in 5.6.
>
> Also, it only occurs after allocating a considerable bunch of memory for
> an array (something like 4 GB out of the total of 6 GB of RAM available).
> But once the bug strikes, even freeing memory with DELVAR or TEMPORARY
> does not help anymore.
>
> I worked on other Sunblades before (albeit with more memory available) and
> never ran into this. May have to contact RSI.
>
> Cheers,
> Timm
>
Dear Timm
findfile belongs to the obsolete routines. It was replaced by file_search.
Did you see the same problems by this one?
Reimar
--
Forschungszentrum Juelich
email: R.Bauer@fz-juelich.de
http://www.fz-juelich.de/icg/icg-i/
============================================================ ======
a IDL library at ForschungsZentrum Juelich
http://www.fz-juelich.de/icg/icg-i/idl_icglib/idl_lib_intro. html
|
|
|
|
| Re: % FINDFILE: Error managing child process. [message #40235 is a reply to message #40226] |
Sun, 25 July 2004 05:46 |
Timm Weitkamp
Messages: 66
Registered: August 2002
|
Member |
|
|
On 24.07.04 at 21:21 -0500, Craig Markwardt wrote:
> Timm Weitkamp <dont.try@this.address> writes:
>> I am having an annoying problem with FINDFILE on a Sunblade with IDL 6.0
>> (version = { sparc sunos unix Solaris 6.0 Jun 27 2003 64 64}). I run an
>> IDL program that runs fine on other machines (PCs running Linux) and used
>> to work on this Sunblade too, and now it stops with an error message at a
>> call to FINDFILE. The call is alright, the problem is that FINDFILE seems
>> to spawn an "ls" or something, because I get the same error when I spawn
>> "ls" by hand:
>>
>> IDL> $ls
>> % Error managing child process.
>> Not enough space
>>
>> What is this? Bug? Feature? Memory problem? It actually occurs with *any*
>> spawned command (I tried "cat" or even non-existent commands with the same
>> result). Can I circumvent this somehow? Any help appreciated. Here's the
>> system info:
>
> I seem to recall a friend having a problem like this. Somehow, by
> accident, his "/tmp" scratch area was non-writeable, except by root.
> Once we made it writeable, then all sorts of things started to work
> again. We speculated that somehow IDL was attempting to make a
> temporary file, which it couldn't do when permissions were wrong.
Thank you for this hint, Craig, which I will keep in mind. At first
glance, though, it doesn't exactly seem to be that (/tmp/ is writable).
Another thing is that I now tried with different IDL releases (5.4, 5.6,
and 6.0). The problem occurs with 5.6 and 6.0, but not with 5.4.
Unfortunately my code relies on some functionality introduced in 5.6.
Also, it only occurs after allocating a considerable bunch of memory for
an array (something like 4 GB out of the total of 6 GB of RAM available).
But once the bug strikes, even freeing memory with DELVAR or TEMPORARY
does not help anymore.
I worked on other Sunblades before (albeit with more memory available) and
never ran into this. May have to contact RSI.
Cheers,
Timm
--
Timm Weitkamp
Paul Scherrer Institut, 5232 Villigen PSI, Switzerland
|
|
|
|
| Re: % FINDFILE: Error managing child process. [message #40237 is a reply to message #40226] |
Sat, 24 July 2004 19:21 |
Craig Markwardt
Messages: 1869
Registered: November 1996
|
Senior Member |
|
|
Timm Weitkamp <dont.try@this.address> writes:
> I am having an annoying problem with FINDFILE on a Sunblade with IDL 6.0
> (version = { sparc sunos unix Solaris 6.0 Jun 27 2003 64 64}). I run an
> IDL program that runs fine on other machines (PCs running Linux) and used
> to work on this Sunblade too, and now it stops with an error message at a
> call to FINDFILE. The call is alright, the problem is that FINDFILE seems
> to spawn an "ls" or something, because I get the same error when I spawn
> "ls" by hand:
>
> IDL> $ls
> % Error managing child process.
> Not enough space
>
> What is this? Bug? Feature? Memory problem? It actually occurs with *any*
> spawned command (I tried "cat" or even non-existent commands with the same
> result). Can I circumvent this somehow? Any help appreciated. Here's the
> system info:
I seem to recall a friend having a problem like this. Somehow, by
accident, his "/tmp" scratch area was non-writeable, except by root.
Once we made it writeable, then all sorts of things started to work
again. We speculated that somehow IDL was attempting to make a
temporary file, which it couldn't do when permissions were wrong.
Good luck,
Craig
--
------------------------------------------------------------ --------------
Craig B. Markwardt, Ph.D. EMAIL: craigmnet@REMOVEcow.physics.wisc.edu
Astrophysics, IDL, Finance, Derivatives | Remove "net" for better response
------------------------------------------------------------ --------------
|
|
|
|
| Re: % FINDFILE: Error managing child process. [message #40298 is a reply to message #40226] |
Wed, 28 July 2004 01:02 |
Timm Weitkamp
Messages: 66
Registered: August 2002
|
Member |
|
|
Thank you for all info and suggestions. It seems unlikely (though not
impossible) to me that a lack of swap space or other disk space should
cause my problem, as some of you have suggested.
Given that there is plenty of swap space, even quite a bit of RAM left and
that the problem occurs only with 5.6 and higher, but not with 5.4, I tend
to think that it is an internal IDL problem.
I will further investigate this thing when I have more time -- for the
time being I can live with it. Thanks again to all of you.
Timm
--
Timm Weitkamp
Paul Scherrer Institut, 5232 Villigen PSI, Switzerland
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
