[haiku-bugs] [Haiku] #12703: Anomalous/incorrect behavior of get_team_info() in conjunction with start_watching_system()

  • From: "anevilyak" <trac@xxxxxxxxxxxx>
  • Date: Sun, 03 Apr 2016 02:38:21 -0000

#12703: Anomalous/incorrect behavior of get_team_info() in conjunction with
start_watching_system()
---------------------------+------------------------------
 Reporter:  anevilyak      |        Owner:  bonefish
     Type:  bug            |       Status:  new
 Priority:  normal         |    Milestone:  Unscheduled
Component:  System/Kernel  |      Version:  R1/Development
 Keywords:                 |   Blocked By:
 Blocking:                 |  Has a Patch:  0
 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.

--
Ticket URL: <https://dev.haiku-os.org/ticket/12703>
Haiku <https://dev.haiku-os.org>
Haiku - the operating system.

Other related posts: