The opendir and closedir/free_dircookie hooks were called with
mismatched vnode. It seems only googlefs is actually affected by this,
since all other fs without a get_vnode_name just don't are about the
passed vnode arg to closedir and free_dircookie.
Now I should really get some sleep!
This depends on quite a nasty hack to generate those, namely using
inline assembly to generate a file with things that are not actually
assembly, which Clang therefore filters out.
See http://www.freelists.org/post/haiku-development/Unifying-visuals-of-BTabView-usage
Besides the tab bar going the full width of the window, also some
layouting tweaks to several apps and prefs.
Still missing: the first (and last) tabs in the tab bar should be inset by
B_USE_WINDOW_SPACING so the controls in the tab view line up nicely.
I think I remember stippi wanting to look into it... :)
* This removes the CenteredViewContainer class, as it is no longer
being used.
* However, it also removes its functionality, ie. the Sudoku view now
fills the complete window (even without any borders), again.
The lock was only acquired when paths to watch were added or removed,
protecting the data structures against concurrent modification due
to addition/removal of entries by the API user.
Locking is also required for node monitor messages since these can
trigger the data structures to be modified (due to recursive watching
and new directories becoming available or due to resyncing of modified
ancestor chains).
Previously it was possible to corrupt the data structures when node
monitor messages were received while still starting to watch a directory
structure. This was especially likely in the case of watching devfs
directories, as accessing these can trigger device scanning which in
turn could possibly add new device entries. Either the path monitor
looper or the API user would then trip over the corrupted data
structures.
Probably fixes#11280. Although I was only able to reproduce crashes
on the API side, corruption of the hash tables and corresponding endless
loops are quite plausible.
Possibly also fixes#12412 if the input_server was in the process of
starting to watch entries. It's hard to tell due to the lack of a back
trace but would fit the crashes I was able to reproduce with a synthetic
test case.
Reduce duplication of code by
* Removing from elf_common.h definitions available in os/kernel/elf.h
* Deleting elf32.h and elf64.h
* Renaming elf_common.h to elf_private.h
* Updating source to build using public and private ELF header files
together
Signed-off-by: Jessica Hamilton <jessica.l.hamilton@gmail.com>
