Mail Archives: cygwin/2011/09/14/08:23:53
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
- Raw text -