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

Thread lock up #6771

Closed
vicuna opened this Issue Feb 4, 2015 · 13 comments

Comments

Projects
None yet
2 participants
@vicuna
Copy link
Collaborator

commented Feb 4, 2015

Original bug ID: 6771
Reporter: enrico
Assigned to: @xavierleroy
Status: closed (set by @xavierleroy on 2017-02-16T14:18:17Z)
Resolution: fixed
Priority: high
Severity: minor
Version: 4.01.0
Target version: 4.03.0+dev / +beta1
Fixed in version: 4.03.0+dev / +beta1
Category: platform support (windows, cross-compilation, etc)
Duplicate of: #5325
Related to: #4466
Monitored by: @gasche @diml @ygrek @hcarty

Bug description

Especially on windows (but also on Linux) it seems that:

  • at least 2 threads blocked on a read (at least 3 on linux)
  • some data is finally available on one of their fd, but no thread is woken up

Steps to reproduce

Test case in attachment. It is a stripped down Coq, sorry for the not exactly clean and readable code.

"server" spawns "client mitm" that in turn spawns "client".

The MITM runs two threads talking with server and client respectively.
The two threads communicate via a queue protected with a mutex and a condition.

On Linux things mostly work here, and rarely hang (and only if I add to the picture more threads). On my Windows 7 virtual machine the test case hangs systematically.

Additional information

This bug affects Coq 8.5beta1 (where a huge hack works around it).

File attachments

@vicuna

This comment has been minimized.

Copy link
Collaborator Author

commented Feb 5, 2015

Comment author: @mshinwell

Could you please provide a test case that hangs on Linux?

@vicuna

This comment has been minimized.

Copy link
Collaborator Author

commented Feb 5, 2015

Comment author: enrico

I'm pretty sure I've seen that hang on linux too, but I can't reproduce it now by adding more "bouncers" to the code I've attached.

@vicuna

This comment has been minimized.

Copy link
Collaborator Author

commented Feb 5, 2015

Comment author: @diml

If it only hangs on windows, could this be related to #5325?

@vicuna

This comment has been minimized.

Copy link
Collaborator Author

commented Feb 5, 2015

Comment author: enrico

Could be, on Windows we use sockets (the code I've attached can do with pipes too but on Windows we go for sockets). From the bug report you link it is
a bit unclear to me which OCaml version I could test in order to see it it solves the bug (on Win).

But I'm sure I've seen it hang on Linux too, even if today I cannot reproduce
it by playing with the small example I've attached.

@vicuna

This comment has been minimized.

Copy link
Collaborator Author

commented May 6, 2015

Comment author: @mshinwell

Damien is going to see if he can reproduce this on Windows.

@vicuna

This comment has been minimized.

Copy link
Collaborator Author

commented May 12, 2015

Comment author: @damiendoligez

Can't reproduce with the Cygwin version of OCaml. Will try with MSVC and Mingw.

@vicuna

This comment has been minimized.

Copy link
Collaborator Author

commented May 13, 2015

Comment author: @damiendoligez

Reproduced with MSVC.

@vicuna

This comment has been minimized.

Copy link
Collaborator Author

commented May 13, 2015

Comment author: enrico

Sorry for not being clear from the very beginning, I've been using the ocaml installer for windows available here: http://protz.github.io/ocaml-installer/

@vicuna

This comment has been minimized.

Copy link
Collaborator Author

commented May 14, 2015

Comment author: @damiendoligez

I'm pretty sure this is a duplicate of #5325: you have one thread blocked on read on a socket, and another thread tries to write, and blocks.

In your case, there is an easy workaround: use two sockets instead of one (see attached diff, which fixes the problem on your test case).

This bug won't be fixed before 4.02.2.

@vicuna

This comment has been minimized.

Copy link
Collaborator Author

commented Dec 4, 2015

Comment author: @xavierleroy

See proposed fix #331 Re-test most welcome.

@vicuna

This comment has been minimized.

Copy link
Collaborator Author

commented Dec 9, 2015

Comment author: @xavierleroy

Fix committed to trunk, will be in 4.03. Re-test most welcome.

@vicuna

This comment has been minimized.

Copy link
Collaborator Author

commented Dec 9, 2015

Comment author: @alainfrisch

I confirm that the attached example does not hang with trunk (tested with the MSVC 32 port).

@vicuna

This comment has been minimized.

Copy link
Collaborator Author

commented Dec 9, 2015

Comment author: @xavierleroy

Thanks a million for the re-test. We're making progress!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.