Skip to content
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.

Sign up for GitHub

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

Jump to bottom

which("julia") causes seg fault #44153

Closed
jlapeyre opened this issue Feb 12, 2022 · 7 comments
Closed

which("julia") causes seg fault #44153

jlapeyre opened this issue Feb 12, 2022 · 7 comments
Assignees
@aviatesk
Labels
bug Indicates an unexpected problem or unintended behavior

Comments

@jlapeyre
Copy link
Contributor

problem:

julia> which("julia")

signal (11): Segmentation fault

This should throw an error instead.

Version 1.8.0-DEV.1501 (2022-02-12)
@oscardssmith oscardssmith added bug Indicates an unexpected problem or unintended behavior regression Regression in behavior compared to a previous version labels Feb 12, 2022
@oscardssmith
Copy link
Member

this is a regression since 1.6

@simeonschaub
Copy link
Member

@aviatesk You removed the input type annotations in #43087. Is there a way to achieve the same behavior wrt specialization while also keeping the annotations? We could manually throw errors, but that seems cumbersome. Or should we just revert #43087?

@giordano
Copy link
Contributor

@jlapeyre did you mean Sys.which("julia")?

this is a regression since 1.6

In v1.6 it returned a MethodError because he's likely trying to call the wrong function.

@jlapeyre
Copy link
Contributor Author

Yes, I did mean to say Sys.which("julia"). I tried to call the wrong function, so it should throw an error, not segfault.
It looks like such an obvious mistake that I'm surprised it wasn't found. I guess this is the first issue. I searched for it.

@giordano
Copy link
Contributor

Sure, the segfault isn't nice and should be fixed anyway, but I just want to stress that no working code should be affected by this issues, since which(::String) isn't supposed to work.

@aviatesk
Copy link
Member

aviatesk commented Feb 13, 2022 •
edited
Loading

Is there a way to achieve the same behavior wrt specialization while also keeping the annotations?

After #43113 Julia compiler can inline @nospecialize ::AbstractType signature, so we can reintroduce the input type annotations.
Still I want to keep the current ::Any signature for those utility functions heavily in Core.Compiler (e.g. isbitstype) because isa(t, Type) check inserted by the inliner might involve some cost.
But I agree that the other non-performance sensitive functions like which is better to have input type restrictions.

@aviatesk aviatesk removed the regression Regression in behavior compared to a previous version label Feb 13, 2022
@jlapeyre
Copy link
Contributor Author

I just want to stress that no working code should be affected

Oh yes, important distinction.

aviatesk added a commit that referenced this issue Feb 13, 2022
@aviatesk
fix #44153, limit input types of reflection utilities
6ee499d 
After #43113 Julia compiler can inline `@nospecialize ::AbstractType`
signature, so we can reintroduce the input type annotations.
Still I want to keep the current `::Any` signature for those utility
functions heavily in `Core.Compiler` (e.g. `isbitstype`) because `isa(t, Type)`
check inserted by the inliner otherwise might involve some cost.
But I agree that the other non-performance sensitive functions like `which`
is better to have input type restrictions.
antoine-levitt pushed a commit to antoine-levitt/julia that referenced this issue Feb 17, 2022
@aviatesk @antoine-levitt
fix JuliaLang#44153, limit input types of reflection utilities (Julia…
3de59e7 
…Lang#44155)

After JuliaLang#43113 Julia compiler can inline `@nospecialize ::AbstractType`
signature, so we can reintroduce the input type annotations.
Still I want to keep the current `::Any` signature for those utility
functions heavily in `Core.Compiler` (e.g. `isbitstype`) because `isa(t, Type)`
check inserted by the inliner otherwise might involve some cost.
But I agree that the other non-performance sensitive functions like `which`
is better to have input type restrictions.
LilithHafner pushed a commit to LilithHafner/julia that referenced this issue Feb 22, 2022
@aviatesk @LilithHafner
fix JuliaLang#44153, limit input types of reflection utilities (Julia…
ca14386 
…Lang#44155)

After JuliaLang#43113 Julia compiler can inline `@nospecialize ::AbstractType`
signature, so we can reintroduce the input type annotations.
Still I want to keep the current `::Any` signature for those utility
functions heavily in `Core.Compiler` (e.g. `isbitstype`) because `isa(t, Type)`
check inserted by the inliner otherwise might involve some cost.
But I agree that the other non-performance sensitive functions like `which`
is better to have input type restrictions.
LilithHafner pushed a commit to LilithHafner/julia that referenced this issue Mar 8, 2022
@aviatesk @LilithHafner
fix JuliaLang#44153, limit input types of reflection utilities (Julia…
a1a7941 
…Lang#44155)

After JuliaLang#43113 Julia compiler can inline `@nospecialize ::AbstractType`
signature, so we can reintroduce the input type annotations.
Still I want to keep the current `::Any` signature for those utility
functions heavily in `Core.Compiler` (e.g. `isbitstype`) because `isa(t, Type)`
check inserted by the inliner otherwise might involve some cost.
But I agree that the other non-performance sensitive functions like `which`
is better to have input type restrictions.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@aviatesk aviatesk

Labels
bug Indicates an unexpected problem or unintended behavior
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@giordano @jlapeyre @simeonschaub @oscardssmith @aviatesk