HTCondor Project List Archives



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Condor-devel] Which manufacturer/version of C/C++ compiler didyou use?



Hi Ian:

> Something along the lines of: 6.8.6 is using GeneralWindowsAPI::foo()
> from the MS runtime library. So it gets loaded into memory. And when it
> spawn the thread that spawns the thread that eventually spawns the
> thread that runs our job the out-of-data foo() is being used instead of
> the new foo() that our software expects.
> 
> Now I'm fairly certain Condor isn't spawning the thread in the same
> process space that condor_starter or condor_startd is running in. Is
> this true?


Yes, in general we spawn the job's executable as a child process of
the starter.  Once we have executed it in the starter, the process
is on its own and will load its libraries in the same way it would if
run by hand.


> How can I demonstrate to this Director that Condor is giving the cmd it
> spawns it's own process space? So it loads its own DLLs? Here's a
> typical process tree for our jobs:


Process Explorer (from System Internals--now part of MS) will give you
a graphical tree of the process running on your system (it also allows
you to get all sorts of information about the process, like it's current
environment, running threads, etc.).

If you want a list of the DLLs used by your application the Dependency
Walker (free: http://www.dependencywalker.com/) will give you a 
break-down of all the DLLs the application loads at runtime.


> But I really want to end this type of dialog once and for all. Any help
> here to help me show that Condor isn't forcing the cmd's it spawns to
> inherit its runtime linking dependencies is greatly appreciated.


Hope the above helps clear the air for you.  I you need anything more,
ask away :)

Regards,
-B