We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
In BIPART_LEFT_BLOCKS and RIGHT_BLOCKS, t bipart.cc:616 on my machine, here is a line which looks like:
ADDR_OBJ(x)[1] = blocks_new_obj(bipart_get_cpp(x)->left_blocks());
That's illegal, as the left hand side gets evaluated first, then the right hand side can cause GC.
Found using the new memory canary in ( gap-system/gap#2293 ), just for information.
The text was updated successfully, but these errors were encountered:
Funnily enough we addressed this last week in PR #466.
It now reads
Obj o = blocks_new_obj(bipart_get_cpp(x)->left_blocks()); ADDR_OBJ(x)[1] = o;
Sorry, something went wrong.
Woops, just a little bit too late. I had a quick try of some other functions, and couldn't find anything other obvious memory-related bugs.
This is a duplicate of Issue #444, fixed in the 3.0.15 release, of two days ago 👍
No branches or pull requests
In BIPART_LEFT_BLOCKS and RIGHT_BLOCKS, t bipart.cc:616 on my machine, here is a line which looks like:
ADDR_OBJ(x)[1] = blocks_new_obj(bipart_get_cpp(x)->left_blocks());
That's illegal, as the left hand side gets evaluated first, then the right hand side can cause GC.
Found using the new memory canary in ( gap-system/gap#2293 ), just for information.
The text was updated successfully, but these errors were encountered: