On Friday, September 5, 2014 3:47:53 PM UTC+2, Volker Braun wrote:
I don't know of a ticket, feel free to fix it. All relevant files are in
build/pkgs/singular. It seems that the debug patches conflict with the
cygwin patch. Also, the debug patches should probably be applied strictly
On Sunday, December 30, 2012 3:05:52 AM UTC, Dima Pasechnik wrote:
GAP uses mmap to get/extend memory.
On Linux, mmap has a MAP_NORESERVE parameter which tells the kernel
whether or not to reserve the swap.
Granted, if MAP_NORESERVE is set then one can get
a segfault - but segfaults can
On 2012-12-30, Volker Braun vbraun.n...@gmail.com wrote:
--=_Part_615_22553311.1356862244107
Content-Type: text/plain; charset=ISO-8859-1
On Sunday, December 30, 2012 3:05:52 AM UTC, Dima Pasechnik wrote:
GAP uses mmap to get/extend memory.
On Linux, mmap has a MAP_NORESERVE parameter
On Sunday, December 30, 2012 1:20:24 PM UTC, Dima Pasechnik wrote:
I think it's just the matter of setting up a fresh signal handler before
calling mmap(), and reinstating the old one after this is done.
No, if you mmap() with MAP_NORESERVE then it always succeeds (if the
processor can
On Dec 30, 8:03 am, Volker Braun vbraun.n...@gmail.com wrote:
No, if you mmap() with MAP_NORESERVE then it always succeeds (if the
processor can address it, 16TB on x86_64). Reads always succeed. But
whenever you write to the memory map, you can get a SIGSEGV.
In the face of Linux's overcommit
On 2012-12-30, Volker Braun vbraun.n...@gmail.com wrote:
--=_Part_795_4463763.1356883427560
Content-Type: text/plain; charset=ISO-8859-1
On Sunday, December 30, 2012 1:20:24 PM UTC, Dima Pasechnik wrote:
I think it's just the matter of setting up a fresh signal handler before
calling
On Dec 29, 6:01 am, Simon King simon.k...@uni-jena.de wrote:
* In sage/misc/memory_info.py, MemoryInfo().available_swap() returns
zero, but it is expected to return a positive number. No idea where
that comes from.
For me that test works properly. However, I'd say it's perfectly
legitimate
On 2012-12-29, Nils Bruin nbr...@sfu.ca wrote:
On Dec 29, 6:01 am, Simon King simon.k...@uni-jena.de wrote:
* In sage/misc/memory_info.py, MemoryInfo().available_swap() returns
zero, but it is expected to return a positive number. No idea where
that comes from.
For me that test works
Hi Nils,
On 2012-12-29, Nils Bruin nbr...@sfu.ca wrote:
I don't think this issue is related to debug builds, though. The
file itself got introduced on #13211 and merged in 5.6b1. Volker is
the sole author, so he can probably comment.
Only introduced in 5.6b1? Hm. I did not test what happens
On Saturday, December 29, 2012 6:23:13 PM UTC, Dima Pasechnik wrote:
Actually, GAP wants to reserve an awful lot of swap on systems
with a lot of RAM
We set up GAP to reserve a lot of swap on systems with a lot of free swap.
640kb is not enough for everybody.
--
You received this message
On Dec 29, 11:13 am, Volker Braun vbraun.n...@gmail.com wrote:
We set up GAP to reserve a lot of swap on systems with a lot of free swap.
640kb is not enough for everybody.
Agreed. It sucks that GAP needs an upper limit at startup, but we
won't be changing that.
I retract my complaint about
Fix is at http://trac.sagemath.org/13880
Also, I don't see how a longjmp is going to fix that. Ideally, GAP would
rewrite their allocator to not require a single contiguous chunk of memory.
It would be fine to have a fixed-size master pointer area and a
reallocatable (or even non-contiguous)
Hi!
On 2012-12-29, Simon King simon.k...@uni-jena.de wrote:
* There is one crash in sage/combinat/tiling.py: Sage's debug version
allows to test assertions in headers, and there is a failing assertion
in sage/combinat/matrices/dancing_links_c.h, line 217. I already
reported on
On 2012-12-29, Volker Braun vbraun.n...@gmail.com wrote:
--=_Part_750_16846180.1356813944502
Content-Type: text/plain; charset=ISO-8859-1
Fix is at http://trac.sagemath.org/13880
Also, I don't see how a longjmp is going to fix that. Ideally, GAP would
rewrite their allocator to not
14 matches
Mail list logo
