[Gc] Solaris (PROC_VDB) and fork()

Shiro Kawai shiro at lava.net
Tue Nov 1 21:29:08 PST 2005


I'm tracking a problem of live objects being collected under
Solaris 5.9, and needs some help of Solaris proc data file
experts.  I'm using gc6.5, but the code I'm looking at isn't
changed in gc7.0alpha5.  I'm using pthreads, incremental
collection, and LARGE_CONFIG.

The symptom is that the objects pointed by .data section of
a dlopened file are collected, even the .data section is
in the root set (GC_print_static_roots() shows the section).

Tracking the problem, I found that the bits in GC_written_pages
corresponding to the data section isn't set, so the section
isn't marked, for GC_page_was_ever_dirty returns false for
the region.  More specifically, the process forks before the
GC is kicked, and GC_read_dirty in the child process (called
first) correctly sees the data section dirty, while GC_read_dirty
in the parent process (called later) sees the data section isn't
dirty.

The execution of the problematic program goes like this:

  program start
    some code     ----[1]
    dlopen()
    write to .data section of DSO
    fork()
     |-----------------------\
     \[parent]                \[child]
                                  some code ---[2]
       some code   ----[3]

GC is initiated at the point [1], [2] and [3].  The problem
arises in the second and third GC.  I inserted some dump code
in GC_read_dirty and found that reading form GC_proc_fd from
the child process at [2] sees the pages of the .data section
is dirty, the reading from GC_proc_fd in the parent process at
[3] sees those dirty bits cleared.

I couldn't find a document referring the semantics of fork()
and the process data file descriptor obtained by PIOCOPENPD,
but is it possible that the child's reading from the same
file descriptor affects the parent's reading from it?  

--shiro


More information about the Gc mailing list