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.

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

Segfault with ^ (caret) operator with string and UInt of value zero. #35578

Closed
Demonstrandum opened this issue Apr 23, 2020 · 0 comments · Fixed by #35579
Closed

Segfault with ^ (caret) operator with string and UInt of value zero. #35578

Demonstrandum opened this issue Apr 23, 2020 · 0 comments · Fixed by #35579
Labels
bug Indicates an unexpected problem or unintended behavior strings "Strings!"

Comments

@Demonstrandum
Copy link

System & Version

uname:

Arch Linux 4.19.91-lts x86_64 GNU/Linux

versioninfo():

Julia Version 1.4.1
Commit 381693d3df* (2020-04-14 17:20 UTC)
Platform Info:
  OS: Linux (x86_64-pc-linux-gnu)
  CPU: Intel(R) Core(TM) i5-7300U CPU @ 2.60GHz
  WORD_SIZE: 64
  LIBM: libopenlibm
  LLVM: libLLVM-8.0.1 (ORCJIT, skylake)

Bug

When I try to apply ^ to a string more than one character long with an unsigned integer with value 0 (when trying to duplicate the string n (zero) times), it segfaults.

julia> "xx" ^ Int(0)    # works
""
julia> "xx" ^ UInt(2)   # works
"xxxx"
julia> "x" ^ UInt(0)    # works
""
julia> "xx" ^ UInt(0)   # segfaults

signal (11): Segmentation fault
in expression starting at REPL[3]:0
unknown function (ip: 0x7f7df8c8d369)
unknown function (ip: 0x7f7df8eb8b0a)
unknown function (ip: 0x7f7df8eb8ef4)
unknown function (ip: 0x7f7e05c9b439)
unknown function (ip: (nil))
Allocations: 962253 (Pool: 961928; Big: 325); GC: 1
[1]    96359 segmentation fault (core dumped)  julia

# Expected:
""
ararslan added a commit that referenced this issue Apr 24, 2020
Currently the case where `r == 0` falls through the same logic as every
other non-negative value of `r` (aside from 1). This works for signed
integers. However, this does not work for unsigned integers: in the loop
where we unsafely fill in the output string, we're looping from 0 to `r
- 1`, which for unsigned integers wraps around and causes us to request
the address of the output string at a location that is well beyond what
was allocated.

Fixes #35578.
@JeffBezanson JeffBezanson added bug Indicates an unexpected problem or unintended behavior strings "Strings!" labels Apr 24, 2020
fredrikekre pushed a commit that referenced this issue Apr 24, 2020
Currently the case where `r == 0` falls through the same logic as every
other non-negative value of `r` (aside from 1). This works for signed
integers. However, this does not work for unsigned integers: in the loop
where we unsafely fill in the output string, we're looping from 0 to `r
- 1`, which for unsigned integers wraps around and causes us to request
the address of the output string at a location that is well beyond what
was allocated.

Fixes #35578.
KristofferC pushed a commit that referenced this issue May 10, 2020
Currently the case where `r == 0` falls through the same logic as every
other non-negative value of `r` (aside from 1). This works for signed
integers. However, this does not work for unsigned integers: in the loop
where we unsafely fill in the output string, we're looping from 0 to `r
- 1`, which for unsigned integers wraps around and causes us to request
the address of the output string at a location that is well beyond what
was allocated.

Fixes #35578.

(cherry picked from commit 1dcb42f)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Indicates an unexpected problem or unintended behavior strings "Strings!"
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants