Changes between Version 1 and Version 2 of Ticket #11280, comment 20


Ignore:
Timestamp:
Apr 8, 2015, 5:21:39 PM (9 years ago)
Author:
ttcoder

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #11280, comment 20

    v1 v2  
    11It's occuring right now on  my desktop, keeping it open in debugger in case someone wants me to try out a command?
    22
    3 I tried to step.. step.. step.. for a while  in debugger, and we never ever get out of GetAncestor(), I'm always either in node_ref::eq() or in GeAncestor().
     3I tried to step.. step.. step.. for a while  in debugger (as well as Run/Debug/Run a dozen times), and we never ever get out of GetAncestor(), I'm always either in node_ref::eq() or in GeAncestor().
    44
    55So I would theorize that..
    66- BOpenHashTable<AncestorHashDefinition>::Lookup() is inlined inside GetAncestor()
    77- the infinite loop culprit is inside (i.e. it's not caused by a continuous stream of B_ENTRY_CREATED messages)
    8 - thus the "root" so to speak, of the stoppage is either  [ http://cgit.haiku-os.org/haiku/tree/src/kits/storage/PathMonitor.cpp#n1394 this call] or [http://cgit.haiku-os.org/haiku/tree/src/kits/storage/PathMonitor.cpp#n1424 this call] and the actual guilty party (loop that never exists) would be that one: http://grok.bikemonkey.org/source/xref/haiku/headers/private/kernel/util/OpenHashTable.h#160
     8- thus the "root" so to speak, of the stoppage is either  [http://cgit.haiku-os.org/haiku/tree/src/kits/storage/PathMonitor.cpp#n1394 this call] or [http://cgit.haiku-os.org/haiku/tree/src/kits/storage/PathMonitor.cpp#n1424 this call] and the actual guilty party (loop that never exists) would be that one: http://grok.bikemonkey.org/source/xref/haiku/headers/private/kernel/util/OpenHashTable.h#160
    99
    1010Plausible?