Opened 4 years ago
Anomalous/incorrect behavior of get_team_info() in conjunction with start_watching_system()
|Reported by:||anevilyak||Owned by:||bonefish|
|Has a Patch:||no||Platform:||All|
In order to monitor teams being created/destroyed as part of some Debugger-related refactoring, I set up some code that uses the private start/stop_watching_system() APIs to be notified of those events, as be_roster only covers BApplications, and cannot be relied upon in the CLI case anyways.
However, something appears to be not entirely correct here, as there seems to be a relatively reliably reproducible case where the notifications arrives that a new team was created, and then turning around to retrieve the corresponding team's info succeeds, but the team_info struct in question only has the team_id itself filled in. The args are empty, image and thread count are 0 (though argc is surprisingly 1), and as such it's impossible to determine from said info what the launched app actually was. Waiting for a bit and requesting the info succeeds though, so it seems there's some race here on the kernel side. Attached a testcase that can relatively easily reproduce the problem. It can be compiled from the root of the Haiku tree using:
g++ -g testcase.cpp -Iheaders/private/system -Iheaders/private/kernel -o testcase -lroot
Running the program and then simply creating new Terminals repeatedly using the cmd+n Terminal shortcut will relatively reliably trigger it within 3-4 new Terminals here, and the code in question is set up to trigger a debugger call when the issue is detected. Interestingly, the actual team that exhibits the problem is quite reliably the one belonging to the newly created Terminal app itself, none of the bash, etc. subprocesses appear to wind up being affected.