[v2,6/6,gdb/testsuite] Extend gdb.testsuite/lock.exp a bit more

Message ID 20260929110921.1910094-6-tdevries@suse.de
State New
Headers
Series [v2,1/6,gdb/testsuite] Add gdb.testsuite/lock.exp |

Checks

Context Check Description
linaro-tcwg-bot/tcwg_gdb_build--master-aarch64 success Build passed
linaro-tcwg-bot/tcwg_gdb_build--master-arm success Build passed
linaro-tcwg-bot/tcwg_gdb_check--master-arm success Test passed

Commit Message

Tom de Vries Sept. 29, 2026, 11:09 a.m. UTC
  The test-case gdb.testsuite/lock.exp contains a lock taken scenario, but it's
timing dependent, so while it's probable that the scenario is tested, is not
guaranteed.

Fix this by adding a scenario where we use the on_retry parameter to release
the lock.
---
 gdb/testsuite/gdb.testsuite/lock.exp | 23 +++++++++++++++++++++++
 1 file changed, 23 insertions(+)
  

Patch

diff --git a/gdb/testsuite/gdb.testsuite/lock.exp b/gdb/testsuite/gdb.testsuite/lock.exp
index 51859cb80db..9815dc25bbb 100644
--- a/gdb/testsuite/gdb.testsuite/lock.exp
+++ b/gdb/testsuite/gdb.testsuite/lock.exp
@@ -66,3 +66,26 @@  with_test_prefix "on retry return" {
     lock_file_release $res
     gdb_assert {![file exists $lockfile]} "Release lock"
 }
+
+# Scenario 4:
+# - acquire 1
+# - acquire 2 fails.  On retry, release 1.  Acquire 2 succeeds.
+# - release 2
+with_test_prefix "on retry unlock" {
+    set res [lock_file_acquire $lockfile]
+    gdb_assert {[file exists $lockfile]} "Acquire lock"
+
+    proc on_retry {} {
+	lock_file_release $::res
+	return 1
+    }
+
+    # Try to acquire the lock.  That should fail.
+    # Then on retry, release the lock.
+    # The next try to acquire the lock should succeed.
+    set res2 [lock_file_acquire $lockfile on_retry]
+    gdb_assert {[file exists $lockfile]} "Re-acquire lock"
+
+    lock_file_release $res2
+    gdb_assert {![file exists $lockfile]} "Release lock"
+}