[haiku-bugs] Re: [Haiku] #12317: Debugger (silent?) crash, incomplete report

  • From: "anevilyak" <trac@xxxxxxxxxxxx>
  • Date: Thu, 20 Aug 2015 21:23:39 -0000

#12317: Debugger (silent?) crash, incomplete report
-------------------------------------+----------------------------
Reporter: ttcoder | Owner: anevilyak
Type: bug | Status: closed
Priority: normal | Milestone: Unscheduled
Component: Applications/Debugger | Version: R1/Development
Resolution: invalid | Keywords:
Blocked By: | Blocking:
Has a Patch: 0 | Platform: All
-------------------------------------+----------------------------
Changes (by anevilyak):

* status: new => closed
* resolution: => invalid


Comment:

Replying to [comment:7 ttcoder]:

Discussion (to continue in a new /clean ticket maybe):
- wouldn't it be better if the kernel "held tight" on the crashed
thread, instead of letting it go ?

That presents its own problems, since in the case where something goes
wrong, that leaves you with a permanently unkillable thread without a
reboot.

- if it isn't, how could Debugger give a hint about what happened ?
Seeing a list of threads with no indication of any of them being stopped
gives the (false) impression that the Debugger report is spurious and the
team did not really crash. We probably don't want that.

All the Debugger knows is the kernel told it the thread exited, so there's
no way for it to differentiate that. That having been said, to be
perfectly blunt, the attached code sample is pretty much a case study in
how not to do things.
- `kill_thread()` should never be getting used as a matter of course by
application code, it exists as a last resort, and only that, since among
other things, any resources the thread may have allocated would have been
leaked in such a case, i.e. any memory/objects/sockets allocated by
ntp_update_time(), and in fact, could potentially even cause
issues/corruption for future invocations within the same team.
`kill_thread()` exists solely for the use of tools like `kill` or
`ProcessController`. Furthermore, since Haiku is currently single user,
any mistake can potentially result in it killing threads in other teams,
leading to other unpredictable behavior.
- The way UpdateSystemTime() currently works is pretty horribly broken, as
it will result in the aforementioned condition getting triggered if
there's any transient network lag or temporary loss in connectivity, and
as such, if this is being run periodically will cause the hosting
application to leak resources over time, eventually leading to other code
randomly failing.
- Last but not least, loading an image as an add-on that isn't designed to
be, such as an application image, is asking for trouble. That will cause
global constructors/destructors to be called, which, if there are global
and/or static variables involved, could potentially mess with the internal
state of the calling application. Since all the source code in question is
available, if you really want to use it this way, it would make more sense
to simply pull that code into your own function and call it directly
rather than the series of messy kludges used here. Alternatively,
submitting a patch that pulls the ntp functionality into a
daemon/standalone app that could be invoked by others would also be nice.

All in all, you're pretty much causing your own problems here in many
ways, and I really don't see any good reason to go out of the way to
accommodate such a situation.

--
Ticket URL: <https://dev.haiku-os.org/ticket/12317#comment:8>
Haiku <https://dev.haiku-os.org>
Haiku - the operating system.

Other related posts:

  1. Home
  2. haiku-bugs
  3. Archive
  4. 08-2015