plotting from octave: address space already occupied, fork aborts

Christopher Faylor
Wed Sep 14 15:09:00 GMT 2011

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


Problem reports:
Unsubscribe info:

More information about the Cygwin mailing list