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

Error running tests #43

Closed
epipho opened this issue Jan 20, 2015 · 5 comments
Closed

Error running tests #43

epipho opened this issue Jan 20, 2015 · 5 comments

Comments

@epipho
Copy link
Contributor

epipho commented Jan 20, 2015

Tests are failing on master and I have not yet found a cause.

new thread spawned 1476
new thread spawned 1477
new thread spawned 1487
new thread spawned 1488
Hello, World!
new thread spawned 1497
new thread spawned 1498
new thread spawned 1508
new thread spawned 1534
new thread spawned 1535
new thread spawned 1536
foo
Hello, World!
foo
foo
Hello, World!
new thread spawned 1545
new thread spawned 1555
new thread spawned 1556
new thread spawned 1565
--- FAIL: TestVariableFunctionScoping (1.22s)
        proctl_test.go:52: Continue() returned an error : could not get registers could not get registers no such process
new thread spawned 1580
new thread spawned 1581
FAIL
FAIL    github.com/derekparker/delve/proctl     10.588s
@derekparker
Copy link
Member

Yeah, it seems to be a flickering failure but it's definitely there. I'll look into it, I may have an idea why this is happening.

@derekparker
Copy link
Member

So, for some reason on my laptop (Debian Jessie running kernel 3.17) the tests pass fine 99% of the time, with occasional, but rare flickers. However, on an Ubuntu 14.10 vm I have the tests always seem to fail consistently on master.

I'm going to investigate this more and try and figure out what is causing master to fail on certain machines, and under what circumstances.

@epipho
Copy link
Contributor Author

epipho commented Jan 22, 2015

It seems to always fail on both VMs for me (Ubuntu 14.04 and CoreOS 561)

@derekparker
Copy link
Member

So, on the ubuntu VM that reproducibly fails, I have TestNext and TestVariableFunctionScoping failing consistently. I have tracked down why TestNext is failing, it's due to m.procid not being set correctly for a newly created thread. No idea why this is happening, I'm running go 1.4.1 on both my actual machine and on the VM and the VM fails whereas on my machine all tests pass with no problem.

Haven't dug into the TestVariableFunctionScoping failure yet, but it could be related.

@pnasrat
Copy link
Contributor

pnasrat commented Jan 30, 2015

I just tried on GCE on Operating System: CoreOS 575.0.0

@epipho what are you using as a host VM?

nclifton pushed a commit to nclifton/delve that referenced this issue Feb 24, 2021
* Create the correct rabbitmq vhosts and make sure services are connecting
to the right ones

* Update load-definition.json

* Update load-definition.json

Co-authored-by: Thomas <57207652+thomasburst@users.noreply.github.com>
abner-chenc pushed a commit to loongson/delve that referenced this issue Mar 1, 2024
This commit fixes a race condition between Delve and the runtime of the traced process. When a new thread is created in the traced process, Delve takes note of it and then continue both the new thread, and the thread that called clone. If Delve attempts to use data in `runtime.allm` before the new `m->procid` is set, errors occur. The errors are due to Delve assuming any m with a procid of 0 is the main thread of the process (due to how theGo runtime allocates M's, only `clone`d threads have procid properly set. This causes certain events (like `next`) to happen twice to the main thread, because 2 m's in `runtime.allm` have a `procid` of 0, and also causes various other issues that prevent proper thread coordination from Delve.

Fixes go-delve#43
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

No branches or pull requests

3 participants