Phil, I'm copying this to the list since it may affect other people and in fact I think I may have discussed this with Makarius in the past.
The issue was a unexplained segfault which turned out to be caused by the GC running out of stack space. Fundamentally, the problem is that the marking phase of the GC uses a recursive algorithm which can recurse as deep as the data structure being marked. It does a good job of avoiding recursion if there is only one pointer in an object but that doesn't always avoid the problem. The solution, I think, would be to use a bounded queue along with a second bitmap to record when objects need to be rescanned. This will probably have to wait until at least the next release and might be best tackled along with parallelising the garbage collector.
As far as I know there's no way to know that the stack is about to run out and provide some more helpful error message.
Regards, David
Philip Clayton wrote:
Good news! "ulimit -s unlimited" solves this. By default it was set to 10240 (I believe that is kB). That is useful to know about.
In case you are wondering, this GC recursion was happening during the lexing of a block of text that was several MB, I think approx 4-5 MB. I would imagine that the particular reader/lexer (part of ProofPower/DAZ) was just building up a very deep structure.
Thanks, Phil
David Matthews wrote:
Phil, It looks to me as though there is some very deep data structure and that the GC is running out of stack space. It is also possible that there's a bug and the GC is in a recursive loop.
What is your stack limit set to? Try "ulimit -s" under bash. Try removing the limit with "ulimit -s unlimited".
I have a feeling that there was a change that meant that when marking a data structure the GC now involves some extra function calls and so may require more stack space than it did.