plotting from octave: address space already occupied, fork aborts

plotting from octave: address space already occupied, fork aborts

[Paul]

I am using the 2011-08-29 snapshot at http://cygwin.com/snapshots because
cygwin-1.7.9-1 does not allow me to write to, or create, files on network drives
(http://cygwin.com/packages/cygwin/cygwin-1.7.9-1).

I am using Windows 7 Enterprise 64-bit.

My current problem is using plotting commands from Octave.  It is not a gnuplot
problem because I can plot from gnuplot.  If I plot the simplest thing from
octave [ e.g. plot( 1:10 , 1:10 ) ], I get:

   5 [main] octave-3.4.2 2892 child_info_fork::abort: address space needed by
'max.oct' (004F0000) is already occupied
   error: popen2: process creation failed -- Resource temporarily unavailable
   error: called from:
   error:   /usr/share/octave/3.4.2/m/plot/__gnuplot_open_stream__.m at line 30,
column 44
   error:   /usr/share/octave/3.4.2/m/plot/__gnuplot_drawnow__.m at line 72,
column 19

I already did rebaseall and peflagsall from ash.  I ensured there were no cygwin
processes running, then invoked ash from the DOS command prompt.  I also
rebooted after peflagsall.

What else can I try?


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: plotting from octave: address space already occupied, fork aborts

[Marco atzeri]

On 9/14/2011 4:52 AM, Paul wrote:
> I am using the 2011-08-29 snapshot at http://cygwin.com/snapshots because
> cygwin-1.7.9-1 does not allow me to write to, or create, files on network drives
> (http://cygwin.com/packages/cygwin/cygwin-1.7.9-1).

snapshot is fine.
(1.7.9-1 has a bug that does not allow to plot on any MS system)

>
> I am using Windows 7 Enterprise 64-bit.
>
> My current problem is using plotting commands from Octave.  It is not a gnuplot
> problem because I can plot from gnuplot.  If I plot the simplest thing from
> octave [ e.g. plot( 1:10 , 1:10 ) ], I get:
>
>     5 [main] octave-3.4.2 2892 child_info_fork::abort: address space needed by
> 'max.oct' (004F0000) is already occupied
>     error: popen2: process creation failed -- Resource temporarily unavailable
>     error: called from:
>     error:   /usr/share/octave/3.4.2/m/plot/__gnuplot_open_stream__.m at line 30,
> column 44
>     error:   /usr/share/octave/3.4.2/m/plot/__gnuplot_drawnow__.m at line 72,
> column 19
>
> I already did rebaseall and peflagsall from ash.  I ensured there were no cygwin
> processes running, then invoked ash from the DOS command prompt.  I also
> rebooted after peflagsall.
>
> What else can I try?
>
Hi Paul,
your problem is a new one :-(

max.oct is a dll of octave, and its base address is not 004F0000

$ objdump -p /lib/octave/3.4.2/oct/i686-pc-cygwin/max.oct |grep ImageBase

ImageBase               686c0000

I guess that another dll is loaded at 686c0000, so max.oct
is loaded too near at 004000000, the base address of any exe

$ objdump -p /bin/gnuplot.exe |grep ImageBase
ImageBase               00400000

$ objdump -p /bin/octave-3.4.2.exe |grep ImageBase
ImageBase               00400000

So when octave fork gnuplot, gnuplot take that address space
and max.oct can not be loaded at the previous 004F0000.

peflagsall is not aware that .oct are also dll, so you could try with

$ peflagsall -s 'exe|dll|so|oct'



Regards
Marco




--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: plotting from octave: address space already occupied, fork aborts

[Paul]

Marco atzeri <marco.atzeri <at> gmail.com> writes:
>On 9/14/2011 4:52 AM, Paul wrote:
>> I am using the 2011-08-29 snapshot at http://cygwin.com/snapshots
>> because cygwin-1.7.9-1 does not allow me to write to, or create,
>> files on network drives
>> (http://cygwin.com/packages/cygwin/cygwin-1.7.9-1).
> 
> snapshot is fine.
> (1.7.9-1 has a bug that does not allow to plot on any MS system)
> 
>>
>> I am using Windows 7 Enterprise 64-bit.
>>
>> My current problem is using plotting commands from Octave.  It is
>> not a gnuplot problem because I can plot from gnuplot.  If I plot
>> the simplest thing from octave [ e.g. plot( 1:10 , 1:10 ) ], I get:
>>
>>     5 [main] octave-3.4.2 2892 child_info_fork::abort: address
>>       space needed by 'max.oct' (004F0000) is already occupied
>>     error: popen2: process creation failed -- Resource temporarily
>>       unavailable
>>     error: called from:
>>     error: /usr/share/octave/3.4.2/m/plot/__gnuplot_open_stream__.m
>>       at line 30, column 44
>>     error: /usr/share/octave/3.4.2/m/plot/__gnuplot_drawnow__.m
>>       at line 72, column 19
>>
>> I already did rebaseall and peflagsall from ash.  I ensured there
>> were no cygwin processes running, then invoked ash from the DOS
>> command prompt.  I also rebooted after peflagsall.
>>
>> What else can I try?
>
>Hi Paul,
>your problem is a new one 
>
>max.oct is a dll of octave, and its base address is not 004F0000
>
>$ objdump -p /lib/octave/3.4.2/oct/i686-pc-cygwin/max.oct |grep ImageBase
>
>ImageBase               686c0000
>
>I guess that another dll is loaded at 686c0000, so max.oct
>is loaded too near at 004000000, the base address of any exe
>
>$ objdump -p /bin/gnuplot.exe |grep ImageBase
>ImageBase               00400000
>
>$ objdump -p /bin/octave-3.4.2.exe |grep ImageBase
>ImageBase               00400000
>
>So when octave fork gnuplot, gnuplot take that address space
>and max.oct can not be loaded at the previous 004F0000.
>
>peflagsall is not aware that .oct are also dll, so you could try with
>
>$ peflagsall -s 'exe|dll|so|oct'

Thanks, Marco.

I just tried that...the command completed in a split second i.e.
immediately.  I rebooted, started octave in an xterm, and issued the
command "plot(1:5,1:5)".  The error is still present, but seems to
have shifted to another oct/dll:

   octave:1> plot(1:5,1:5)
         5 [main] octave-3.4.2 3804 child_info_fork::abort: address
         space needed by 'cellfun.oct' (00340000) is already occupied
   error: popen2: process creation failed -- Resource temporarily unavailable
   error: called from:
   error:   /usr/share/octave/3.4.2/m/plot/__gnuplot_open_stream__.m
      at line 30, column 44
   error:   /usr/share/octave/3.4.2/m/plot/__gnuplot_drawnow__.m at
      line 72, column 19

I'd welcome any further suggestions.


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: plotting from octave: address space already occupied, fork aborts

[Ryan Johnson]

On 14/09/2011 1:43 AM, Marco atzeri wrote:
> On 9/14/2011 4:52 AM, Paul wrote:
>> I am using the 2011-08-29 snapshot at http://cygwin.com/snapshots 
>> because
>> cygwin-1.7.9-1 does not allow me to write to, or create, files on 
>> network drives
>> (http://cygwin.com/packages/cygwin/cygwin-1.7.9-1).
>
> snapshot is fine.
> (1.7.9-1 has a bug that does not allow to plot on any MS system)
>
>>
>> I am using Windows 7 Enterprise 64-bit.
>>
>> My current problem is using plotting commands from Octave.  It is not 
>> a gnuplot
>> problem because I can plot from gnuplot.  If I plot the simplest 
>> thing from
>> octave [ e.g. plot( 1:10 , 1:10 ) ], I get:
>>
>>     5 [main] octave-3.4.2 2892 child_info_fork::abort: address space 
>> needed by
>> 'max.oct' (004F0000) is already occupied
>>     error: popen2: process creation failed -- Resource temporarily 
>> unavailable
>>     error: called from:
>>     error:   /usr/share/octave/3.4.2/m/plot/__gnuplot_open_stream__.m 
>> at line 30,
>> column 44
>>     error:   /usr/share/octave/3.4.2/m/plot/__gnuplot_drawnow__.m at 
>> line 72,
>> column 19
>>
>> I already did rebaseall and peflagsall from ash.  I ensured there 
>> were no cygwin
>> processes running, then invoked ash from the DOS command prompt.  I also
>> rebooted after peflagsall.
>>
>> What else can I try?
>>
> Hi Paul,
> your problem is a new one :-(
>
> max.oct is a dll of octave, and its base address is not 004F0000
>
> $ objdump -p /lib/octave/3.4.2/oct/i686-pc-cygwin/max.oct |grep ImageBase
>
> ImageBase               686c0000
>
> I guess that another dll is loaded at 686c0000, so max.oct
> is loaded too near at 004000000, the base address of any exe
>
> $ objdump -p /bin/gnuplot.exe |grep ImageBase
> ImageBase               00400000
>
> $ objdump -p /bin/octave-3.4.2.exe |grep ImageBase
> ImageBase               00400000
>
> So when octave fork gnuplot, gnuplot take that address space
> and max.oct can not be loaded at the previous 004F0000.
>
> peflagsall is not aware that .oct are also dll, so you could try with
>
> $ peflagsall -s 'exe|dll|so|oct'
Wouldn't rebaseall need similar treatment? My understanding from Corinna 
is that peflagsall is not particularly helpful (though not harmful either).

As for the rebase error, it's not new, unfortunately. Rebasing helps 
(especially if it picks up .oct files), but that message means that 
Windows ASLR dropped "something" on the child (statically-linked dll, 
thread stack, heap, etc.) in a place that a dynamically-loaded dll 
occupied in the parent. Cygwin has exactly zero control over such 
address space clobbers, though sometimes restarting the offending parent 
a few times produces a process with a less vulnerable address space layout.

There is some evidence [1] that flagging cygwin .exe as large address 
aware and rebasing all libraries (excepting cygwin1.dll?) into high 
addresses makes it immune to ASLR problems (the latter apparently only 
mucks with low addresses), but I don't know if anybody has ever tested 
it on octave. Emacs broke in nasty ways when marked large address-aware 
[2], though the problem has since been fixed [3].

[1] http://cygwin.com/ml/cygwin-developers/2011-06/msg00002.html
[2] http://cygwin.com/ml/cygwin/2011-08/msg00153.html
[3] http://cygwin.com/ml/cygwin/2011-08/msg00312.html

Ryan


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: plotting from octave: address space already occupied, fork aborts

[Marco atzeri]

On 9/14/2011 2:22 PM, Ryan Johnson wrote:
> On 14/09/2011 1:43 AM, Marco atzeri wrote:
>> Hi Paul,
>> your problem is a new one :-(
>>
>> max.oct is a dll of octave, and its base address is not 004F0000
>>
>> $ objdump -p /lib/octave/3.4.2/oct/i686-pc-cygwin/max.oct |grep ImageBase
>>
>> ImageBase 686c0000
>>
>> I guess that another dll is loaded at 686c0000, so max.oct
>> is loaded too near at 004000000, the base address of any exe
>>
>> $ objdump -p /bin/gnuplot.exe |grep ImageBase
>> ImageBase 00400000
>>
>> $ objdump -p /bin/octave-3.4.2.exe |grep ImageBase
>> ImageBase 00400000
>>
>> So when octave fork gnuplot, gnuplot take that address space
>> and max.oct can not be loaded at the previous 004F0000.
>>
>> peflagsall is not aware that .oct are also dll, so you could try with
>>
>> $ peflagsall -s 'exe|dll|so|oct'
> Wouldn't rebaseall need similar treatment? My understanding from Corinna
> is that peflagsall is not particularly helpful (though not harmful either).

Hi Ryan,
PEBKC on this side.
I was thinking of rebaseall and writing of peflagsall.

The right command should be:

$ rebaseall -s 'dll|so|oct'

Regards
Marco

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: plotting from octave: address space already occupied, fork aborts

[Christopher Faylor]

On Wed, Sep 14, 2011 at 02:33:26PM +0200, Marco atzeri wrote:
>On 9/14/2011 2:22 PM, Ryan Johnson wrote:
>> On 14/09/2011 1:43 AM, Marco atzeri wrote:
>>> Hi Paul,
>>> your problem is a new one :-(
>>>
>>> max.oct is a dll of octave, and its base address is not 004F0000
>>>
>>> $ objdump -p /lib/octave/3.4.2/oct/i686-pc-cygwin/max.oct |grep ImageBase
>>>
>>> ImageBase 686c0000
>>>
>>> I guess that another dll is loaded at 686c0000, so max.oct
>>> is loaded too near at 004000000, the base address of any exe
>>>
>>> $ objdump -p /bin/gnuplot.exe |grep ImageBase
>>> ImageBase 00400000
>>>
>>> $ objdump -p /bin/octave-3.4.2.exe |grep ImageBase
>>> ImageBase 00400000
>>>
>>> So when octave fork gnuplot, gnuplot take that address space
>>> and max.oct can not be loaded at the previous 004F0000.
>>>
>>> peflagsall is not aware that .oct are also dll, so you could try with
>>>
>>> $ peflagsall -s 'exe|dll|so|oct'
>> Wouldn't rebaseall need similar treatment? My understanding from Corinna
>> is that peflagsall is not particularly helpful (though not harmful either).
>
>Hi Ryan,
>PEBKC on this side.
>I was thinking of rebaseall and writing of peflagsall.
>
>The right command should be:
>
>$ rebaseall -s 'dll|so|oct'

Why do we need to add an arbitrary new extension here?  Why isn't octave
using "dll"?  "oct" is certainly not a standard extension for a shared
library.

cgf

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: plotting from octave: address space already occupied, fork aborts

[Paul]

Marco atzeri <marco.atzeri <at> gmail.com> writes:
>On 9/14/2011 2:22 PM, Ryan Johnson wrote:
>> On 14/09/2011 1:43 AM, Marco atzeri wrote:
>>> Hi Paul,
>>> your problem is a new one 
>>>
>>> max.oct is a dll of octave, and its base address is not 004F0000
>>>
>>> $ objdump -p /lib/octave/3.4.2/oct/i686-pc-cygwin/max.oct |grep ImageBase
>>>
>>> ImageBase 686c0000
>>>
>>> I guess that another dll is loaded at 686c0000, so max.oct
>>> is loaded too near at 004000000, the base address of any exe
>>>
>>> $ objdump -p /bin/gnuplot.exe |grep ImageBase
>>> ImageBase 00400000
>>>
>>> $ objdump -p /bin/octave-3.4.2.exe |grep ImageBase
>>> ImageBase 00400000
>>>
>>> So when octave fork gnuplot, gnuplot take that address space
>>> and max.oct can not be loaded at the previous 004F0000.
>>>
>>> peflagsall is not aware that .oct are also dll, so you could try with
>>>
>>> $ peflagsall -s 'exe|dll|so|oct'
>> Wouldn't rebaseall need similar treatment? My understanding from Corinna
>> is that peflagsall is not particularly helpful (though not harmful either).
> 
> Hi Ryan,
> PEBKC on this side.
> I was thinking of rebaseall and writing of peflagsall.
> 
> The right command should be:
> 
> $ rebaseall -s 'dll|so|oct'

Thanks again, Marco.  Unfortunately, still no joy after redoing you
rebaseall & peflagsall statements and rebooting.  I got the same error
as before:

octave:1> plot(1:5,1:5)
      9 [main] octave-3.4.2 5952 child_info_fork::abort: address space needed by
      'cellfun.oct' (00570000) is already occupied
error: popen2: process creation failed -- Resource temporarily unavailable
error: called from:
error: /usr/share/octave/3.4.2/m/plot/__gnuplot_open_stream__.m at line 30,
       column 44
error: /usr/share/octave/3.4.2/m/plot/__gnuplot_drawnow__.m at
       line 72, column 19


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: plotting from octave: address space already occupied, fork aborts

[David Rothenberger]

On 9/14/2011 5:22 AM, Ryan Johnson wrote:
> There is some evidence [1] that flagging cygwin .exe as large address
> aware and rebasing all libraries (excepting cygwin1.dll?) into high
> addresses makes it immune to ASLR problems (the latter apparently only
> mucks with low addresses), but I don't know if anybody has ever tested
> it on octave. Emacs broke in nasty ways when marked large address-aware
> [2], though the problem has since been fixed [3].
> 
> [1] http://cygwin.com/ml/cygwin-developers/2011-06/msg00002.html
> [2] http://cygwin.com/ml/cygwin/2011-08/msg00153.html
> [3] http://cygwin.com/ml/cygwin/2011-08/msg00312.html

While it was true that DLLs could be rebased above 0x80000000, this is
no longer true [1]. The Cygwin DLL uses the high addresses for the heap
now. Still, marking all .exe files as large-address aware does help,
since it allows the heap to go into high addresses, leaving more room
for the DLLs.

[1] http://cygwin.com/ml/cygwin/2011-08/msg00066.html

-- 
David Rothenberger  ----  daveroth@acm.org

Creditor, n.:
        A man who has a better memory than a debtor.

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: plotting from octave: address space already occupied, fork aborts

[Marco atzeri]

On 9/14/2011 5:02 PM, Christopher Faylor wrote:

>
> Why do we need to add an arbitrary new extension here?  Why isn't octave
> using "dll"?  "oct" is certainly not a standard extension for a shared
> library.
>
> cgf

octave is using .oct on all platforms including linux

upstream choice, no specific difference for cygwin

Regards
Marco

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: plotting from octave: address space already occupied, fork aborts

[Marco atzeri]

On 9/14/2011 5:33 PM, Paul wrote:
> Marco atzeri<marco.atzeri<at>  gmail.com>  writes:

>> The right command should be:
>>
>> $ rebaseall -s 'dll|so|oct'
>
> Thanks again, Marco.  Unfortunately, still no joy after redoing you
> rebaseall&  peflagsall statements and rebooting.  I got the same error
> as before:
>
> octave:1>  plot(1:5,1:5)
>        9 [main] octave-3.4.2 5952 child_info_fork::abort: address space needed by
>        'cellfun.oct' (00570000) is already occupied
> error: popen2: process creation failed -- Resource temporarily unavailable
> error: called from:
> error: /usr/share/octave/3.4.2/m/plot/__gnuplot_open_stream__.m at line 30,
>         column 44
> error: /usr/share/octave/3.4.2/m/plot/__gnuplot_drawnow__.m at
>         line 72, column 19
>
>
> --

I suspect your Windows 7 Enterprise 64-bit is using more space
than rebaseall and cygwin expects.

After the plot error could you check the octave PID with
ps and attach a copy of

/proc/OCTAVE_PID/maps
file ?


It should give us an idea of unavailable address space on your system
due to the MS system and other programs dll's.

Regards
Marco


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: plotting from octave: address space already occupied, fork aborts

[Paul]

Marco atzeri <marco.atzeri <at> gmail.com> writes:
>On 9/14/2011 5:33 PM, Paul wrote:
>> Marco atzeri<marco.atzeri<at>  gmail.com>  writes:
>
>>> The right command should be:
>>>
>>> $ rebaseall -s 'dll|so|oct'
>>
>> Thanks again, Marco.  Unfortunately, still no joy after redoing you
>> rebaseall&  peflagsall statements and rebooting.

      <...snip...>

> 
> I suspect your Windows 7 Enterprise 64-bit is using more space
> than rebaseall and cygwin expects.
> 
> After the plot error could you check the octave PID with
> ps and attach a copy of
> 
> /proc/OCTAVE_PID/maps
> file ?
> 
> It should give us an idea of unavailable address space on your system
> due to the MS system and other programs dll's.

I made a mistake, it's actually Windows 7 Enterprise 32-bit.

The workplace has an atmosphere of vigilence toward sharing info about
work related assets in the open.  I will try to duplicate the problem
at home and post the specified details.

Thanks.


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: plotting from octave: address space already occupied, fork aborts

[Christopher Faylor]

On Wed, Sep 14, 2011 at 11:02:36PM +0200, Marco atzeri wrote:
>On 9/14/2011 5:02 PM, Christopher Faylor wrote:
>>Why do we need to add an arbitrary new extension here?  Why isn't
>>octave using "dll"?  "oct" is certainly not a standard extension for a
>>shared library.
>
>octave is using .oct on all platforms including linux
>
>upstream choice, no specific difference for cygwin

Maybe they should be called ".dll" on Cygwin then.

Either that or we need to come up with some way for packages to register
their idiosyncratic shared library extensions with rebaseall.

cgf

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: plotting from octave: address space already occupied, fork aborts

[Paul]

Marco atzeri <marco.atzeri <at> gmail.com> writes:
>On 9/14/2011 5:33 PM, Paul wrote:
>> Marco atzeri<marco.atzeri<at>  gmail.com>  writes:
>
>>> The right command should be:
>>>
>>> $ rebaseall -s 'dll|so|oct'
>>
>> Thanks again, Marco.  Unfortunately, still no joy after redoing you
>> rebaseall&  peflagsall statements and rebooting.

      <...snip...>

> 
> I suspect your Windows 7 Enterprise 64-bit is using more space
> than rebaseall and cygwin expects.
> 
> After the plot error could you check the octave PID with
> ps and attach a copy of
> 
> /proc/OCTAVE_PID/maps
> file ?
> 
> It should give us an idea of unavailable address space on your system
> due to the MS system and other programs dll's.

I made a mistake, it's actually Windows 7 Enterprise 32-bit.

The workplace has an atmosphere of vigilence toward sharing info about
work related assets in the open.  I will try to duplicate the problem
at home and post the specified details.

   <...some time later...>

Unfortunately, duplicating it at home is a no-go.  I am running into a
different problem between octave and gnuplot on Windows 7 Professional
64-bit.  The problem seems to be accurately captured by someone else's
account http://savannah.gnu.org/bugs/?33291 .

I'm going to treat octave as a strictly nongraphical application for
the time being.

Thanks again.


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: plotting from octave: address space already occupied, fork aborts

[Marco atzeri]

On 9/15/2011 4:28 AM, Paul wrote:
> Marco atzeri<marco.atzeri<at>  gmail.com>  writes:
>> On 9/14/2011 5:33 PM, Paul wrote:
>>> Marco atzeri<marco.atzeri<at>   gmail.com>   writes:
>>
>>>> The right command should be:
>>>>
>>>> $ rebaseall -s 'dll|so|oct'
>>>
>>> Thanks again, Marco.  Unfortunately, still no joy after redoing you
>>> rebaseall&   peflagsall statements and rebooting.
>
>        <...snip...>
>
>>
>> I suspect your Windows 7 Enterprise 64-bit is using more space
>> than rebaseall and cygwin expects.
>>
>> After the plot error could you check the octave PID with
>> ps and attach a copy of
>>
>> /proc/OCTAVE_PID/maps
>> file ?
>>
>> It should give us an idea of unavailable address space on your system
>> due to the MS system and other programs dll's.
>
> I made a mistake, it's actually Windows 7 Enterprise 32-bit.
>
> The workplace has an atmosphere of vigilence toward sharing info about
> work related assets in the open.  I will try to duplicate the problem
> at home and post the specified details.
>
>     <...some time later...>
>
> Unfortunately, duplicating it at home is a no-go.  I am running into a
> different problem between octave and gnuplot on Windows 7 Professional
> 64-bit.  The problem seems to be accurately captured by someone else's
> account http://savannah.gnu.org/bugs/?33291 .

that problem should be solved using a cygwin snapshot dll
instead of 1.7.9-1 one.

I should look in all the bug reports reporting cygwin as "OS", thank
for the link.

>
> I'm going to treat octave as a strictly nongraphical application for
> the time being.

you can try to use the fltk plotting interface instead of gnuplot
default one:

   graphics_toolkit("fltk")
   x=1:10;
   plot(x,x)

Be aware that the octave "print" command does not work with fltk,
but you should be able to make a windows "print screen copy".

>
> Thanks again.

Regards
Marco


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: plotting from octave: address space already occupied, fork aborts

[Paul]

Marco atzeri <marco.atzeri <at| gmail.com| writes:
|On 9/15/2011 4:28 AM, Paul wrote:
|| Marco atzeri<marco.atzeri<at|  gmail.com|  writes:
||| I suspect your Windows 7 Enterprise 64-bit is using more space
||| than rebaseall and cygwin expects.
|||
||| After the plot error could you check the octave PID with
||| ps and attach a copy of
|||
||| /proc/OCTAVE_PID/maps
||| file ?
|||
||| It should give us an idea of unavailable address space on your system
||| due to the MS system and other programs dll's.
||
|| I made a mistake, it's actually Windows 7 Enterprise 32-bit.
||
|| The workplace has an atmosphere of vigilence toward sharing info about
|| work related assets in the open.  I will try to duplicate the problem
|| at home and post the specified details.
  
       <...some time later...>
  
|| Unfortunately, duplicating it at home is a no-go.  I am running into a
|| different problem between octave and gnuplot on Windows 7 Professional
|| 64-bit.  The problem seems to be accurately captured by someone else's
|| account http://savannah.gnu.org/bugs/?33291 .
| 
| that problem should be solved using a cygwin snapshot dll
| instead of 1.7.9-1 one.

Oh, yes....I didn't use a snapshot at home because I didn't have to
deal with the issue of creating, or writing to, network files.

| I should look in all the bug reports reporting cygwin as "OS", thank
| for the link.
| 
|| I'm going to treat octave as a strictly nongraphical application for
|| the time being.
| 
| you can try to use the fltk plotting interface instead of gnuplot
| default one:
| 
|    graphics_toolkit("fltk")
|    x=1:10;
|    plot(x,x)
| 
| Be aware that the octave "print" command does not work with fltk,
| but you should be able to make a windows "print screen copy".

As it turns out, I was able to access Matlab at work today (that's
where I really need the app).  Your solution is great for future
reference, since I won't always have access to the floating license.

Thanks!


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple