You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The issue is that we do not need to reset registers in the this line qlib/kernel/threadmgr/task_signals.rs:1313. Just uncomment this and everything works.
After seeing the go-runtime source code, I figured out that they read the address of g from some of these register we made them zero. So, the issue comes from it because the register point to g is pointing to null.
The issue is that we do not need to reset registers in the this line qlib/kernel/threadmgr/task_signals.rs:1313. Just uncomment this and everything works.
After seeing the go-runtime source code, I figured out that they read the address of g from some of these register we made them zero. So, the issue comes from it because the register point to g is pointing to null.
thanks for figuring out the problem! This makes sense. However I'm not sure whether we should leave the saved trap frame (spelt pt_regs) totally as is. I'll look into linux signal handling later.
(and why should that differ from x86? how does go runtime find the g there?)
reported #1217 (comment)
I think the issue is that the current sig delivery is not dealing with user custom stack correctly (that was set by sys_sigaltstack)
The text was updated successfully, but these errors were encountered: