ср, 21 окт. 2020 г. в 15:23, David Matthews <david.matth...@prolingua.co.uk>: > > On 21/10/2020 07:20, Kostirya wrote: > > But now the 3G memory is not enough to build the git version of polyml: > > > > cp ./imports/polymli386.txt polytemp.txt > > ./polyimport polytemp.txt -I . < ./exportPoly.sml > > > > Unable to create the initial thread - insufficient memory > > This appears to be a problem with allocating memory for the stack. The > call to mmap is failing with EINVAL but I can't see why. It's line 407 > in libpolyml/osmemunix.cpp which adds MAP_STACK to the arguments. This > is necessary for OpenBSD which segfaults if the stack is not allocated > with MAP_STACK but commenting it out in FreeBSD seems to solve the problem. > > David
I asked in FreeBSD mail list and got got an answer: > kdump with MAP_STACK. > > 87183 polyimport CALL > mmap(0,0x1000,0x3<PROT_READ|PROT_WRITE>,0x1402<MAP_PRIVATE|MAP_STACK|MAP_ANON>,0xffffffff,0,0) > 87183 polyimport RET mmap -1 errno 22 Invalid argument So it is anything but 'insufficient memory' (I suspected ENOMEM). EINVAL there is because sysctl security.bsd.stack_guard_page default value is 1, which means that at least one page of the stack is reserved as guard. Kernel does not allow to map stack that would have no data pages (all pages are guard). Your mapping request is for one page, and one page is due to guard, so you get EINVAL. Generally MAP_STACK is magic and requires caller to know what it does. _______________________________________________ polyml mailing list polyml@inf.ed.ac.uk http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
