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?



>> 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.

Thanks Ben. Can I ask for more detail? I was looking at the
Create_Process() method here:
http://condor-wiki.cs.wisc.edu/index.cgi/fileview?f=src/condor_daemon_co
re.V6/daemon_core.cpp&v=6405f9d882299b5db21aba06a782773c5aa72cc3

And it'd be nice to reference a flag (or an absence of a flag) and the
MS API docs that show this is the case. My Windows thread spawning
knowledge isn't as complete as my POSIX thread spawning knowledge.

I guess this is getting more MS-specific than Condor-specific. I was
reading: http://msdn.microsoft.com/en-us/library/ms682425.aspx trying to
understand this better.

Is it that CreateProcess() forks a new thread that doesn't see the
shared memory space of the parent so it loads its own DLLs? Or is it one
of the flags passed like CREATE_NEW_CONSOLE that causes this behaviour?

> 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.

I've suggested the use of Dependency Walker to them to help convince
themselves it's not a because-Condor-ran-this-job problem.

Thanks!

- Ian

Confidentiality Notice.
This message may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient, you are hereby notified that any use, disclosure, dissemination, distribution,  or copying  of this message, or any attachments, is strictly prohibited.  If you have received this message in error, please advise the sender by reply e-mail, and delete the message and any attachments.  Thank you.