Otonom bir kaldırım robotu geliştiren mühendis, haftalarca sorunsuz çalışan robotunun aniden donmaya başlamasıyla karşılaştı. LiDAR akışını WebRTC üzerinden ekledikten sonra, robot yaklaşık 16 saniye sonra tamamen duruyor, ancak çökme veya hata vermiyordu. Bu durum, kontrol döngüsünün kritik önem taşıdığı bir sistem için ciddi bir problemdi.
Mühendis, sorunu çözmek için çeşitli yöntemler denedi. tokio'nun döngüyü aç bırakması, async mutex kullanımı veya döngünün yanlış bir iş parçacığında çalışması gibi olasılıkları araştırdı ancak hiçbiri işe yaramadı. Hatanın tutarlı bir şekilde aynı noktada, 1615. iterasyonda meydana gelmesi, sorunun yavaşlamadan ziyade bir kilitlenme olduğunu düşündürdü. Bir "kalp atışı" iş parçacığı ekleyerek döngünün gerçekten takılıp kaldığını doğruladı.
Büyük silahları devreye sokarak GDB ile hata ayıklama sürecine girdi. GDB, robotun bir mutex üzerinde beklediğini gösterdi. Diğer iş parçacıklarını incelerken, kendisinin oluşturmadığı dört adet "Rayon worker" iş parçacığı keşfetti. rerun adlı görselleştirme SDK'sının dahili olarak rayon kullandığı ortaya çıktı. Mühendis, bir mutex'i tutarken recorder.log() fonksiyonunu çağırdığı için, rayon'un iş çalma iş parçacıkları, zaten tutulan kilidi gerektiren işi "yardımcı olmaya" çalışırken kilitlenmeye neden oluyordu. Çözüm, mutex'i daha kısa süre tutmak ve recorder.log() çağrısını kilidi bıraktıktan sonra yapmaktı. Bu 8 saatlik hata ayıklama süreci, sadece iki satır kod değişikliğiyle çözüldü.
Bir bağımlılığın içindeki beklenmedik iş parçacığı havuzlarının, uygulamanın kendi iş parçacığı modeliyle çakışarak karmaşık kilitlenme sorunlarına yol açabileceğini gösteriyor.