[Scilab-users] Issue when compiling Scilab: "Cannot allocate this quantity of memory"
Nukles
nardo85 at gmail.com
Mon Mar 9 09:44:39 CET 2015
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-tp4031761p4031832.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/20150309/fd035557/attachment.htm>
More information about the users
mailing list