New issue
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
Closure marshalling in toplevel is broken since at least 4.00 #6760
Comments
Comment author: @whitequark @gasche: I've attached a patch. |
Comment author: @gasche I find it rather suspicious that caml_ext_table_remove would take the responsibility to caml_stat_free the data to remove. Does this really correspond to the ownership disciplines of all users of caml_ext_table_add? Also, I'm not familiar with this part of the code, but isn't abort()ing in caml_static_release_bytecode a bit overconfident? I would be more comfortable with at least an error message. |
Comment author: @whitequark It does; caml_ext_table_free performs caml_stat_free on the data, which is why I wrote _remove that way. I don't think so; in the impossible case (mismatched reify/release) that it happens, the backtrace provides more than enough context to debug this. |
Comment author: @jhjourdan gashe : here is what I think. It seems fine to me, except for the abort(), that does not fit the discipline of the rest of the runtime. You should instead use CAMLassert. |
Comment author: @gasche Merged -- in trunk only -- with the change suggested by Jacques-Henri: if (!cf) { |
Original bug ID: 6760
Reporter: @whitequark
Assigned to: @whitequark
Status: closed (set by @xavierleroy on 2016-12-07T10:47:12Z)
Resolution: fixed
Priority: normal
Severity: major
Fixed in version: 4.03.0+dev / +beta1
Category: runtime system and C interface
Tags: patch
Related to: #6468
Monitored by: @gasche @hcarty
Bug description
To reproduce, do in toplevel:
File attachments
The text was updated successfully, but these errors were encountered: