[Scilab-users] Issue when compiling Scilab: "Cannot allocate this quantity of memory"
Nukles
nardo85 at gmail.com
Thu Apr 9 16:26:04 CEST 2015
Hi all,
I think I solved the problem: it had to do with the Endian-ness of the
Operating System. I was using RHEL 7.0 Big Endian, not the Little Endian
version as it is on any x86 System.
I compiled Scilab on RHEL 7.1 Little Endian, on both PowerKVM and PowerVM,
and the issue did not show up again.
I assume then that if the OS is Big Endian, the memory allocation functions
won't get the real memory allocated because the Memory is allocated in
another order.
Issue is then more or less solved, as long as you use a Little Endian
Operating System (like SUSE 12 and Ubuntu 14 on POWER)
On 9 March 2015 at 09:43, nardo85 at gmail.com <nardo85 at gmail.com> wrote:
> Hi all, I would like to "bump" this discussion, as I haven't been able to
> move forward after a week, still facing the same problems. Also, I would be
> able to provide remote access to this ppc64 machine if needed.
>
> On 3 March 2015 at 15:02, nardo85 at gmail.com <nardo85 at gmail.com> wrote:
>
>> Hi Clement,
>>
>> Many thanks for your answer!
>>
>> I found those macros and in the meantime I found a little more info too.
>> Maybe that can help to understand the issue; it seems really puzzling.
>>
>> A) The value returned for __LONG_MAX___ , after querying the compiler,
>> is like that:
>>
>>
>>
>> *[root at localhost ~]# gcc -dM -E - < /dev/null |grep __LONG_MAX__#define
>> __LONG_MAX__ 9223372036854775807L*
>> B) The problem shouldn't be the method
>> *get_max_memory_for_scilab_stack(void)*, as I initially thought, because
>> I noticed it is called by *sci_stacksize.c* to verify if the value given
>> as input is out of bounds. If you do, let's say, *stacksize(1)*, it will
>> return:
>>
>>
>>
>>
>>
>>
>> *-->stacksize(1) !--error 1504stacksize: Out of bounds value.
>> Not in [180000,268435454].-->*
>>
>> the value given as the lower bound, is explicitly defined in the class.
>> The value for the upper bound is instead taken from
>> *get_max_memory_for_scilab_stack(void)*, so that method should not be
>> the problem as in this case, it returns an apparently good value.
>>
>> C) The error is generated at compile time when the buildmacros script
>> does *stacksize(5000000)*. The system returns it cannot allocate this
>> stacksize, as it apparently "thinks" the value 5000000 is bigger than the
>> max stacksize, which we have seen from before, it should amount to
>> *268435454*. It checks if 5000000 is lower than
>> get_max_memory_for_scilab_stack() in stackinfo.c (which should be
>> *268435454)*, it understands that it's larger, and prompts out the
>> error. I tried to "trick the system" by eliminating this check in the class
>> stackinfo.c. The compilation in that case fails as it says the stack size
>> has been exceeded: which is another error message.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> *./bin/scilab-cli -ns -noatomsautoload -f
>> modules/functions/scripts/buildmacros/buildmacros.scestacksize(5000000);
>> !--error 42A fatal error has been detected by Scilab.Your instance will
>> probably quit unexpectedly soon.If a graphic feature has been used, this
>> might be caused by the system graphic drivers.Please try to update them and
>> run this feature again.You can report a bug on http://bugzilla.scilab.org/
>> <http://bugzilla.scilab.org/> with:* a sample code which reproduces the
>> issue* the result of [a, b] = getdebuginfo()* the following
>> information:[localhost:10797] Signal: Segmentation fault
>> (11)[localhost:10797] Signal code: Invalid permissions (2)[localhost:10797]
>> Failing at address: 0x10000a096928Call stack: 1: ?
>> ? (?) 2: 0x2c381c
>> <unsfdcopy_>
>> (/root/scilab/scilab-5.5.1/modules/.libs/libscilab-cli.so.0) 3: 0x1f4060
>> <adjuststacksize_>
>> (/root/scilab/scilab-5.5.1/modules/.libs/libscilab-cli.so.0) 4: 0x1805d0
>> < >
>> (/root/scilab/scilab-5.5.1/modules/.libs/libscilab-cli.so.0) 5: 0x180de4
>> <sci_stacksize_>
>> (/root/scilab/scilab-5.5.1/modules/.libs/libscilab-cli.so.0) 6: 0x1ae7ac
>> <callFunctionFromGateway>
>> (/root/scilab/scilab-5.5.1/modules/.libs/libscilab-cli.so.0) 7: 0x18944c
>> <gw_core>
>> (/root/scilab/scilab-5.5.1/modules/.libs/libscilab-cli.so.0) 8: 0x1ae8a0
>> <callinterf_>
>> (/root/scilab/scilab-5.5.1/modules/.libs/libscilab-cli.so.0) 9: 0x1c7d50
>> <scirun_>
>> (/root/scilab/scilab-5.5.1/modules/.libs/libscilab-cli.so.0) 10: 0x1c1220
>> <realmain>
>> (/root/scilab/scilab-5.5.1/modules/.libs/libscilab-cli.so.0) 11: 0x18b4
>> < >
>> (/root/scilab/scilab-5.5.1/.libs/lt-scilab-cli-bin) 12: 0x4454c <
>> > (/lib64/power8/libc.so.6) 13: 0x44774
>> <__libc_start_main> (/lib64/power8/libc.so.6)End of stackat
>> line 27 of exec file called by
>> :exec('modules/functions/scripts/buildmacros/buildmacros.sce',-1)
>> !--error 999Aborting current computation*
>>
>> D) I also tried to trick the system by eliminating the command *stacksize(5000000)
>> *from buildmacros, and the compilation completed successfully. However,
>> when starting *scilab-cli*, there is a startup script which apparently
>> tests the stacksize and displays the error, although scilab keeps working.
>> Wheneven I try however to allocate a stacksize, it displays the error again.
>>
>> E) I modified the class to explicitly declare a value lower than 180'000
>> as the lower bound. I set 1. I tried to do *stacksize(2)*, and it also
>> returned that it cannot allocate this quantity of memory.
>>
>>
>> If you would like to have a closer look, and I would really thank you for
>> that, I think I can arrange for a remote access on my VM, so that you can
>> see directly.
>>
>> Thanks!
>>
>> Andrea
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On 3 March 2015 at 10:25, Clément David-2 [via Scilab / Xcos - Mailing
>> Lists Archives] <ml-node+s994242n4031774h24 at n3.nabble.com> wrote:
>>
>>> Hello (added dev ML),
>>>
>>> Le lundi 02 mars 2015 à 06:01 -0700, Nukles a écrit :
>>> > So my guess is: MAXLONG is not declared, so the function does not
>>> return a
>>> > value (or it returns 0) and therefore the error message is triggered
>>> because
>>> > the stacksize given as input is higher than 0 or NULL or N/A.
>>> >
>>> > My questions are then:
>>> >
>>> > - Why are all lines commented where MAXLONG is defined?
>>>
>>> On my system (Fedora 21 x86_64) the MAXLONG macro is defined at :
>>>
>>> stackinfo.c:35 #define MAXLONG LONG_MAX
>>>
>>> and LONG_MAX comes from limits.h
>>>
>>>
>>> > - Where does MAXLONG originate from? Is it something passed from the
>>> > kernel?
>>> > - How can I solve the problem?
>>>
>>> Well, as we do not have any PPC64 at Scilab I cannot check. Is a VM
>>> available for that platform / distro ?
>>>
>>>
>>> --
>>> Clément
>>>
>>> _______________________________________________
>>> users mailing list
>>> [hidden email] <http:///user/SendEmail.jtp?type=node&node=4031774&i=0>
>>> http://lists.scilab.org/mailman/listinfo/users
>>>
>>>
>>> ------------------------------
>>> If you reply to this email, your message will be added to the
>>> discussion below:
>>>
>>> http://mailinglists.scilab.org/Issue-when-compiling-Scilab-Cannot-allocate-this-quantity-of-memory-tp4031761p4031774.html
>>> To unsubscribe from Issue when compiling Scilab: "Cannot allocate this
>>> quantity of memory", click here
>>> <http://mailinglists.scilab.org/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4031761&code=bmFyZG84NUBnbWFpbC5jb218NDAzMTc2MXwzNDY4NDM1NTY=>
>>> .
>>> NAML
>>> <http://mailinglists.scilab.org/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>>>
>>
>>
>
--
View this message in context: http://mailinglists.scilab.org/Issue-when-compiling-Scilab-Cannot-allocate-this-quantity-of-memory-tp4031761p4032056.html
Sent from the Scilab users - Mailing Lists Archives mailing list archive at Nabble.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.scilab.org/pipermail/users/attachments/20150409/33e4a7c0/attachment.htm>
More information about the users
mailing list