[Mono-bugs] [Bug 75923][Nor] Changed - Mono compilation leaks semaphores

[bugzilla-daemon at bugzilla.ximian.com]

Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

Changed by caelian at gmail.com.

http://bugzilla.ximian.com/show_bug.cgi?id=75923

--- shadow/75923	2005-08-28 04:00:34.000000000 -0400
+++ shadow/75923.tmp.29102	2005-08-28 23:17:59.000000000 -0400
@@ -2,13 +2,13 @@
 Product: Mono: Runtime
 Version: 1.1
 OS: other
 OS Details: FreeBSD 5.4-RELEASE-p6
 Status: NEW   
 Resolution: 
-Severity: 
+Severity: Unknown
 Priority: Normal
 Component: io-layer
 AssignedTo: mono-bugs at ximian.com                            
 ReportedBy: tmclaugh at sdf.lonestar.org               
 QAContact: mono-bugs at ximian.com
 TargetMilestone: ---
@@ -76,6 +76,43 @@
 ------------------------------------------------------------------------
 [tom at compass tom]$ ipcs -bst
 Semaphores:
 T     ID     KEY        MODE       OWNER    GROUP NSEMS    OTIME    CTIME
 s 196608 1294723677 --rw-------     root    wheel      8  3:02:58  3:01:23
 ------------------------------------------------------------------------
+
+------- Additional Comments From caelian at gmail.com  2005-08-28 23:17 -------
+Well .. i have to admit first hand i don't have much experience with
+semaphores myself but ...
+
+I have been combing through the mono sources for several hours by now
+.. (mostly the io-layer and libgc .. as they basically seem to be the
+only two parts that actually seem to use semaphores) and so far i have
+started wondering a few things that i would really appreciate some
+clarification on.
+
+I see there's two different mechanisms of acquiring semaphores being
+used .. sem_init for unnamed semaphores and  semget for named
+semaphores to use in IPC.
+
+For most of the sem_init() calls i have been able to identify a
+seemingly appropriate sem_destroy() call to clean up the semaphore
+though i am not 100% sure every sem_init() Indeed has a matching
+sem_destroy().
+
+The thing that struck me as extremely strange though is the fact that
+the only occurances of semctl(..., IPC_RMID) i have encountered in the
+entire mono tree are for documented "error cases" ... however i can't
+find even a SINGLE non-error-case semctl(..., IPC_RMID) call in the
+Entire mono tree that will actually clean up these semget() created
+semaphores.
+
+If somebody more knowledgable on the concept of semaphores could
+explain to me the relationships between all the sem_get() and
+sem_destroy() calls that would be appreciated.
+
+The biggest concern here obviously is the semget()/semctl() scenario
+though ... unless i completely miss something extremely obvious, can
+somebody please explain to me how we ever expect Not to leave
+semaphores behind .. if we Never actually clean them up with the
+appropriate semctl(..., IPC_RMID) call ?
+