Actually Beagle didn't crash at that time (not sure why crash window appeared) but later on started to use a lot of CPU when I tried to make another call:
In the first case, the crash was caused by WebRTC inside its own thread. I have no idea what happened. We could try to update WebRTC or check if there is some race condition - ie. stop being called before start? How fast were you?
In the second case, I see a lot of "presence" being handled and avatars being updated as well CAPS being refreshed. But there is also WebRTC thread starting peer connection and audio device. Maybe, if you were fast enough it caused race condition? Could you try to quantify how fast were you? I may need to add another protection against race conditions like that.
wojciech.kapcia@tigase.net commented 3 years ago
It was "split-second": call window opened and I clicked "diconnect" red button almost immediately (less than 2s I'd say). Interestingly enough call window was also delayed to shop up by 1-3s.
Andrzej Wójcik (Tigase) commented 3 years ago
The only possible cause, which I've found, was the initialization of the WebRTC connection after the window was closed. (That could happen in this case). Fix will be part of the next build.
wojciech.kapcia@tigase.net commented 3 years ago
I tried to test it and first attempt (call and disconnect was OK). Then I tried to do it faster so click on call button and quickly hit space. After 3-4 attempts it crashed again but I'm not sure if we dig deeper into this (seems like a border case, though previously it could have happened when my machine was running slower so I wouldn't have to do things that quickly). Feel free to close it if you deem it "good enough". Current stacktrace below (which seems to indicate some timing issue and possibly "easy" to hande exception?):