Hi,
On Thu, Nov 26, 2020 at 5:15 AM Lucas Nussbaum <lu...@debian.org> wrote:
> > The relevant part is near "FAIL:"
> >
> > === RUN TestIssue1374
> > proc_test.go:112: failed assertion at proc_test.go:4211: Call -
> > could not restore registers: bad address
> > --- FAIL: TestIssue1374 (0.62s)
> >
> >
> > However as delve was just built by buildd 11hour ago, and on my
> > desktop. So this seems a corner case triggered by your environment.
> > Hence I downgrade the severity.
> >
> > I guess the difference between buildd, my desktop and your env is real
> > hardware and VM.
> > Since delve is a debug tool, like gdb, probably the failed tests are
> > using some extreme methods which are restricted by VM.
>
> I tried to build this package in another environment (standard sbuild,
> not a VM) and could reproduce a build failure (but I'm not sure it's the
> same issue). Could you maybe post a build log and diff it with mine so
> that we can track down what differs?
>
> I'm attaching a build log from today.
>
It's a new issue. The error is different from the previous one
=== RUN TestStepIntoWrapperForEmbeddedPointer
support.go:248: enabling recording for
github.com/go-delve/delve/pkg/proc_test.TestStepIntoWrapperForEmbeddedPointer
support.go:248: enabling recording for
github.com/go-delve/delve/pkg/proc_test.TestStepIntoWrapperForEmbeddedPointer
proc_test.go:488: Program did not continue to correct next
location expected 19 was ifaceembcall.go:28 (0x49aa62) (testcase 3)
--- FAIL: TestStepIntoWrapperForEmbeddedPointer (1.12s)
=== RUN TestStarlarkVariable
starlark_test.go:160: for "v = eval(None, \"f1\").Variable; print(v.Value)"
expected "3"
got "3.0"
--- FAIL: TestStarlarkVariable (0.39s)
I have pushed a fix to salsa, should I just close this bug, or you
prefer cloning a new one?
https://salsa.debian.org/go-team/packages/delve/-/commit/5d77e7f46cb38bd2be5f9e0c12302541f0a02cb3
--
Shengjing Zhu
