Reported by Hanbin Lee on Slack, https://tskit-dev.slack.com/archives/C01JKJC5Y9G/p1762540162029699. Input script and .trees file supplied there, and now on my Desktop in Hanbin_bug.
The description from Hanbin:
The command that crashes (sequenceLength is given twice):
slim -d sequenceLength=1 -d sequenceLength=1 -d numIndividuals=10 -d inTreeSequence="'test.trees'" test.slim
The command that's okay:
slim -d sequenceLength=1 -d numIndividuals=10 -d inTreeSequence="'test.trees'" test.slim
The tree sequence file seems to be irrelevant but I'm uploading it for a reference. I tried both slim 5.0 and 5.1 in conda-forge and have the same crashing.
My response so far:
How very odd. The -d is defining a constant, of course; so you’re trying to redefine a constant that has already been defined. I’m surprised that doesn’t raise an error straight off. But that doesn’t seem to be the problem exactly, since this seems to work fine:
slim -d foo=1 -d foo=1 /Users/bhaller/Desktop/default.slim
So it doesn’t seem to happen for just any duplicated -d command line option. Your hang does reproduce on my end with your input files, though; thanks for those. It looks like the double define has somehow corrupted the Eidos interpreter’s symbol table. I’m not sure why that would happen, but I suspect some part of the code is not expecting a constant in the symbol table to get redefined, and so the fact that this code path does not raise an error, but instead happily just tries to redefine the constant, probably leads to the corruption. Nice find. :->
Reported by Hanbin Lee on Slack, https://tskit-dev.slack.com/archives/C01JKJC5Y9G/p1762540162029699. Input script and .trees file supplied there, and now on my Desktop in
Hanbin_bug.The description from Hanbin:
The command that crashes (sequenceLength is given twice):
slim -d sequenceLength=1 -d sequenceLength=1 -d numIndividuals=10 -d inTreeSequence="'test.trees'" test.slimThe command that's okay:
slim -d sequenceLength=1 -d numIndividuals=10 -d inTreeSequence="'test.trees'" test.slimThe tree sequence file seems to be irrelevant but I'm uploading it for a reference. I tried both slim 5.0 and 5.1 in conda-forge and have the same crashing.
My response so far:
How very odd. The -d is defining a constant, of course; so you’re trying to redefine a constant that has already been defined. I’m surprised that doesn’t raise an error straight off. But that doesn’t seem to be the problem exactly, since this seems to work fine:
slim -d foo=1 -d foo=1 /Users/bhaller/Desktop/default.slimSo it doesn’t seem to happen for just any duplicated
-dcommand line option. Your hang does reproduce on my end with your input files, though; thanks for those. It looks like the double define has somehow corrupted the Eidos interpreter’s symbol table. I’m not sure why that would happen, but I suspect some part of the code is not expecting a constant in the symbol table to get redefined, and so the fact that this code path does not raise an error, but instead happily just tries to redefine the constant, probably leads to the corruption. Nice find. :->