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
