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

backtrace test issue #33877

Closed
vtjnash opened this issue Nov 18, 2019 · 4 comments · Fixed by #34019
Closed

backtrace test issue #33877

vtjnash opened this issue Nov 18, 2019 · 4 comments · Fixed by #34019

Comments

@vtjnash
Copy link
Sponsor Member

vtjnash commented Nov 18, 2019

Been seeing a lot of this start happening recently: https://build.julialang.org/#/builders/65/builds/5828

Error in testset backtrace:
Test Failed at D:\buildbot\worker-tabularasa\tester_win32\build\share\julia\test\backtrace.jl:239
  Expression: read(#= D:\buildbot\worker-tabularasa\tester_win32\build\share\julia\test\backtrace.jl:239 =# Core.@cmd("\$(Base.julia_cmd()) --startup-file=no --compile=min -e \$code"), String) == "1000 1000"
   Evaluated: "998 1000" == "1000 1000"
@c42f
Copy link
Member

c42f commented Nov 20, 2019

Is this only on the windows buildbots?

@c42f
Copy link
Member

c42f commented Nov 26, 2019

For the record, Jameson reports on slack that he's only observed this on the windows AWS buildbots so far.

@c42f c42f mentioned this issue Nov 26, 2019
Closed
vtjnash added a commit that referenced this issue Dec 4, 2019
@vtjnash
simplify interpreter-stacktraces code
3d1d693 
The unwinder and debuggers thought that our assembly code here was not
quite correct. Rather than attempt to fix that, let the compiler
generate it so we don't need to maintain it anymore.

This was previously also not particularly optimal for an interpreter to
need a couple extra function calls (by indirect pointer too) to setup
the call frame, so now we avoid that.

This simplifies the design by adding a new flag bit to the existing
pgcstack frames. In the future, we may end up generalizing this support
to handle stack allocation of arbitrary objects, but for now we
implement just enough support for our current needs.

It's unclear why dbghelp StackWalk glitches here a couple times (it is
reporting the stack pointer instead of the instruction pointer as the
return address), but this design is robust against that now (even though
I've manually verified that that particular glitch still happens with
this patch).

fix #33877
vtjnash added a commit that referenced this issue Dec 4, 2019
@vtjnash
simplify interpreter-stacktraces code
72d95d3 
The unwinder and debuggers thought that our assembly code here was not
quite correct. Rather than attempt to fix that, let the compiler
generate it so we don't need to maintain it anymore.

This was previously also not particularly optimal for an interpreter to
need a couple extra function calls (by indirect pointer too) to setup
the call frame, so now we avoid that.

This simplifies the design by adding a new flag bit to the existing
pgcstack frames. In the future, we may end up generalizing this support
to handle stack allocation of arbitrary objects, but for now we
implement just enough support for our current needs.

It's unclear why dbghelp StackWalk glitches here a couple times (it is
reporting the stack pointer instead of the instruction pointer as the
return address), but this design is robust against that now (even though
I've manually verified that that particular glitch still happens with
this patch).

fix #33877
@vtjnash vtjnash mentioned this issue Dec 4, 2019
Merged
vtjnash added a commit that referenced this issue Dec 4, 2019
@vtjnash
simplify interpreter-stacktraces code
cf714ef 
The unwinder and debuggers thought that our assembly code here was not
quite correct. Rather than attempt to fix that, let the compiler
generate it so we don't need to maintain it anymore.

This was previously also not particularly optimal for an interpreter to
need a couple extra function calls (by indirect pointer too) to setup
the call frame, so now we avoid that.

This simplifies the design by adding a new flag bit to the existing
pgcstack frames. In the future, we may end up generalizing this support
to handle stack allocation of arbitrary objects, but for now we
implement just enough support for our current needs.

It's unclear why dbghelp StackWalk glitches here a couple times (it is
reporting the stack pointer instead of the instruction pointer as the
return address), but this design is robust against that now (even though
I've manually verified that that particular glitch still happens with
this patch).

fix #33877
vtjnash added a commit that referenced this issue Dec 4, 2019
@vtjnash
simplify interpreter-stacktraces code
64cd545 
The unwinder and debuggers thought that our assembly code here was not
quite correct. Rather than attempt to fix that, let the compiler
generate it so we don't need to maintain it anymore.

This was previously also not particularly optimal for an interpreter to
need a couple extra function calls (by indirect pointer too) to setup
the call frame, so now we avoid that.

This simplifies the design by adding a new flag bit to the existing
pgcstack frames. In the future, we may end up generalizing this support
to handle stack allocation of arbitrary objects, but for now we
implement just enough support for our current needs.

It's unclear why dbghelp StackWalk glitches here a couple times (it is
reporting the stack pointer instead of the instruction pointer as the
return address), but this design is robust against that now (even though
I've manually verified that that particular glitch still happens with
this patch).

fix #33877
vtjnash added a commit that referenced this issue Dec 11, 2019
@vtjnash
simplify interpreter-stacktraces code
98f42c4 
The unwinder and debuggers thought that our assembly code here was not
quite correct. Rather than attempt to fix that, let the compiler
generate it so we don't need to maintain it anymore.

This was previously also not particularly optimal for an interpreter to
need a couple extra function calls (by indirect pointer too) to setup
the call frame, so now we avoid that.

This simplifies the design by adding a new flag bit to the existing
pgcstack frames. In the future, we may end up generalizing this support
to handle stack allocation of arbitrary objects, but for now we
implement just enough support for our current needs.

It's unclear why dbghelp StackWalk glitches here a couple times (it is
reporting the stack pointer instead of the instruction pointer as the
return address), but this design is robust against that now (even though
I've manually verified that that particular glitch still happens with
this patch).

fix #33877
JeffBezanson pushed a commit that referenced this issue Dec 12, 2019
@vtjnash @JeffBezanson
simplify interpreter-stacktraces code (#34019)
7090b23 
The unwinder and debuggers thought that our assembly code here was not
quite correct. Rather than attempt to fix that, let the compiler
generate it so we don't need to maintain it anymore.

This was previously also not particularly optimal for an interpreter to
need a couple extra function calls (by indirect pointer too) to setup
the call frame, so now we avoid that.

This simplifies the design by adding a new flag bit to the existing
pgcstack frames. In the future, we may end up generalizing this support
to handle stack allocation of arbitrary objects, but for now we
implement just enough support for our current needs.

It's unclear why dbghelp StackWalk glitches here a couple times (it is
reporting the stack pointer instead of the instruction pointer as the
return address), but this design is robust against that now (even though
I've manually verified that that particular glitch still happens with
this patch).

fix #33877
@c42f
Copy link
Member

c42f commented Dec 13, 2019

Out of curiosity, how did you get to the bottom of this @vtjnash? I hope some info from #33948 may have helped, meager and confusing as it was.

@vtjnash
Copy link
Sponsor Member Author

vtjnash commented Dec 16, 2019

Eventually I loaded that PR up in a debugger on the CI worker and stepped through the code until I observed the source of the failure.

KristofferC pushed a commit that referenced this issue Apr 11, 2020
@vtjnash @KristofferC
simplify interpreter-stacktraces code (#34019)
259f794 
The unwinder and debuggers thought that our assembly code here was not
quite correct. Rather than attempt to fix that, let the compiler
generate it so we don't need to maintain it anymore.

This was previously also not particularly optimal for an interpreter to
need a couple extra function calls (by indirect pointer too) to setup
the call frame, so now we avoid that.

This simplifies the design by adding a new flag bit to the existing
pgcstack frames. In the future, we may end up generalizing this support
to handle stack allocation of arbitrary objects, but for now we
implement just enough support for our current needs.

It's unclear why dbghelp StackWalk glitches here a couple times (it is
reporting the stack pointer instead of the instruction pointer as the
return address), but this design is robust against that now (even though
I've manually verified that that particular glitch still happens with
this patch).

fix #33877
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

simplify interpreter-stacktraces code JuliaLang/julia
2 participants
@vtjnash @c42f