#12286: Menus seem to be leaking ports
-------------------------------------+----------------------------
Reporter: ttcoder | Owner: axeld
Type: bug | Status: new
Priority: blocker | Milestone: R1/beta1
Component: Servers/launch_daemon | Version: R1/Development
Resolution: | Keywords:
Blocked By: | Blocking:
Has a Patch: 0 | Platform: All
-------------------------------------+----------------------------
Comment (by ttcoder):
@jackburton the `if (fMsgPort >= 0 && fOwnsPort)` only triggers the
close_port() if `fOwnsPort`==true, that should be the right logic?
Anyway I fessed up and actually built a libbe.so right away, with some
tracing added, and that allows to pinpoint the problem at
'''close_port()''', if I'm not mistaken: it seems it ''is'' called, but it
does ''not'' succeed in closing the port, even though it returns B_OK.
- if it's commented out, opening a menu allocates 3 ports, closing it
frees only 2 ports.
- if it's commented in as normal, opening a menu allocates 3 ports,
closing it frees only 2 ports -- no change whatsoever !
I looked at the kernelland create_port() code out of curiosity to see how
it could fail yet still return 0x0 but I don't "see" it.. And out of my
pool depth of course.
To double-check what I did, here's a sample session showing the be_app
looper, the BWindow looper, and the BMenu opened and closed twice:
{{{
/boot/system/cache/tmp/New folder> ./Mouse
BLooper ctor 0x72e86400
BLooper ctor 0x18859698
BLooper ctor 0x188c6430
BLooper DTOR 0x188c6430 with fOwnsPort=1
dtor: close_port(6091) returns 0
BLooper ctor 0x188e2430
BLooper DTOR 0x188e2430 with fOwnsPort=1
dtor: close_port(6094) returns 0
BLooper DTOR 0x18859698 with fOwnsPort=1
dtor: close_port(6088) returns 0
BLooper DTOR 0x72e86400 with fOwnsPort=1
dtor: close_port(6085) returns 0
/boot/system/cache/tmp/New folder> ls -R
.:
lib Mouse
./lib:
libbe.so
}}}
--
Ticket URL: <https://dev.haiku-os.org/ticket/12286#comment:25>
Haiku <https://dev.haiku-os.org>
Haiku - the operating system.
