0843376018
On linux we can not read memory if the thread we use to do it is occupied doing certain system calls. The exact conditions when this happens have never been clear. This problem was worked around by using the Blocked method which recognized the most common circumstances where this would happen. However this is a hack: Blocked returning true doesn't mean that the problem will manifest and Blocked returning false doesn't necessarily mean the problem will not manifest. A side effect of this is issue #2151 where sometimes we can't read the memory of a thread and find its associated goroutine. This commit fixes this problem by always reading memory using a thread we know to be good for this, specifically the one returned by ContinueOnce. In particular the changes are as follows: 1. Remove (ProcessInternal).CurrentThread and (ProcessInternal).SetCurrentThread, the "current thread" becomes a field of Target, CurrentThread becomes a (*Target) method and (*Target).SwitchThread basically just sets a field Target. 2. The backends keep track of their own internal idea of what the current thread is, to use it to read memory, this is the thread they return from ContinueOnce as trapthread 3. The current thread in the backend and the current thread in Target only ever get synchronized in two places: when the backend creates a Target object the currentThread field of Target is initialized with the backend's current thread and when (*Target).Restart gets called (when a recording is rewound the currentThread used by Target might not exist anymore). 4. We remove the MemoryReadWriter interface embedded in Thread and instead add a Memory method to Process that returns a MemoryReadWriter. The backends will return something here that will read memory using the current thread saved by the backend. 5. The Thread.Blocked method is removed One possible problem with this change is processes that have threads with different memory maps. As far as I can determine this could happen on old versions of linux but this option was removed in linux 2.5. Fixes #2151
67 lines
1.6 KiB
Go
67 lines
1.6 KiB
Go
package core
|
|
|
|
import (
|
|
"github.com/go-delve/delve/pkg/logflags"
|
|
"github.com/go-delve/delve/pkg/proc"
|
|
"github.com/go-delve/delve/pkg/proc/core/minidump"
|
|
"github.com/go-delve/delve/pkg/proc/winutil"
|
|
)
|
|
|
|
func readAMD64Minidump(minidumpPath, exePath string) (*process, proc.Thread, error) {
|
|
var logfn func(string, ...interface{})
|
|
if logflags.Minidump() {
|
|
logfn = logflags.MinidumpLogger().Infof
|
|
}
|
|
|
|
mdmp, err := minidump.Open(minidumpPath, logfn)
|
|
if err != nil {
|
|
if _, isNotAMinidump := err.(minidump.ErrNotAMinidump); isNotAMinidump {
|
|
return nil, nil, ErrUnrecognizedFormat
|
|
}
|
|
return nil, nil, err
|
|
}
|
|
|
|
memory := &splicedMemory{}
|
|
|
|
for i := range mdmp.MemoryRanges {
|
|
m := &mdmp.MemoryRanges[i]
|
|
memory.Add(m, m.Addr, uint64(len(m.Data)))
|
|
}
|
|
|
|
entryPoint := uint64(0)
|
|
if len(mdmp.Modules) > 0 {
|
|
entryPoint = mdmp.Modules[0].BaseOfImage
|
|
}
|
|
|
|
p := &process{
|
|
mem: memory,
|
|
Threads: map[int]*thread{},
|
|
bi: proc.NewBinaryInfo("windows", "amd64"),
|
|
entryPoint: entryPoint,
|
|
breakpoints: proc.NewBreakpointMap(),
|
|
pid: int(mdmp.Pid),
|
|
}
|
|
|
|
for i := range mdmp.Threads {
|
|
th := &mdmp.Threads[i]
|
|
p.Threads[int(th.ID)] = &thread{&windowsAMD64Thread{th}, p, proc.CommonThread{}}
|
|
}
|
|
var currentThread proc.Thread
|
|
if len(mdmp.Threads) > 0 {
|
|
currentThread = p.Threads[int(mdmp.Threads[0].ID)]
|
|
}
|
|
return p, currentThread, nil
|
|
}
|
|
|
|
type windowsAMD64Thread struct {
|
|
th *minidump.Thread
|
|
}
|
|
|
|
func (th *windowsAMD64Thread) pid() int {
|
|
return int(th.th.ID)
|
|
}
|
|
|
|
func (th *windowsAMD64Thread) registers() (proc.Registers, error) {
|
|
return winutil.NewAMD64Registers(&th.th.Context, th.th.TEB), nil
|
|
}
|