[Scilab-users] Issue when compiling Scilab: "Cannot allocate this quantity of memory"
Clément David
clement.david at scilab-enterprises.com
Mon Apr 13 11:16:36 CEST 2015
Hello Andrea,
Thanks for this workaround. However note that any Scilab endianess issue
is a bug. Do not hesitate to report on bugzilla.scilab.org .
Regards,
--
Clément
Le jeudi 09 avril 2015 à 07:26 -0700, Nukles a écrit :
> 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, [hidden email] <[hidden email]> 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, [hidden email] <[hidden email]>
> 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 1504
> stacksize: 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.sce
> stacksize(5000000);
> !--error 42
> A 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/
> 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: 0x10000a096928
>
> Call 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 stack
>
>
> at line 27 of exec file called by :
> exec('modules/functions/scripts/buildmacros/buildmacros.sce',-1)
>
> !--error 999
> Aborting 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] <[hidden
> email]> 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://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.
> NAML
>
>
>
>
>
>
>
>
> ______________________________________________________________________
> View this message in context: Re: Issue when compiling Scilab: "Cannot
> allocate this quantity of memory"
> Sent from the Scilab users - Mailing Lists Archives mailing list
> archive at Nabble.com.
> _______________________________________________
> users mailing list
> users at lists.scilab.org
> http://lists.scilab.org/mailman/listinfo/users
More information about the users
mailing list