[v2,6/6,gdb/testsuite] Extend gdb.testsuite/lock.exp a bit more
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
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(+)
@@ -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"
+}