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

["Matt Hope" <Matt.Hope@xxxxxxxxxxxxxxx>]

Create process is entirely unlike creating a new thread and has none of
the fork like semantics from unix land.

The new process inherits:

The environment (so environment variables) and security related contexts
like the user (unless spoofed which it almost certainly is) and hence
sessions/desktops if they are present.

The way older versions of condor launched the new processes did IIRC
cause some differences related to how they spoofed the user and thus
what desktop/profile resources were accessible...

We never had too many problems with it before we went to 7 series so I
lost interest trying to work it out (the messages about this might be in
the logs I dod know that it used to use CreateProcessAsUser)

Are the machines in question 64bit (i.e. arch and os) that can be a
little problematic sometimes

Matt

-----Original Message-----
From: condor-devel-bounces@xxxxxxxxxxx
[mailto:condor-devel-bounces@xxxxxxxxxxx] On Behalf Of Ian Chesal
Sent: 24 March 2009 21:29
To: Ben Burnett
Cc: condor-devel@xxxxxxxxxxx
Subject: 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.

_______________________________________________
Condor-devel mailing list
Condor-devel@xxxxxxxxxxx
https://lists.cs.wisc.edu/mailman/listinfo/condor-devel

----
Gloucester Research Limited believes the information provided herein is reliable. While every care has been taken to ensure accuracy, the information is furnished to the recipients with no warranty as to the completeness and accuracy of its contents and on condition that any errors or omissions shall not be made the basis for any claim, demand or cause for action.
The information in this email is intended only for the named recipient.  If you are not the intended recipient please notify us immediately and do not copy, distribute or take action based on this e-mail.
All messages sent to and from this email address will be logged by Gloucester Research Ltd and are subject to archival storage, monitoring, review and disclosure.
Gloucester Research Limited, 5th Floor, Whittington House, 19-30 Alfred Place, London WC1E 7EA.
Gloucester Research Limited is a company registered in England and Wales with company number 04267560.
----