HB-relationship involving thread creations while mutexes are held by dabund24 · Pull Request #1913 · goblint/analyzer

dabund24 · 2026-01-17T15:53:03Z

second part of #1805. The first half was implemented in #1865.
closes #1805.

Summary

Simplest case: After creating $t_1$ in $t_0$ with mutex $l$ held, succeeding statements until maybe unlocking in $t_0$ must happen before everything after definitely locking $l$ in $t_1$.

generalizations:

$t_1$ can be any descendant of $t_0$ as long as $t_0$ is a must-ancestor.
It doesn't matter if locking happens in $t_1$ or a must-ancestor as long as that thread is also a must-ancestor of the thread created in $t_0$

Examples

In the following examples, A must happen before B.

Simple example

graph TB;
subgraph t1;
    E["lock(l);"]-->F;
    F["unlock(l);"]-->G;
    G((B))
end;
subgraph t0;
    A["lock(l);"]-->B;
    B["create(t1);"]-->C;
    C((A))-->D;
    D["unlock(l);"];
end;
B-.->E

`B` in a descendant of $t_1$

graph TB;
subgraph t2;
    H((B))
end;
subgraph t1;
    E["lock(l);"]-->F;
    F["create(t2);"]
end;
subgraph t0;
    A["lock(l);"]-->B;
    B["create(t1);"]-->C;
    C((A))-->D;
    D["unlock(l);"];
end;
B-.->E
F-.->H

`A` in a descendant of $t_0$

Note

This case is not covered by the analysis implemented in this Pull Request, but may be added some time later

graph TB;
subgraph t1;
    E["lock(l);"]-->I;
    I["unlock(l);"]-->F;
    F((B));
end;
subgraph t2;
    H((A))
end;
subgraph t0;
    A["lock(l);"]-->B;
    B["create(t1);"]-->C;
    C["create(t2);"]-->D;
    D["join(t2);"]-->G;
    G["unlock(l);"]
end;
B-.->E
C-.->H
H-.->D

Here, it is important that no unlock happens in $t_0$ before $t_2$ is joined into $t_0$, which was computed in #1865.

Dependency Analyses

$t_{\mathrm{ego}}$: Ego Thread Id at program point
$\mathcal L$: Must-Lockset at program point
$\mathcal C$: May-Creates of ego thread before program point
$\mathcal J$: Transitive Must-Joins of ego thread before program point
$\mathcal{DES}\ t$: Descendant threads of $t$ (implemented in this PR)
$\mathcal{ANC}\ t$: Must-ancestors of $t$

From these analyses, we compute:

Given a statement create(t) all threads transitively created, for which $t_{\mathrm{ego}}$ is a must-ancestor:
$$c^* \ t:= \set{t _ d\mid t _ d\in \set{t} \cup \mathcal{DES}\ t, t_{\mathrm{ego}}\in\mathcal{ANC}\ t_d}$$
All possibly running descendants, for which $t_{\mathrm{ego}}$ is a must-ancestor:
$$\mathcal{R}:= \set{t_ r\mid t_ r\in \left(\mathcal{C}\cup \bigcup{\set{\mathcal{DES} c\mid c\in\mathcal{C}}}\right)\setminus \mathcal J, t_{\mathrm{ego}}\in\mathcal{ANC}\ t_r}$$

Analyses

Descendant Locksets $\mathcal{DL}$

flow-sensitive
Domain: $T\to 2^L$
$T\to 2^L$ is MapBot
$2^L$ is Must-Set
$\mathcal{DL}=\set{t_1\mapsto \set{l}}$ means
There must have existed at least one create($t_c$) statement in $t_A$ with $t_B\in c^*\ t_c$.
For all of those create($t_c$) statements, $\mathit{l}\in\mathcal{L}$.
We must not have encountered an unlock($l$) statement after having detected the thread creation.

Transfer functions

$\mathsf{init}^\sharp = \emptyset$
$\mathsf{new}^\sharp\ X = \emptyset$
$[[\mathsf{create}(t)]]^\sharp\ X=X\sqcup\set{t_d\mapsto \mathcal{L}\mid t_d\in c^*\ t}$
$[[\mathsf{unlock}(l)]]^\sharp\ X=\set{t\mapsto L\setminus\set{l}\mid t\mapsto L\in X}$
$[[\mathsf{unlock}(?)]]^\sharp\ X=\set{t\mapsto \emptyset\mid t\mapsto L\in X}$

Mustlock History $\mathcal{LH}$

flow-sensitive
Domain: $L\to 2^T$
$T\to 2^T$ is MapTop
$2^T$ is Must-Set
$\mathcal{LH}=\set{l\mapsto \set{t}}$ means "before the next operation, mutex $l$ must have been locked in $t$"

Transfer functions

$\mathsf{init}^\sharp=\emptyset$
$\mathsf{new}^\sharp\ X=X$
$[[\mathsf{lock}(l)]]^\sharp\ X=X\oplus\set{l\mapsto (X\ l)\cup \set{t_{\mathrm{ego}}}}$

Global descendant lockset $\mathcal{DL}_g\ t$

flow-insensitive with V$=T$
Domain: $T\to T\to 2^L$
$T\to T\to 2^L$ and $T\to 2^L$ are MapBot
$\mathcal{DL}G\ t=\set{t{\mathrm{anc}}\mapsto DL}$ means "throughout the entire execution of $t$, the descendant lockset $DL$ is valid in $t_{\mathrm{anc}}$".

Contributions

We only contribute at create($t_c$) statements for all $t_d\in t^*\ t_c$:
$$DL_{t_d}:=\set{t\mapsto (\mathcal{DL}\ t)\cap (\mathcal{CL}\ t_d\ t_{\mathrm{ego}})\mid t\in T}$$
$$\mathcal{DL}_ g\ t_ d\sqsupseteq \set{t_ {\mathrm{ego}} \mapsto DL_ {t_d}}$$

Happened-Before rules

Statement s2 with $\mathcal{LH}_ 2, t_2$ must happen after s1 with $\mathcal{DL}_ 1, \mathcal{LH}_ 1, t_1$, if:

$\exists t_2\mapsto L_a\in\mathcal{DL}_ 1, l_ {LH}\mapsto T_ {LH}\in \mathcal{LH}_ 1, t_ {LH}\in T_ {LH}:$
$l_{LH}\in L_a\land t_1\in \mathcal{ANC}\ t_{LH}\land(t_{LH}\in\mathcal{ANC}\ \mathcal t_2\lor t_{LH}=t_2)$ or
$\exists (t_X\mapsto DL_{t_1})\in\mathcal{DL}_ g\ t_1$ such that the rule above holds replacing $t_ 1$ by $t_ X$ and $\mathcal{DL}_ 1$ by $DL_ {t_1}$.

Copilot

Pull request overview

This PR implements the second part of happens-before (HB) relationship analysis for thread creations while mutexes are held. It introduces two new analyses (MustlockHistory and DescendantLockset) that work together to detect race conditions by establishing happens-before relationships between thread operations based on mutex locking patterns.

Changes:

Added MustlockHistory analysis to track which threads have locked specific mutexes
Added DescendantLockset analysis to compute descendant locksets and determine happens-before relationships
Extended CreationLockset analysis with query support for integration with the new analyses
Added 20 comprehensive test cases covering both race-free and racing scenarios

Reviewed changes

Copilot reviewed 21 out of 21 changed files in this pull request and generated 9 comments.

Show a summary per file

File	Description
`src/analyses/mustlockHistory.ml`	New analysis tracking mutex lock history per thread
`src/analyses/descendantLockset.ml`	New analysis computing descendant locksets and HB relationships
`src/analyses/creationLockset.ml`	Added `CreationLockset` query support
`src/domains/queries.ml`	Added `CreationLockset` and `MustlockHistory` query types with supporting domains
`src/goblint_lib.ml`	Exported the two new analysis modules
`tests/regression/53-races-mhp/40-45-*.c`	Race-free test cases validating correct HB detection
`tests/regression/53-races-mhp/50-59-*.c`	Racing test cases validating race detection

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

… of descendant lockset analysis

michael-schwarz · 2026-01-20T15:18:47Z

Random thought: What do your analyses do for recursive mutexes? Are they sound in these cases?

dabund24 · 2026-01-20T16:30:51Z

Thanks for bringing this up, those would never have crossed my mind. I think the analyses remain sound, but get less precise.

The only relevant thing changing here coming to my mind is the fact that after an unlock, we can't assume anymore that the mutex is now unlocked. As unlock statements have been places in our analyses, where we assume things to just break, but not start/keep working, this wouldn't be an issue.

michael-schwarz · 2026-01-21T01:10:17Z

I think the analyses remain sound, but get less precise.

👍 Could you add tests here and maybe also include some tests for your first analysis (potentially in a separate PR)?

…kset` analysis

dabund24 · 2026-02-02T15:23:13Z

@DrMichaelPetter and I decided to remove the flow-insensitive analysis detecting cases like the third example, since we did not see a simple way of both having only monotonic contributions and being certain that the analysis is sound

michael-schwarz · 2026-02-02T15:29:27Z

Just so I can understand: why is monotonicity important here? @dabund24 @DrMichaelPetter

(By default (without update rule) globals are accumulated, so their values grow monotonically anyway)

dabund24 · 2026-02-02T15:52:34Z

What we did was pretty much copying a MapBot from the local analysis to the global analysis, where the (inner) domain is MapTop:

This felt problematic to me, since for example, if the local analysis also ever read from the global analysis (which it doesn't, but may at any time later on), the fixed-point iteration may never terminate. Maybe I am missing something here, though 🤔

michael-schwarz · 2026-02-02T16:07:03Z

I'm not deeply familiar with what exactly you're trying to do, but in general our fixpoint solvers can deal with non-monotonic right-hand sides without any issues.

====

Nothing wrong with copying values from a MapBot to a MapTop, though it usually doesn't do much for globals. If the binding is not present, it is assumed to be top, so contributing more to it will not really have much of an effect...

dabund24 · 2026-02-02T16:10:37Z

Thanks for remarking this. In that case, I'm going to undo the changes

michael-schwarz · 2026-02-02T16:17:13Z

No, please discuss with @DrMichaelPetter what he suggests before doing so.

… with thesis

dabund24 · 2026-02-23T12:23:12Z

I re-added the $\mathcal{DL}_g$ analysis, as using MapBot as the domain turned out to work fine when writing the thesis

michael-schwarz

Sorry for the stall here. I think we should now try to get this merged so it evolves with the rest of the system. Can you merge master into this (or rebase, whatever you prefer) and address the comments?

Then it should be good to merge!

michael-schwarz · 2026-05-05T11:00:09Z

@@ -0,0 +1,31 @@
+// PARAM: --set ana.activated[+] threadJoins --set ana.activated[+] threadDescendants --set ana.activated[+] mustlockHistory --set ana.activated[+] descendantLockset --set "ana.activated[+]" creationLockset


Suggested change

// PARAM: --set ana.activated[+] threadJoins --set ana.activated[+] threadDescendants --set ana.activated[+] mustlockHistory --set ana.activated[+] descendantLockset --set "ana.activated[+]" creationLockset

// PARAM: --set ana.activated[+] threadJoins --set ana.activated[+] threadDescendants --set ana.activated[+] mustlockHistory --set ana.activated[+] descendantLockset --set ana.activated[+] creationLockset

michael-schwarz · 2026-05-05T11:01:25Z

@@ -0,0 +1,36 @@
+// PARAM: --set ana.activated[+] threadJoins --set ana.activated[+] threadDescendants --set ana.activated[+] mustlockHistory --set ana.activated[+] descendantLockset --set "ana.activated[+]" creationLockset


"ana.activated[+]" creationLockset should be ana.activated[+] creationLockset here as well. Probably easiest to do with a search & replace.

michael-schwarz · 2026-05-05T11:03:28Z

+
+int main(void) {
+
+  int maybe;


With the goal of turning these into SV-COMP tests later, it may make sense to replace all occurences where we rely on uninitialized locals for non-determinism with the proper nondet functions.

michael-schwarz · 2026-05-05T11:10:32Z

+
+  (** [{ t_0 |-> { t_d |-> L } }]
+
+      [{ t_d |-> L }] is the descendant lockset valid for the [V] value,


What is [V] supposed to mean here?

michael-schwarz · 2026-05-05T11:12:34Z

+  module V = struct
+    include TID
+    include StdV
+  end


I think we have four instances of this now, maybe add a TIDV to analyses.ml?

michael-schwarz · 2026-05-05T11:16:34Z

+      if Lockset.is_bot locks_held_creating_t2
+      then false
+      else (
+        let relevant_lh2_threads =
+          Lockset.fold
+            (fun lock -> TIDs.union (Queries.LH.find lock lh2))
+            locks_held_creating_t2
+            (TIDs.empty ())
+        in
+        TIDs.exists
+          (fun t_lh ->
+             TID.must_be_ancestor t1 t_lh
+             && (TID.equal t_lh t2 || TID.must_be_ancestor t_lh t2))
+          relevant_lh2_threads)


The indentation is a little strange here. Also, I don't think you need the ( ) around the else case.

michael-schwarz · 2026-05-05T11:23:01Z

+(** descendant lockset analysis [descendantLockset]
+    analyzes a happened-before relationship related to thread creations with mutexes held.
+
+    Enabling [creationLockset] may improve the precision of this analysis.
+
+    @see https://github.com/goblint/analyzer/pull/1923
+*)


Maybe you should push your thesis to https://github.com/goblint/theses and then reference it here (and add something like "available upon request") until there's a formal publication.

Same for the other analyses from your thesis.

michael-schwarz · 2026-05-05T11:31:02Z

+    let tid_lifted = man.ask Queries.CurrentThreadId in
+    let child_tid_lifted = fman.ask Queries.CurrentThreadId in
+    match tid_lifted, child_tid_lifted with
+    | `Lifted tid, `Lifted child_tid when TID.must_be_ancestor tid child_tid ->


This implicitly checks uniqueness of tid. Could you elaborate why such a check is not needed for the child?

I was wondering about the case where two threads get the same non-unique id, but for one of the creations no mutex is held while one is held for the other?

main for(int i = 0; i < 2; i++) { if(i == 1) { lock(m) } create(thread1) // Both copies receive same TID } g = 42; //RACE! unlock(m)

thread1: lock(m) g = 8; // RACE! unlock(m)

Is this handled by the lockset being a must lockset? Do you have a test for this?

dabund24 added 4 commits January 15, 2026 13:07

mustlock history analysis

4f611d5

initial version of descendant lockset analysis

d4189b4

first descendant lockset racefree tests

4d5fee2

first descendant lockset racing tests

2cc4be9

dabund24 added feature student-job precision labels Jan 17, 2026

dabund24 mentioned this pull request Jan 17, 2026

Improve MHP precision using ancestor locksets #1865

Merged

dabund24 added 6 commits January 18, 2026 14:36

descendant lockset racing tests with multiple thread creations

470279f

creation lockset query

1f883f2

global descendant locksets

bb16da6

regression tests for global descendant locksets

8f46eb3

descendant lockset tests involving multiple mutexes

61cdb71

Merge branch 'master' into descendant-locksets

67a62bd

michael-schwarz requested a review from Copilot January 20, 2026 03:14

Copilot started reviewing on behalf of michael-schwarz January 20, 2026 03:14 View session

Copilot AI reviewed Jan 20, 2026

View reviewed changes

dabund24 added 7 commits January 20, 2026 10:17

fix incorrect indentatoin in regression test

c8cdf89

add missing return statement to regression test

6c68a6c

add missing mutex initializations

6020267

remove redundant whitespace in creation lockset analysis

5bf536d

remove unused tid function parameter in unlock and unknown_unlock…

bd388a2

… of descendant lockset analysis

modify global domain to use D instances as values

66ad3f1

Merge branch 'master' into descendant-locksets

d4aec37

recursive mutex regression tests for descendant locksets

743092a

dabund24 mentioned this pull request Jan 21, 2026

Recursive mutex regression tests for creation locksets #1928

Merged

Merge branch 'master' into descendant-locksets

b161fed

dabund24 commented Jan 25, 2026

View reviewed changes

Comment thread src/analyses/descendantLockset.ml Outdated

Comment thread src/analyses/descendantLockset.ml Outdated

Comment thread src/analyses/mustlockHistory.ml

dabund24 requested review from DrMichaelPetter, michael-schwarz and sim642 January 25, 2026 22:59

Merge branch 'master' into descendant-locksets

6785efa

dabund24 marked this pull request as ready for review January 25, 2026 23:00

dabund24 added 6 commits January 26, 2026 20:06

refactor functions related to thread descendants

a71d29e

locally abstract type for happens_before function in `descendantLoc…

be913ba

…kset` analysis

also print mustlock history in A of descendant lockset analysis

624254b

remove side effects analysis for descendant locksets

30d7daf

skip tests involving global descendant lockset analysis

9b40093

Merge branch 'master' into descendant-locksets

ba0cac3

dabund24 marked this pull request as draft February 5, 2026 13:14

dabund24 added 8 commits February 19, 2026 16:23

undo removal of descendant lockset analysis

9e8399e

undo skipping global descendant lockset regression tests

6827d4d

also use MapBot for global domain of descendant lockset analysis

ac2b66f

align definition of transfer functions of descendant lockset analysis…

b0e6f4b

… with thesis

use sticky set intersection in global descendant lockset analysis

6dd1f3c

add global descendant lockset regression tests with multiple creates

596cb68

threadenter of descendant lockset analysis

7e4f3d8

Merge branch 'master' into descendant-locksets

f3ba129

dabund24 marked this pull request as ready for review February 23, 2026 12:23

michael-schwarz requested changes May 5, 2026

View reviewed changes

		@@ -0,0 +1,31 @@
		// PARAM: --set ana.activated[+] threadJoins --set ana.activated[+] threadDescendants --set ana.activated[+] mustlockHistory --set ana.activated[+] descendantLockset --set "ana.activated[+]" creationLockset

		@@ -0,0 +1,36 @@
		// PARAM: --set ana.activated[+] threadJoins --set ana.activated[+] threadDescendants --set ana.activated[+] mustlockHistory --set ana.activated[+] descendantLockset --set "ana.activated[+]" creationLockset


		(** [{ t_0 \|-> { t_d \|-> L } }]

		[{ t_d \|-> L }] is the descendant lockset valid for the [V] value,

Conversation

dabund24 commented Jan 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Examples

Simple example

B in a descendant of $t_1$

A in a descendant of $t_0$

Dependency Analyses

Analyses

Descendant Locksets $\mathcal{DL}$

Transfer functions

Mustlock History $\mathcal{LH}$

Transfer functions

Global descendant lockset $\mathcal{DL}_g\ t$

Contributions

Happened-Before rules

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

michael-schwarz commented Jan 20, 2026

Uh oh!

dabund24 commented Jan 20, 2026

Uh oh!

michael-schwarz commented Jan 21, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

dabund24 commented Feb 2, 2026

Uh oh!

michael-schwarz commented Feb 2, 2026

Uh oh!

dabund24 commented Feb 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

michael-schwarz commented Feb 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

dabund24 commented Feb 2, 2026

Uh oh!

michael-schwarz commented Feb 2, 2026

Uh oh!

dabund24 commented Feb 23, 2026

Uh oh!

michael-schwarz left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

dabund24 commented Jan 17, 2026 •

edited

Loading

`B` in a descendant of $t_1$

`A` in a descendant of $t_0$

dabund24 commented Feb 2, 2026 •

edited

Loading

michael-schwarz commented Feb 2, 2026 •

edited

Loading