Jazz Forum Welcome to the Jazz Community Forum Connect and collaborate with IBM Engineering experts and users

scm.exe error if build user not logged in (Windows)

We have RTC (2.0.0.2 iFix5) builds running with the the Build Forge
integration and have a puzzling problem employing the scm command line on Windows -- wondering if anyone else has seen
and/or can explain... I know when it happens and how to prevent
it, but not exactly why...

Our build machines are Windows 2003 SP2 (32-bit and 64-bit -- both
exhibit the same behavior) with the BF agent running as a service.
If, for some reason (say, Windows updates) the system is restarted
and the build user doesn't log in, we get the following from scm.exe:

Password (user @ rtcserver):
JVMDUMP006I Processing dump event "systhrow", detail "java/lang/OutOfMemoryError" - please wait.
JVMDUMP032I JVM requested Snap dump using 'E:\build\Snap.20110222.195339.3104.0001.trc' in response to an event
JVMDUMP010I Snap dump written to E:\build\Snap.20110222.195339.3104.0001.trc
JVMDUMP032I JVM requested Heap dump using 'E:\build\heapdump.20110222.195339.3104.0002.phd' in response to an event
JVMDUMP010I Heap dump written to E:\build\heapdump.20110222.195339.3104.0002.phd
JVMDUMP032I JVM requested Java dump using 'E:\build\javacore.20110222.195339.3104.0003.txt' in response to an event
JVMDUMP010I Java dump written to E:\build\javacore.20110222.195339.3104.0003.txt
JVMDUMP013I Processed dump event "systhrow", detail "java/lang/OutOfMemoryError".
Unexpected exception
java.lang.OutOfMemoryError
at java.lang.StringBuffer.ensureCapacityImpl(StringBuffer.java:386)
at java.lang.StringBuffer.append(StringBuffer.java:146)
at com.ibm.team.filesystem.cli.core.util.PasswordReader.run(Unknown Source)
at com.ibm.team.filesystem.cli.core.util.PromptUtil.prompt(Unknown Source)
at com.ibm.team.filesystem.cli.core.internal.LocalContext.getPassword(Unknown Source)
at com.ibm.team.filesystem.cli.core.internal.ClientConfiguration.getConnectionInfo(Unknown Source)
at com.ibm.team.filesystem.cli.core.internal.ClientConfiguration$$Cold.getConnectionInfo(Unknown Source)
at com.ibm.team.filesystem.cli.core.internal.ClientConfiguration.getConnectionInfo(Unknown Source)
at com.ibm.team.filesystem.cli.client.internal.subcommands.LoadCmdLauncher.run(LoadCmdLauncher.java:76)
at com.ibm.team.filesystem.cli.core.internal.SubcommandLauncher.run(Unknown Source)
at com.ibm.team.filesystem.cli.core.internal.SubcommandLauncher.doStart(Unknown Source)
at com.ibm.team.filesystem.cli.core.internal.SubcommandLauncher.run(Unknown Source)
at com.ibm.team.filesystem.cli.core.internal.Application.start(Unknown Source)
at org.eclipse.equinox.internal.app.EclipseAppHandle.run(Unknown Source)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(Unknown Source)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(Unknown Source)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(Unknown Source)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:79)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:618)
at org.eclipse.equinox.launcher.Main.invokeFramework(Unknown Source)
at org.eclipse.equinox.launcher.Main.basicRun(Unknown Source)
at org.eclipse.equinox.launcher.Main.run(Unknown Source)
Scm:
An error has occurred. See the log file
E:\dev\RTC-2.0.0.2-Win\scmtools\eclipse\configuration\1298422096509.log.

I gather scm is trying to put up a password prompt and it's failing
due to no access to the console... But, we're relying on creds
stored in the user's home directory via scm login command so
I'm not sure where the "Password:" prompt comes from and/or
how to suppress it.

The solution is to have the build user logged in on the console
via remote desktop at all times -- it would be nice not to have to
do so...

Thanks for any insight!

0 votes



3 answers

Permanent link
When you run 'scm login' with credentials specified on the command line, the credentials is cached in the configuration directory which is by default the users home directory. So when the machine starts up and you run the scm cli, it will look for the cached credentials in the logged-in user's (which is non build user in your case) home directory. Since it is not available it will prompt the user to enter the credentials.

You can change the default configuration directory by specifying --config option in the scm cli and every command that is run using this --config option will look for the cached credentials at that location.

We have RTC (2.0.0.2 iFix5) builds running with the the Build Forge
integration and have a puzzling problem employing the scm command line on Windows -- wondering if anyone else has seen
and/or can explain... I know when it happens and how to prevent
it, but not exactly why...

Our build machines are Windows 2003 SP2 (32-bit and 64-bit -- both
exhibit the same behavior) with the BF agent running as a service.
If, for some reason (say, Windows updates) the system is restarted
and the build user doesn't log in, we get the following from scm.exe:

Password (user @ rtcserver):
JVMDUMP006I Processing dump event "systhrow", detail "java/lang/OutOfMemoryError" - please wait.
JVMDUMP032I JVM requested Snap dump using 'E:\build\Snap.20110222.195339.3104.0001.trc' in response to an event
JVMDUMP010I Snap dump written to E:\build\Snap.20110222.195339.3104.0001.trc
JVMDUMP032I JVM requested Heap dump using 'E:\build\heapdump.20110222.195339.3104.0002.phd' in response to an event
JVMDUMP010I Heap dump written to E:\build\heapdump.20110222.195339.3104.0002.phd
JVMDUMP032I JVM requested Java dump using 'E:\build\javacore.20110222.195339.3104.0003.txt' in response to an event
JVMDUMP010I Java dump written to E:\build\javacore.20110222.195339.3104.0003.txt
JVMDUMP013I Processed dump event "systhrow", detail "java/lang/OutOfMemoryError".
Unexpected exception
java.lang.OutOfMemoryError
at java.lang.StringBuffer.ensureCapacityImpl(StringBuffer.java:386)
at java.lang.StringBuffer.append(StringBuffer.java:146)
at com.ibm.team.filesystem.cli.core.util.PasswordReader.run(Unknown Source)
at com.ibm.team.filesystem.cli.core.util.PromptUtil.prompt(Unknown Source)
at com.ibm.team.filesystem.cli.core.internal.LocalContext.getPassword(Unknown Source)
at com.ibm.team.filesystem.cli.core.internal.ClientConfiguration.getConnectionInfo(Unknown Source)
at com.ibm.team.filesystem.cli.core.internal.ClientConfiguration$$Cold.getConnectionInfo(Unknown Source)
at com.ibm.team.filesystem.cli.core.internal.ClientConfiguration.getConnectionInfo(Unknown Source)
at com.ibm.team.filesystem.cli.client.internal.subcommands.LoadCmdLauncher.run(LoadCmdLauncher.java:76)
at com.ibm.team.filesystem.cli.core.internal.SubcommandLauncher.run(Unknown Source)
at com.ibm.team.filesystem.cli.core.internal.SubcommandLauncher.doStart(Unknown Source)
at com.ibm.team.filesystem.cli.core.internal.SubcommandLauncher.run(Unknown Source)
at com.ibm.team.filesystem.cli.core.internal.Application.start(Unknown Source)
at org.eclipse.equinox.internal.app.EclipseAppHandle.run(Unknown Source)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(Unknown Source)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(Unknown Source)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(Unknown Source)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:79)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:618)
at org.eclipse.equinox.launcher.Main.invokeFramework(Unknown Source)
at org.eclipse.equinox.launcher.Main.basicRun(Unknown Source)
at org.eclipse.equinox.launcher.Main.run(Unknown Source)
Scm:
An error has occurred. See the log file
E:\dev\RTC-2.0.0.2-Win\scmtools\eclipse\configuration\1298422096509.log.

I gather scm is trying to put up a password prompt and it's failing
due to no access to the console... But, we're relying on creds
stored in the user's home directory via scm login command so
I'm not sure where the "Password:" prompt comes from and/or
how to suppress it.

The solution is to have the build user logged in on the console
via remote desktop at all times -- it would be nice not to have to
do so...

Thanks for any insight!

0 votes


Permanent link
Thanks for the explanation and work-around -- we'll implement --config
for our builds, but...

It seems to me however, this is a bug -- that scm.exe's method of
determining users' home directory is flawed on Windows. What if,
for example, BF uses one set of server creds and a different user
happens to be logged in? Are you saying scm would use the logged
on user's cached password info? That seems wrong to me. I would
say scm's method of determining the calling user's home directory
should be changed to use that of the executing user (as it does
on *nix), not the Windows logged on user.

Thoughts?

0 votes


Permanent link
First, your workaround, --config <dir>, did work for us so thanks for that.
But, once we got past the scm.exe problem, we next bumped into the same
sort of issue with maven (mvn) command line -- it wasn't reading our
~/.m2/settings.xml. To make a very long googling story short, it turns
out our problems were all rooted in a Build Forge Agent bug. After much
rummaging around the web, I ended up back here at jazz.net looking at
this thread: http://jazz.net/forums/viewtopic.php?t=13710 Lo and
behold, upgrading BF agent on our Windows system addressed not just
maven but also cured the original scm.exe problem reported here. With
an up-to-date BF agent, scm --config <dir> is no longer necessary -- scm.exe
finds the config dir in the user's home directory just fine now that BF agent
is establishing the proper environment (USERPROFILE being the key I
believe.)

Case closed -- Build Forge Agent bug which has been fixed, not an RTC
issue at all...

0 votes

Your answer

Register or log in to post your answer.

Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.

Search context
Follow this question

By Email: 

Once you sign in you will be able to subscribe for any updates here.

By RSS:

Answers
Answers and Comments
Question details

Question asked: Feb 23 '11, 10:12 a.m.

Question was seen: 6,523 times

Last updated: Feb 23 '11, 10:12 a.m.

Confirmation Cancel Confirm