Running Poly/ML 5.4 on a 64-bit Linux machine with 16 GB of physical RAM, I see unexpected St9bad_alloc exceptions when I use ulimit -v with limits near 8 GB/4 GB/2 GB/1 GB. For instance,
$ uname -a Linux weber 2.6.34.6-54.fc13.x86_64 #1 SMP Sun Sep 5 17:16:27 UTC 2010 x86_64 x86_64 x86_64 GNU/Linux
$ poly -v Poly/ML 5.4 Release RTS version: X86_64-5.4.0
$ ulimit -v 8388608
$ poly terminate called after throwing an instance of 'St9bad_alloc' what(): std::bad_alloc Aborted (core dumped)
$ ulimit -v 4321280
$ poly terminate called after throwing an instance of 'St9bad_alloc' what(): std::bad_alloc Aborted (core dumped)
$ ulimit -v 2170880
$ poly terminate called after throwing an instance of 'St9bad_alloc' what(): std::bad_alloc Aborted (core dumped)
$ ulimit -v 1146880
$ poly terminate called after throwing an instance of 'St9bad_alloc' what(): std::bad_alloc Aborted (core dumped)
The same problem is present in Poly/ML 5.3. Any help would be appreciated.
Regards, Tjark
I haven't been able to reproduce this but I don't have a machine with that much memory. I suspect that what is happening is that poly is trying to allocate as much memory as possible for its own heap and not leaving anything spare for the C++ heap. This is something I'm planning to address in the next release but in the meantime have you tried setting the heap size with the -H option? Try setting it to half the size of the virtual memory. I take it that your crashes happen immediately on start-up.
Regards, David
Tjark Weber wrote:
Running Poly/ML 5.4 on a 64-bit Linux machine with 16 GB of physical RAM, I see unexpected St9bad_alloc exceptions when I use ulimit -v with limits near 8 GB/4 GB/2 GB/1 GB. For instance,
$ uname -a Linux weber 2.6.34.6-54.fc13.x86_64 #1 SMP Sun Sep 5 17:16:27 UTC 2010 x86_64 x86_64 x86_64 GNU/Linux
$ poly -v Poly/ML 5.4 Release RTS version: X86_64-5.4.0
$ ulimit -v 8388608
$ poly terminate called after throwing an instance of 'St9bad_alloc' what(): std::bad_alloc Aborted (core dumped)
$ ulimit -v 4321280
$ poly terminate called after throwing an instance of 'St9bad_alloc' what(): std::bad_alloc Aborted (core dumped)
$ ulimit -v 2170880
$ poly terminate called after throwing an instance of 'St9bad_alloc' what(): std::bad_alloc Aborted (core dumped)
$ ulimit -v 1146880
$ poly terminate called after throwing an instance of 'St9bad_alloc' what(): std::bad_alloc Aborted (core dumped)
The same problem is present in Poly/ML 5.3. Any help would be appreciated.
Regards, Tjark
polyml mailing list polyml@inf.ed.ac.uk http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
On Thu, 2010-09-16 at 12:02 +0100, David Matthews wrote:
[...] in the meantime have you tried setting the heap size with the -H option? Try setting it to half the size of the virtual memory.
That allows poly to start up normally. -H values well above half the size of the virtual memory also work, as long as they are below the size of the virtual memory (less some relatively small safety margin).
I take it that your crashes happen immediately on start-up.
That's right. Also, poly -v crashes in the same way, without printing any version information.
I'll be happy to test a fix/the next release on my machine when you have one.
Regards, Tjark
On 16/09/2010 12:52, Tjark Weber wrote:
I'll be happy to test a fix/the next release on my machine when you have one.
I've now had a chance to look at this and I've installed some experimental changes to SVN.
I've added some handlers to the C++ "new" allocator so that it shouldn't crash if the allocation fails. Instead there should be an ML exception if there is insufficient memory.
I've added a command-line option (--stackSpace=n) to reserve some memory for thread stacks and the C++ heap. Whenever Poly/ML wants to extend the heap it tries to keep "n" megabytes of memory in reserve. In Linux the default stack size seems to be 8Mbytes but the actual value is set by ulimit -s It seems it also needs 1-2 Mbytes in addition, probably for the C++ heap. The default for the option is currently zero so I'd like some feedback on how it works.
For testing I've also added a --heapmax option. This simulates the effect of Poly/ML growing the heap as far as it will go by allocating as much space for the heap as possible when poly starts up. I'll remove this when the testing is complete.
Could you test this by seeing whether you now get an ML exception instead of the crash and also see whether specifying --stackspace=50 (say) avoids the problem?
Regards, David
-
David.Matthews＠prolingua.co.uk -
tjark.weber＠gmx.de