Bug#666525: culprit located as dpkg-architecture ?

[Yann Dirson]

Running a build with systemtap set to intercept:
* calls to mkdir() as root under ccache
* mkdir failures with EACCESS

... reveals quite constant shape of the process tree leading to the
suspect mkdir's, and strong correlation with the EACCESS problems (and
with the actual ccache subdirs owned by root, as expected):

$ stap /work/yann/deb/cssc/mkdir.stap
go...
mkdir /work/pbuilder/ccache/tmp
process traceback:
  gcc(32018) sh(32017) dpkg-architectu(32016) pbuilder-satisf(32015) pbuilder-satisf(32014) pbuilder-buildp(30987) pbuilder(30986) sudo(30985) pdebuild(29971) bash(4485) screen(4306)
mkdir /work/pbuilder/ccache/2
process traceback:
  gcc(32018) sh(32017) dpkg-architectu(32016) pbuilder-satisf(32015) pbuilder-satisf(32014) pbuilder-buildp(30987) pbuilder(30986) sudo(30985) pdebuild(29971) bash(4485) screen(4306)
mkdir /work/pbuilder/ccache/2/4 => EACCESS
mkdir /work/pbuilder/ccache/2/5 => EACCESS
mkdir /work/pbuilder/ccache/2/d => EACCESS
mkdir /work/pbuilder/ccache/2/6 => EACCESS
mkdir /work/pbuilder/ccache/2/e => EACCESS
mkdir /work/pbuilder/ccache/2/e => EACCESS
...


dpkg-architecture launching gcc ?  Now that's a funny surprise :)

I hope this information will be of some help...
-------------- next part --------------

probe begin { println("go...") }

probe syscall.mkdir.return {
    err = errno_p(returnval())
    if (err == 13) {
        println("mkdir ", kernel_string($pathname), " => EACCESS")
    }
}

probe syscall.mkdir {
    if ((uid() == 0) && isinstr(pathname, "/ccache/")) {
        println("mkdir ", kernel_string($pathname))
        printf("process traceback:\n %s\n", pstrace(task_current()))
    }
}