-
-
Notifications
You must be signed in to change notification settings - Fork 409
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
Potential compiler segfault in lookup.c #4153
Comments
Thanks for reporting this one. This should be a straightforward PR for anyone who wants to take it. |
I am happy to submit a PR but wanted to not do it since there is a current PR (private types confusing error...) that involves this file, and I was worried that two edits of lookup.c are potentially floating around. If that is unfounded, I am happy to quickly create the PR |
The variable ponyc/src/libponyc/type/lookup.c Lines 150 to 167 in 58134d1
I actually don't know if Also, we have several |
@ergl Should I close this? |
I don't think this should be closed. I think we should remove the opt != NULL and could reasonably add an assert that it isn't null to the function. |
This attempts to fix issues ponylang#4130 and ponylang#4153. The issue was when a private type in another package was used as a default value in a method call. Fix to ponylang#4130 Since it has been decided to treat this as a bug instead of a missing error, this PR implements the fix suggested by @ergl, namely using `lookup_try()` instead of lookup() in call.c's `check_partial_function_call()` since it allows to permit private types. Fix to ponylang#4153 This is also a simply fix to lookup.c that prevents a potential segfault by a dereferencing of `opt` (`typecheck_t* t = &opt->check;`) *before* `opt != NULL` was checked. As pointed out by @SeanTAllen, opt should not be NULL to begin with when lookup_nominal is called, and instead, an assert should be added and the NULL checks in that function removed.
This attempts to fix ponylang#4130 This crash stems from the use of a private type as defined in another package when it was used as a default value in a method call. Since it has been decided to treat this as a bug instead of a missing error, this PR implements the fix suggested by @ergl, namely using `lookup_try()` instead of lookup() in call.c's `check_partial_function_call()` since the former can be configured to permit private types. Fix to ponylang#4153 This is a simply change to `lookup_nominal()` in lookup.c that prevents a potential segfault by a dereferencing of `opt` (`typecheck_t* t = &opt->check;`) *before* `opt != NULL` was checked. As pointed out by @SeanTAllen, opt should not be NULL to begin with when `lookup_nominal()` is called, and instead, an assert should be added and the NULL checks in that function removed. With this PR, the two examples below that crashed the compiler now both compile: Original example: ```pony // inside the "useful" package primitive _PrivateDefault actor Useful[A: Any val] fun tag config(value: (A | _PrivateDefault) = _PrivateDefault): Useful[A] => this // inside "main" use "useful" primitive This primitive That type Stuff is (This | That) actor Main new create(env: Env) => let u = Useful[Stuff].config() ``` Minimal example: ```pony // In the "lib" pacakge primitive _Private primitive Public fun apply[T](v: (T | _Private) = _Private): None => None // In main use lib = "lib" actor Main new create(env: Env) => let p = lib.Public.apply[U8]() env.out.print(p.string()) ```
I tried your suggestion exactly: It does compile and work fine in Release mode but failed on all platforms in Debug mode with an assertion error. It is unclear to me why, if opt is NULL in Debug mode during that call, the next line dereferencing opt hasn't crashed the current compiler in Debug mode typecheck_t* t = &opt->check; |
We discussed this during sync - the next step would be to use a debugger like lldb to catch the assert fail and figure out what code path is calling a NULL |
Here is the backtrace from the compiler built in Debug mode with this patch applied:
|
@jemc I think I found the offending call/ code path ponyc/src/libponyc/reach/reach.c Lines 563 to 567 in 932d5cd
I think the newly added assertion is tripped by the call to lookup_try in add_special in reach.c where opt is set NULL!
From the design of the function it is likely it was written with the possibility of However, if this call with opt NULL makes it way into lookup_nominal, why does it not currently crash the compiler (without the assertion) in either Debug or Release config when NULL is dereferend in the ponyc/src/libponyc/type/lookup.c Lines 56 to 68 in 58134d1
|
@stefandd - We already have the |
As to the question of how it's not currently crashing the compiler, I don't know and couldn't say further on that without some investigation. |
Unfortunately this definitely does seem more involved. In #4191, I tried first to only implement the suggestion (provide opt as parameter to the Unsure how to proceed with this. |
Can you give more detail - maybe a compiler error output? |
It fails with the newly inserted assertion opt!=NULL being tripped. There is one |
To make it work, we need to add The compiler was written with the assumption that |
@jemc static ast_t* eq_param_type(compile_t* c, ast_t* pattern)
{
ast_t* pattern_type = deferred_reify(c->frame->reify, ast_type(pattern),
c->opt);
deferred_reification_t* fun = lookup(c->opt, pattern, pattern_type, c->str_eq);
AST_GET_CHILDREN(fun->ast, cap, id, typeparams, params, result, partial); The cause for the returned NULL is in Also, I know too little about the compiler to understand why Overall, for me it currently looks as if certain checks in lookup_nominal are suppressed by passing |
The
I think your assessment is correct, but this was the wrong approach by whomever wrote this code - they should have probably passed in an extra flag argument called |
It seems then that resolving this is a bit of a rewrite of certain parts of the compiler which is a task better left to one of the core developers. To summarize the situation:
One way forward would simply be to slightly alter Another way forward is to continue to make the changes as suggested by @jemc and @SeanTAllen which would however need significant modifications to Please advise on how to proceed! |
My suggested approach is still the same as in my previous comment - that the code should be updated in whatever was is necessary to make it no longer assume that |
Ok, I can do this but would have to assume that all guarding |
Yes, I think so. |
ponyc/src/libponyc/type/lookup.c
Lines 56 to 68 in 58134d1
This code is a bit bogus. If opt can be NULL, the declaration
typecheck_t* t = &opt->check;
could crash the compiler. In any case, it looks like the t declaration could be safely moved into the scope of the if-branch, where it is properly guarded against opt == NULL.The text was updated successfully, but these errors were encountered: