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

Delete trust_inference option #50432

Merged
merged 2 commits into from
Jul 6, 2023
Merged

Delete trust_inference option #50432

merged 2 commits into from
Jul 6, 2023

Conversation

Keno
Copy link
Member

@Keno Keno commented Jul 6, 2023

I think the time has come to flip this. This was added when the type system was much less reliable at producing intersections. It is true that we still have the occasional type sytem bug, but we're already trusting inference in a bunch of other places. At the same time, the cost of this has grown in terms of bloated IR needing to be visited in places like irinterp, so let's flip the bit and we'll deal with type system bugs the way we usually due.

I think the time has come to flip this. This was added when the type
system was much less reliable at producing intersections. It is true
that we still have the occasional type sytem bug, but we're already
trusting inference in a bunch of other places. At the same time,
the cost of this has grown in terms of bloated IR needing to
be visited in places like irinterp, so let's flip the bit and
we'll deal with type system bugs the way we usually due.
Copy link
Member

@aviatesk aviatesk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm fine with this. Can't we just delete this option entirely and remove the related branches also?

@vtjnash
Copy link
Member

vtjnash commented Jul 6, 2023

I agree with @aviatesk

@oscardssmith
Copy link
Member

Refactored.

@oscardssmith oscardssmith changed the title Flip trust_inference option Delete trust_inference option Jul 6, 2023
@vtjnash
Copy link
Member

vtjnash commented Jul 6, 2023

Not sure why rr ran into such trouble here (signal SIGSTKFLT?), but probably not the PR fault

[Scheduler] Scheduling next task (ALLOW_SWITCH)
[Scheduler] Task event is SYSCALL: openat
[Scheduler]   2125 is blocked on SYSCALL: openat; checking status ...
[RecordTask] waitid(2125, NOHANG) returns 0
[Scheduler]   still blocked
[Scheduler]   need to reschedule
[Scheduler] Task event is SYSCALL: rt_sigtimedwait
[Scheduler]   2098 is blocked on SYSCALL: rt_sigtimedwait; checking status ...
[RecordTask] waitid(2098, NOHANG) returns 0
[Scheduler]   still blocked
[Scheduler] Task event is SYSCALL: rt_sigtimedwait
[Scheduler]   2106 is blocked on SYSCALL: rt_sigtimedwait; checking status ...
[RecordTask] waitid(2106, NOHANG) returns 0
[Scheduler]   still blocked
[Scheduler] Task event is SYSCALL: rt_sigtimedwait
[Scheduler]   2107 is blocked on SYSCALL: rt_sigtimedwait; checking status ...
[RecordTask] waitid(2107, NOHANG) returns 0
[Scheduler]   still blocked
[Scheduler] Task event is SYSCALL: rt_sigtimedwait
[Scheduler]   2130 is blocked on SYSCALL: rt_sigtimedwait; checking status ...
[RecordTask] waitid(2130, NOHANG) returns 0
[Scheduler]   still blocked
[Scheduler] Task event is SCHED
[Scheduler]   2135 isn't blocked
[Scheduler]   selecting task 2135
[Scheduler] Switching from 2125(julia) to 2135(julia) (priority 0 to 0) at 2692976
[RecordSession] trace time 2692976: Active task is 2135. Events:
[INFO log_pending_events()] SCHED
[INFO log_pending_events()] (none)
[RecordSession] EXEC_START: status=0x107f (STOP-SIGSTKFLT)
[RecordTask] Refreshed sigmask, now 0x4206
[PerfCounters] Resetting counters with period 2434898
[Task] resuming execution of 2135 with PTRACE_CONT tick_period 2434898 wait 1
[Scheduler] Scheduling next task (PREVENT_SWITCH)
[Scheduler]   (2135 is un-switchable at SCHED)
[Scheduler]   and running; waiting for state change
[Task] going into blocking waitid(2135) ...
[Task]   Task 2135 changed status to 0x107f (STOP-SIGSTKFLT)
[Task]   (refreshing register cache)
[Task] Requesting registers from tracee 2135
[Scheduler]   new status is 0x107f (STOP-SIGSTKFLT)
[RecordSession] trace time 2692976: Active task is 2135. Events:
[INFO log_pending_events()] (no pending events)
[record_signal] 2135: handling signal SIGSTKFLT (pevent: PTRACE_EVENT(0), event: (none)
[record_signal] Safe to deliver signal at 0x7f464b417ff0 because not in syscallbuf
[RecordSession] SIGSTKFLT handled
[Scheduler] Scheduling next task (ALLOW_SWITCH)
[Scheduler]   need to reschedule
[Scheduler] Task event is SYSCALL: rt_sigtimedwait
[Scheduler]   2110 is blocked on SYSCALL: rt_sigtimedwait; checking status ...
[RecordTask] waitid(2110, NOHANG) returns 0
[Scheduler]   still blocked
[Scheduler] Task event is (none)
[Scheduler]   2136 isn't blocked
[Scheduler]   selecting task 2136
[Scheduler] Switching from 2135(julia) to 2136(julia) (priority 0 to 0) at 2692976
[FATAL src/RecordTask.cc:1809:maybe_flush_syscallbuf() errno: EDOM]
 (task 2135 (rec:2135) at time 2692976)
 -> Assertion `!flushed_syscallbuf || flushed_num_rec_bytes == hdr.num_rec_bytes' failed to hold.
[INFO log_pending_events()] SCHED
[INFO log_pending_events()] (none)
[FATAL src/log.cc:444:emergency_debug()] (session doesn't look interactive, aborting emergency debugging)
=== Start rr backtrace:
/root/.julia/artifacts/37805a06093bdc0d5938601719cf02fa0cf3aa68/bin/rr(_ZN2rr13dump_rr_stackEv+0x28)[0x6437d8]
/root/.julia/artifacts/37805a06093bdc0d5938601719cf02fa0cf3aa68/bin/rr(_ZN2rr15notifying_abortEv+0xe)[0x64500e]
/root/.julia/artifacts/37805a06093bdc0d5938601719cf02fa0cf3aa68/bin/rr[0x662dd0]
/root/.julia/artifacts/37805a06093bdc0d5938601719cf02fa0cf3aa68/bin/rr[0x53a9d6]
/root/.julia/artifacts/37805a06093bdc0d5938601719cf02fa0cf3aa68/bin/rr[0x53b30b]
/root/.julia/artifacts/37805a06093bdc0d5938601719cf02fa0cf3aa68/bin/rr(_ZN2rr10RecordTask22maybe_flush_syscallbufEv+0xb4)[0x5c4d94]
/root/.julia/artifacts/37805a06093bdc0d5938601719cf02fa0cf3aa68/bin/rr(_ZN2rr10RecordTask12record_eventERKNS_5EventENS0_15FlushSyscallbufENS0_20AllowSyscallbufResetEPKNS_9RegistersE+0x475)[0x5c5f55]
/root/.julia/artifacts/37805a06093bdc0d5938601719cf02fa0cf3aa68/bin/rr(_ZN2rr13RecordSession11record_stepEv+0x466)[0x571dc6]
/root/.julia/artifacts/37805a06093bdc0d5938601719cf02fa0cf3aa68/bin/rr(_ZN2rr13RecordCommand3runERSt6vectorINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESaIS7_EE+0xaf8)[0x567178]
/root/.julia/artifacts/37805a06093bdc0d5938601719cf02fa0cf3aa68/bin/rr(main+0x1a8)[0x4cec78]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xeb)[0x7f4a0b7a809b]
/root/.julia/artifacts/37805a06093bdc0d5938601719cf02fa0cf3aa68/bin/rr[0x4cf155]
=== End rr backtrace
/cache/build/default-amdci4-6/julialang/julia-master/temp_for_rr/jl_Z7eepa/capture_output.sh: line 3:   524 Aborted                 /root/.julia/artifacts/37805a06093bdc0d5938601719cf02fa0cf3aa68/bin/rr record --nested=detach "$@" > >(tee -a /cache/build/default-amdci4-6/julialang/julia-master/temp_for_rr/jl_Z7eepa/stdout.log) 2> >(tee -a /cache/build/default-amdci4-6/julialang/julia-master/temp_for_rr/jl_Z7eepa/stderr.log >&2)
Pkg             (7) |         failed at 2023-07-06T17:53:35.747

@Keno
Copy link
Member Author

Keno commented Jul 6, 2023

Not sure why rr ran into such trouble here (signal SIGSTKFLT?), but probably not the PR fault

Known rr bug rr-debugger/rr#3468

@Keno Keno merged commit 46477cc into master Jul 6, 2023
@Keno Keno deleted the kf/fliptrustinference branch July 6, 2023 21:19
@@ -630,14 +630,7 @@ function ir_inline_unionsplit!(compact::IncrementalCompact, idx::Int,
end
bb += 1
# We're now in the fall through block, decide what to do
if fully_covered
if !params.trust_inference
e = Expr(:call, GlobalRef(Core, :throw), FATAL_TYPE_BOUND_ERROR)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any reason you didn't remove the FATAL_TYPE_BOUND_ERROR definition?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

was this the only use of it? If so the reason is because I didn't notice that there weren't any other uses.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maleadt added a commit that referenced this pull request Jul 7, 2023
vtjnash pushed a commit that referenced this pull request Aug 31, 2023
Fix #50709

This issue *appears* fixed on master due to #50432, which simply removed
the error. This fixes the underlying cause, which is that we sometimes
return typevars in the environment from intersection that have free vars
in their bounds. I think it's reasonable to just widen these
aggressively, since we usually cannot do much with these kinds of
unknown static parameters anyway.
IanButterworth pushed a commit that referenced this pull request Sep 16, 2023
Fix #50709

This issue *appears* fixed on master due to #50432, which simply removed
the error. This fixes the underlying cause, which is that we sometimes
return typevars in the environment from intersection that have free vars
in their bounds. I think it's reasonable to just widen these
aggressively, since we usually cannot do much with these kinds of
unknown static parameters anyway.

(cherry picked from commit a3e2316)
nalimilan pushed a commit that referenced this pull request Nov 5, 2023
Fix #50709

This issue *appears* fixed on master due to #50432, which simply removed
the error. This fixes the underlying cause, which is that we sometimes
return typevars in the environment from intersection that have free vars
in their bounds. I think it's reasonable to just widen these
aggressively, since we usually cannot do much with these kinds of
unknown static parameters anyway.

(cherry picked from commit a3e2316)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants