History | Log In     View a printable version of the current page.  
Issue Details (XML | Word | Printable)

Key: CIB-1920
Type: Bug Bug
Status: Resolved Resolved
Resolution: Fixed
Priority: 1 1
Assignee: jason
Reporter: Rohan McGovern
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
Pulse

"Unexpected error: Index: 0, Size: 0" when doing git bootstrap on Windows

Created: 07/Apr/09 12:08 AM   Updated: 16/Apr/09 08:47 PM
Component/s: None
Affects Version/s: 2.0.26
Fix Version/s: 2.1.4, 2.0.28

Original Estimate: Unknown Remaining Estimate: Unknown Time Spent: Unknown
File Attachments: 1. Text File badagent.log (3 kb)

Environment:
Windows XP SP3 i386
git version 1.6.2.msysgit.0.186.gf7512


 Description  « Hide
Bootstrap of a git repo consistently fails on Windows with the message "Unexpected error: Index: 0, Size: 0"

However, the output of the command looks completely normal and successful. e.g., on an incremental update, the files.txt artifact for bootstrap is:

>> git.cmd checkout local
Switched to branch "local"

It might be relevant that we have overridden pulse.git.command on our agents, setting it to git.cmd rather than the Windows default of git.exe.

 All   Comments   Work Log   Change History      Sort Order:
Rohan McGovern - 07/Apr/09 12:40 AM
Does not fail on a Windows Vista Business SP1 machine with the same version of git.
Both machines have java 1.6.0_13.

Daniel Ostermeier - 07/Apr/09 01:32 AM
Hi Rohan,

Can you please attach (or send to support @ zutubi) the log files from the windows agents that are failing and also the windows vista business SP1 machine that is not failing?

Regards,
-Daniel

Rohan McGovern - 07/Apr/09 02:06 AM
Attached the log from the XP agent where git fails.

The first error in the log is from a build where a bootstrap is done for the first time. (project is set to "clean update" mode)

The second error is from a subsequent bootstrap.

The log from the Vista agent which is working correctly has no entries for the same time period.

Rohan McGovern - 07/Apr/09 02:55 AM
As the backtrace mentions GitClient.java:226, it looks like the problem is in invoking the `log' command.

If I manually log into the XP machine and run the `git log' command I believe Pulse will run, I get this:

C:\Documents and Settings\pulseagent\git_test\somerepo>git.cmd log --name-status -
c --pretty=format:#%n%H%n%cn%n%cd%n%s%n%b# --reverse -n 1

fatal: ambiguous argument 'and': unknown revision or path not in the working tre
e.

Use '--' to separate paths from revisions

The problem is that %cd% in the pretty-format string expands to my current directory, and that contains a space.

My theory is that it fails on XP and not on Vista because on Vista, the pulse agent is under c:\users\pulseagent (no space), while on XP it is under c:\documents and settings\pulseagent (spaces).

If I run the same command on the Vista machine, it doesn't fail, however the current path is put into the log messages. e.g., the entries output are:

#

caab736c126ac6f0e9e908440bbdbf0817dcdd5e

Bob Jones
C:\Users\pulseagent\git_test\somereponFixed some bug.
#


jason - 07/Apr/09 04:13 AM
Hi Rohan,

Thanks for the extra details. I think, however, the problem you are seeing is because you are typing the command in at the prompt where environment variables (such as %cd%) will be replaced, but this should not be the case when Pulse calls git itself. Are you able to repeat the test but with the % characters escaped with ^? That is:

git.cmd log --name-status -c --pretty=format:#^%n^%H^%n^%cn^%n^%cd^%n^%s^%n^%b# --reverse -n 1

Rohan McGovern - 07/Apr/09 05:51 AM
I can't test this right now, but I'm pretty certain you're correct and it will work if the characters are escaped. However I don't think it's just a coincidence that my test fails on the same platform in the same git command as Pulse.

My thoughts are that a variable substitution step is taking place somewhere where I didn't expect it. Possibly within git.cmd, which means the bug wouldn't be in Pulse at all. Will test more tomorrow...

jason - 07/Apr/09 06:13 AM
Hi Rohan,

You are right that it seems more than coincidence - particularly as you are using the same version of git. It may well be that substitution is happening in git.cmd. This may also point to a separate issue with git.cmd -- if it doesn't like the input and is failing, it seems to still exit with code 0 (else Pulse would detect the error on exit and report it differently). Batch files are notorious for not exiting with correct codes, as it can be tricky to get it right.

Rohan McGovern - 07/Apr/09 07:49 PM
Testing indicates that git.cmd behaves correctly in these two respects: it doesn't introduce an additional substitution step, and it correctly preserves the exit code.

Therefore it doesn't look like the problem is with git.cmd. The manner in which `git.cmd log' failed in my earlier comments might just be a coincidence after all.

Is there some way to make logging more verbose on the agents so I can tell for sure what command(s) it is running?

jason - 08/Apr/09 06:01 AM
Hi Rohan,

The git commands run should appear in the recipe log prefixed by >>, just like the checkout command you pasted in the original description for this issue. I would expect the log command to come after it and take the form you have been testing at the command line. If that command works, then it may be a problem with how we parse the output. If a total parse failure is detected Pulse will show the raw output from the git command, but unfortunately it seems it is just missing the important parts without failing (and there is no way to force it to show raw output at the moment). However, if you can send us the output produced by running the log command at the command line we can test with it to try and reproduce the problem.

Rohan McGovern - 08/Apr/09 07:48 PM
Additional log sent to support@zutubi.com

jason - 16/Apr/09 08:47 PM
Handle unexpected leading lines in log output in change 5815, merged to trunk in change 5833.