C++ still get segmentation fault (core dumped) error after change stack size with setrlimit -

-

i wrote c++ program in ubuntu. in main function, have 2-d array this:

int main() {    unsigned long long int s[11000][100];    // code manipulate s (just initialization)    // ... }

and program failed run. after search web, know size of 2-d array exceeds default stack size in ubuntu 8 mb. tried suggests change stack size automatically in program. added few lines of code:

int main() {    unsigned long long int s[11000][100];    const rlim_t kstacksize = 32 * 1024 * 1024;    struct rlimit rl;    int result;     result = getrlimit(rlimit_stack, &rl);    if (result == 0) {       if (rl.rlim_cur < kstacksize) {          rl.rlim_cur = kstacksize;          result = setrlimit(rlimit_stack, &rl);          if (result != 0) {             printf("error\n");          }    } else {         printf("error\n");    }     // code manipulate s (just initialization)    // ... } // end main

but still got segmentation fault (core dumped) error. checked stack size, size 32 mb, 4 times lager size of 2-d array. try set stack size rlim_infinity, failed again. can me figure out reason , solution? thank much!

given size of block of memory, should instead allocate either new[] or malloc , delete[] or free appropriate. or, if you're using c++, should use std::vector or other heap-allocated container.

the reason still crashing because it's still trying allocate more limit on still-limited stack space, before try adjust it. variables in automatic storage (that is, on stack) allocated before function executes.


Comments

Post a Comment

Popular posts from this blog

c# - How Configure Devart dotConnect for SQLite Code First? -

-
can configure following sample code ? when run following code, error : no entity framework provider found ado.net provider invariant name 'devart.data.sqlite' setting in machine.config <system.data> <dbproviderfactories> <add name="dotconnect sqlite" invariant="devart.data.sqlite" description="devart dotconnect sqlite" type="devart.data.sqlite.sqliteproviderfactory, devart.data.sqlite, version=4.6.287.0, culture=neutral, publickeytoken=09af7300eec23701" /> </dbproviderfactories> </system.data> after add below block code in app.config <?xml version="1.0"?> <configuration>   <configsections> <!-- more information on entity framework configuration, visit http://go.microsoft.com/fwlink/?linkid=237468 --> <section name="entityframework" type="system.data.entity.internal.configfile.entityframeworksection, entit...
Read more

c++ - Clear the memory after returning a vector in a function -

-
i have function processes , stores lot of data in , returns results vector of class. amount of data stored in function tremendous , want clear storage memory of function after finished job. necessary (does function automatically clear memory) or should clear memory function? update: vector<customers> process(char* const *filename, vector<int> id) { vector<customers> list_of_customers; (perform actions) return list_of_customers; } variables defined locally within function automatically released @ end of function scope. destructors objects called, should free memory allocated objects (if objects coded correctly). example of such object std::vector . anything you've allocated new must have corresponding delete release storage. try avoid doing own allocation , use raii instead, i.e. containers or smart pointers.
Read more

erlang - Saving a digraph to mnesia is hindered because of its side-effects -

-
updated the digraph library in erlang implements data type side-effectful. each operation on data type saves new state in ets table -- instead of returning altered version of itself, more common in functional languages. the problem usage perspective, impedes effort store or pass around state in convenient way requiring me first "collect" state before can start juggle around. the closest solution have seen far serializer/deserializer , these have drawback tied current structure of digraphs instead of operating on abstract type -- prevents future proof solution. update pascal pointed out serializer utilizes interface of digraph, , hence eliminates drawback mentioned above. better, albeit still inconvenient, see no better alternative. what recommendation on how store digraphs? should go different data type altogether? thanks. i not sure understand concern. fact digraph stored in ets transparent in user interface, might want chnge either exchange digr...
Read more