Problem with "dashless options"

Problem with "dashless options"

[Henrik Tidefelt]

Hi,

Yesterday I installed a fresh git (1.6.4.2) on my system using  
MacPorts.  Some of the git sub-commands work fine (for instance,  
checkout, status, remote), while push gives an error as follows:

$ git push isy next
fatal: BUG: dashless options don't support arguments

The same thing happens when I do

$ git push --repo=isy next

Since this seems to be a rather severe problem, I suppose it is that  
it is related to the old and perhaps unusual platform I am using.  It  
is a PowerPC machine running Mac OS 10.4, with GCC powerpc-apple- 
darwin8-gcc-4.0.1 and MacPorts 1.8.0.

I'll be happy to provide additional information that might help.


Best regards,

Henrik Tidefelt

Re: Problem with "dashless options"

[Jeff King]

On Wed, Sep 09, 2009 at 03:21:30PM +0200, Henrik Tidefelt wrote:

> Yesterday I installed a fresh git (1.6.4.2) on my system using
> MacPorts.  Some of the git sub-commands work fine (for instance,
> checkout, status, remote), while push gives an error as follows:
> 
> $ git push isy next
> fatal: BUG: dashless options don't support arguments

Hmm. Very strange. The only code path that triggers this is an option
declared with PARSE_OPT_NODASH but not PARSE_OPT_NOARG. But there are
only two options in all of git that use PARSE_OPT_NODASH, and:

  1. They are in git grep, not git push.

  2. They correctly have PARSE_OPT_NOARG set.

Which leads me to believe that something is writing random cruft on top
of the options struct. Either a stack overflow, or some issue related to
your compiler (either a bug in the compiler, or something non-portable
we are doing).

Can you try applying the patch below which will at least give us a bit
more information about the offending option?

Also, does 1.6.4.1 work OK? Or any other earlier version? If so, can you
try bisecting?

diff --git a/parse-options.c b/parse-options.c
index f7ce523..e93eb67 100644
--- a/parse-options.c
+++ b/parse-options.c
@@ -275,7 +275,15 @@ static int parse_nodash_opt(struct parse_opt_ctx_t *p, const char *arg,
 			continue;
 		if ((options->flags & PARSE_OPT_OPTARG) ||
 		    !(options->flags & PARSE_OPT_NOARG))
-			die("BUG: dashless options don't support arguments");
+			die("BUG: dashless options don't support arguments\n"
+			    "buggy option is:\n"
+			    " type: %d\n"
+			    " short_name: %c\n"
+			    " long_name: %s\n"
+			    " flags: %d\n",
+			    options->type, options->short_name,
+			    options->long_name, options->flags
+			);
 		if (!(options->flags & PARSE_OPT_NONEG))
 			die("BUG: dashless options don't support negation");
 		if (options->long_name)

Re: Problem with "dashless options"

[Henrik Tidefelt]

Yes, that was a strange error.  I applied the patch, but could not  
reproduce the error any more.  Also, Gustaf Hendeby built git  
directly from the git distribution (not via MacPorts) on my machine,  
and could not reproduce the error.  Then I simply tried to clean and  
build the git from MacPorts again, and voila!, now it works.   
Something very strange must have happened during the previous build.

I am sorry for taking your time.


Henrik

On 9Sep , 2009, at 16:34 , Jeff King wrote:

> On Wed, Sep 09, 2009 at 03:21:30PM +0200, Henrik Tidefelt wrote:
>
>> Yesterday I installed a fresh git (1.6.4.2) on my system using
>> MacPorts.  Some of the git sub-commands work fine (for instance,
>> checkout, status, remote), while push gives an error as follows:
>>
>> $ git push isy next
>> fatal: BUG: dashless options don't support arguments
>
> Hmm. Very strange. The only code path that triggers this is an option
> declared with PARSE_OPT_NODASH but not PARSE_OPT_NOARG. But there are
> only two options in all of git that use PARSE_OPT_NODASH, and:
>
>   1. They are in git grep, not git push.
>
>   2. They correctly have PARSE_OPT_NOARG set.
>
> Which leads me to believe that something is writing random cruft on  
> top
> of the options struct. Either a stack overflow, or some issue  
> related to
> your compiler (either a bug in the compiler, or something non-portable
> we are doing).
>
> Can you try applying the patch below which will at least give us a bit
> more information about the offending option?
>
> Also, does 1.6.4.1 work OK? Or any other earlier version? If so,  
> can you
> try bisecting?
>
> diff --git a/parse-options.c b/parse-options.c
> index f7ce523..e93eb67 100644
> --- a/parse-options.c
> +++ b/parse-options.c
> @@ -275,7 +275,15 @@ static int parse_nodash_opt(struct  
> parse_opt_ctx_t *p, const char *arg,
>  			continue;
>  		if ((options->flags & PARSE_OPT_OPTARG) ||
>  		    !(options->flags & PARSE_OPT_NOARG))
> -			die("BUG: dashless options don't support arguments");
> +			die("BUG: dashless options don't support arguments\n"
> +			    "buggy option is:\n"
> +			    " type: %d\n"
> +			    " short_name: %c\n"
> +			    " long_name: %s\n"
> +			    " flags: %d\n",
> +			    options->type, options->short_name,
> +			    options->long_name, options->flags
> +			);
>  		if (!(options->flags & PARSE_OPT_NONEG))
>  			die("BUG: dashless options don't support negation");
>  		if (options->long_name)

Re: Problem with "dashless options"

[Pierre Habouzit]

On Wed, Sep 09, 2009 at 06:26:37PM +0200, Henrik Tidefelt wrote:
> Yes, that was a strange error.  I applied the patch, but could not
> reproduce the error any more.  Also, Gustaf Hendeby built git
> directly from the git distribution (not via MacPorts) on my machine,
> and could not reproduce the error.  Then I simply tried to clean and
> build the git from MacPorts again, and voila!, now it works.
> Something very strange must have happened during the previous build.

Are you using a keyboard mapping where AltGr+space produces an   ?

-- 
·O·  Pierre Habouzit
··O                                                madcoder@debian.org
OOO                                                http://www.madism.org

Re: Problem with "dashless options"

[Henrik Tidefelt]

No, but it is mapped to WHITE FROWNING FACE; I guess I defined it so  
to avoid the trouble I was previously experiencing from accidentally  
typing the   instead of space without being able to see the  
difference on screen.  Why would it matter?


Henrik

On 09-09-09, at 18:30 , Pierre Habouzit wrote:

> On Wed, Sep 09, 2009 at 06:26:37PM +0200, Henrik Tidefelt wrote:
>> Yes, that was a strange error.  I applied the patch, but could not
>> reproduce the error any more.  Also, Gustaf Hendeby built git
>> directly from the git distribution (not via MacPorts) on my machine,
>> and could not reproduce the error.  Then I simply tried to clean and
>> build the git from MacPorts again, and voila!, now it works.
>> Something very strange must have happened during the previous build.
>
> Are you using a keyboard mapping where AltGr+space produces an  
>   ?
>
> -- 
> ·O·  Pierre Habouzit
> ··O                                                madcoder@debian.org
> OOO                                                http://www.madism.org

Re: Problem with "dashless options"

[Pierre Habouzit]

[-- Attachment #1: Type: text/plain, Size: 935 bytes --]

On Wed, Sep 09, 2009 at 11:12:12PM +0200, Henrik Tidefelt wrote:
> No, but it is mapped to WHITE FROWNING FACE; I guess I defined it so
> to avoid the trouble I was previously experiencing from accidentally
> typing the   instead of space without being able to see the
> difference on screen.  Why would it matter?

well because then one of your space could have been that, and the shell
doesn't consider non breakable space as .. breakable, hence you can read
something where you believe there is (n+1) arguments but the shell (and
git) see only n.

It often yields errors really hard to grasp like the dreaded:

$ ls | grep
zsh: command not found:  grep
notice the              ^

sorry then I don't really know what happened...

-- 
·O·  Pierre Habouzit
··O                                                madcoder@debian.org
OOO                                                http://www.madism.org

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Problem with "dashless options"

[Christopher Cameron]

Henrik Tidefelt <tidefelt <at> isy.liu.se> writes:

> Some of the git sub-commands work fine (for instance,  
> checkout, status, remote), while push gives an error as follows:
> 
> $ git push isy next
> fatal: BUG: dashless options don't support arguments

I encountered the exact same problem.  There are a sequence of
#defines in parse_options.h which are supposed to initialize option
structs (OPT_END, OPT_STRING, etc).  These structures only partially 
initialize the structure, leading to, for instance, junk bits in the flags 
word of OPT_STRING.
 type: 9
 short_name: m
 long_name: master
 flags: 74636f6e
You were seeing some commands affected vs not depending on how
they use the options macros.

I changed my local source to fill out the full struct, and I never saw 
the bug again.

Re: Problem with "dashless options"

[Andreas Schwab]

Christopher Cameron <christopher.cameron@live.com> writes:

> I encountered the exact same problem.  There are a sequence of
> #defines in parse_options.h which are supposed to initialize option
> structs (OPT_END, OPT_STRING, etc).  These structures only partially 
> initialize the structure, leading to, for instance, junk bits in the flags 
> word of OPT_STRING.

That's a bug in your compiler.  All parts of the struct that are not
explicitly initialized are supposed to be implicitly initialized to
zero.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."