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. Any help is appreciated Sincerely Bernhard -- Minds are like parachutes They only function when open
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
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@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
-- Minds are like parachutes They only function when open
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@brainfood.homelinux.org> 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@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
-- Minds are like parachutes They only function when open
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Hello, thank you for having a look at my problem. Any idea how I can find out what library is doing it and how it is triggered ? Sincerely Bernhard On Wed, September 9, 2009 16:24, Kevin Kassil wrote:
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@brainfood.homelinux.org> 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
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
On Mon, September 7, 2009 23:41, Václav Haisman wrote: 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@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
-- Minds are like parachutes They only function when open
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
-- Minds are like parachutes They only function when open
On Wed, Sep 09, 2009 at 07:15:13PM +0200, Bernhard Duebi wrote:
thank you for having a look at my problem. Any idea how I can find out what library is doing it and how it is triggered ?
compile your program with debug symbols (-g) and attach to it with the debugger (dbx -p <pid>) once it enters the loop. Then examine the stack back-trace and see where it's stuck and how it got there.
Hi, On 2009-09-08, Bernhard Duebi <boost@brainfood.homelinux.org> wrote:
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 norm= al user. The behaviour is the same in both files. Both files are incomplete because the program hangs in an endless loop.
does it make a difference if you supply --catch_system_errors=no at the command line (to the test program)? Best regards Georg
On Wed, September 9, 2009 23:06, Georg Sauthoff wrote:
Hi,
On 2009-09-08, Bernhard Duebi <boost@brainfood.homelinux.org> wrote:
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 norm= al user. The behaviour is the same in both files. Both files are incomplete because the program hangs in an endless loop.
does it make a difference if you supply --catch_system_errors=no at the command line (to the test program)?
Not realy, the process-tree-walk is still there and loops endless. See attached truss file... -- Minds are like parachutes They only function when open
AMDG Bernhard Duebi wrote:
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.
Can you post the code? In Christ, Steven Watanabe
participants (1)
-
Bernhard Duebi -
Georg Sauthoff -
Kevin Kassil -
Steven Watanabe -
Václav Haisman -
Zeljko Vrba