[haiku-bugs] Re: [Haiku] #5263: could not create mutex
- From: "bonefish" <trac@xxxxxxxxxxxx>
- Date: Sat, 24 Apr 2010 11:31:07 -0000
#5263: could not create mutex
---------------------------+------------------------------------------------
Reporter: mmadia | Owner: axeld
Type: bug | Status: new
Priority: normal | Milestone: R1
Component: System/Kernel | Version: R1/Development
Keywords: | Blockedby:
Platform: All | Blocking:
---------------------------+------------------------------------------------
Comment(by bonefish):
Replying to [comment:1 kaliber]:
> Is it possible to solve the availability problem of semaphores? I have
to increase their number from 40960 to 102400 (src/build/libroot/sem.cpp)
because I have to copy a lot of files in fs_shell.
Since semaphores are a kernel resource (at least under Haiku), they need
to be limited. The limit could be increased, of course, but I think it's
an fs_shell bug, if that many semaphores are used. The only dynamic use of
semaphores is associated with vnodes and the number of unused vnodes is
limited to 16 in the fs_shell. So there's probably a leak somewhere (maybe
vnode references).
Replying to [comment:4 mmadia]:
> r36423-r1a2-rc. Found one way to reproduce this. add an "exit 1" inside
build_haiku_image, so far mine have been within extractFile(). When
building a raw image, that exit 1 will cause bfs_shell to stick around in
memory. Once 3~5 stray processes are hanging about, jam -q @alpha-raw will
echo the "could not create mutex". Each time, vision does disconnect.
Using ProcessController on the stray bfs_shell's will return the system to
normal.
The fact that one process uses that many semaphores is one problem, but
this is a different issue. Obviously the bfs_shell process shouldn't stick
around after the script terminates. Unfortunately with the current
communication mechanisms (UNIX sockets respectively BeOS ports) the
bfs_shell cannot know when it is no longer needed and therefore needs to
be told explicitly. In the explicit "exit" cases that could be done
easily, but the "set -o errexit" makes it complicated. Maybe it is
possible to install some generic exit callback -- I know that it is
possible to install signal callbacks at least.
Alternatively the communication mechanism could be changed. E.g. to use
named pipes. The shell would open the pipe and when it quits the pipe
would be closed automatically, thus indicating to the bfs_shell that it
should quit.
--
Ticket URL: <http://dev.haiku-os.org/ticket/5263#comment:5>
Haiku <http://dev.haiku-os.org>
Haiku - the operating system.
Other related posts:
