Re: [Boost-users] Solaris Container

Subject: Re: [Boost-users] Solaris Container
From: Kevin Kassil (k.kassil_at_[hidden])
Date: 2009-09-09 10:24:25

This code looks like a "Hello World" example out of boost test.

Not being familiar with the workings of boost test, I would nonetheless be
surprised if it interacted with a platform-specific interface such as
/proc.  Your co-worker is probably correct.  If something is walking your
/proc filesystem then it is probably a system library.

Other opinions?

Kevin

On Tue, Sep 8, 2009 at 11:38 AM, Bernhard Duebi <
boost_at_[hidden]> wrote:

> Hello,
>
> I attached the source off the test application and some truss output.
> There are two truss files from a physical machine, one as root and one as
> a normal user. In these files you can see what the application does, when
> it runs ok.
> There are two truss files from a container, one as root and one as a normal
> user. The behaviour is the same in both files. Both files are incomplete
> because the program hangs in an endless loop.
>
> I tried to find out more with apptrace and pstack, but the output didn't
> look very usefull to me. But if you can use this info, then I will send it
> to you.
> I also created a core file with gcore. If this file contains helpfull
> information for you I can send it to you.
>
> Sincerely
> Bernhard
>
> On Mon, September 7, 2009 23:41, Václav Haisman wrote:
> > Bernhard Duebi wrote, On 7.9.2009 22:06:
> >> Hello,
> >>
> >> I'm not a programmer, I'm only a system engineer, so please be gentle.
> >>
> >> One of our code producers compiled boost in a Solaris Zone/Container
> >> using
> >> SUN Studio. For testing he used a program called test. I guess it is
> >> part
> >> of the distribution. It tests if 2+2==4 with different calls to boost.
> >> The test program runs on real machines, but not in Containers.
> >>
> >> Looking at the output of truss I found a probable cause. The program
> >> climbs up the process tree using the proc filesystem until it reaches
> >> the
> >> root of the tree. In a real machine the init process has PID 1 and this
> >> seems the sign for the program to stop climbing. In a Container the
> >> zsched
> >> process has a random PID and its PPID is the same as the PID. This leads
> >> to an endless loop.
> >>
> >> In the test.cpp file there is not much code besides the add function and
> >> some calls to the boost library. So, I guess the process tree walk is
> >> done
> >> somewhere in the boost library. My fellow co-worker denies this
> >> strictly.
> >>
> >> As we both have no clue about boost, I want to ask you to sched some
> >> light
> >> on this incident.
> >> - Is it possible that boost does that process tree walk ?
> >> - Is this a known problem ?
> >> - Are there any hints how to solve this problem ?
> >>
> >> I talked to SUN and they say it's not their problem. There is no
> >> official
> >> whitepaper that requires that the init process always has PID 1.
> > Having the testcase or at least a list of libraries and the Boost calls
> it
> > uses would make it a lot easier to diagnose this.
> >
> > --
> > VH
> >
> > _______________________________________________
> > Boost-users mailing list
> > Boost-users_at_[hidden]
> > http://lists.boost.org/mailman/listinfo.cgi/boost-users
> >
>
>
> --
> Minds are like parachutes
> They only function when open
>
> _______________________________________________
> Boost-users mailing list
> Boost-users_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/boost-users
>