Bug 74903
| Summary: | devel/valgrind[-snapshot]: Fix lockup in state ``umtx'' on FreeBSD 5.3 | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Ports & Packages | Reporter: | Simon Barner <barner> | ||||||
| Component: | Individual Port(s) | Assignee: | freebsd-ports-bugs (Nobody) <ports-bugs> | ||||||
| Status: | Closed FIXED | ||||||||
| Severity: | Affects Only Me | CC: | pav | ||||||
| Priority: | Normal | ||||||||
| Version: | Latest | ||||||||
| Hardware: | Any | ||||||||
| OS: | Any | ||||||||
| Attachments: |
|
||||||||
State Changed From-To: open->closed Committed, thanks! |
Starting from some point after FreeBSD 5.2.1, valgrind did not terminate correctly, but got stuck in state ``umtx''. This was mentioned on the lists and in kern/68992 [closed], but I was never able to fix the problem. Today, I gave it another try, and it turned out to be quite simple (from the current perspective ;-): Since coregrind/vg_proxylwp.c did not include "vg_unsafe.h" (which in turn includes <sys/param.h>), the __FreeBSD_version macro was undefined. Thus the conditioned definition of the UMTX_CONTESTED constant has always taken place in the <= 5.2.1 way. Therefore, on FreeBSD >= 502120, the kernel's and valgrind's defintion of that flag were out of sync, which is why valgrind did not terminate on these systems. Btw: Pav, please regard this as a first step of closing ports/71832. I had some questions to the originator of that PR, and I thought it would be the best to provide him with a working version of valgrind ;-) How-To-Repeat: Run valgrind{-snapshot} on FreeBSD >= 502120, e.g. % valgrind --tool=memcheck true