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@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 > [email protected] > http://lists.scilab.org/mailman/listinfo/users _______________________________________________ users mailing list [email protected] http://lists.scilab.org/mailman/listinfo/users
