[bug,bisected,-chrisl] Segfault at evaluate.c:341

Commit Message

Al Viro March 19, 2009, 10:09 p.m. UTC

On Thu, Mar 19, 2009 at 09:52:50PM +0000, Al Viro wrote:
> On Thu, Mar 19, 2009 at 01:04:20PM -0700, Christopher Li wrote:
> 
> > We should stop the segfault though. I take a look at it. It seems that
> > there is a SYM_NODE with base_type is NULL. I guess in some of
> > the error path we result in an invalid AST three.
> 
> We are getting some mess with K&R declarations.  Which is bloody likely
> to be my fault; will check.

Yeah...  It's an old b0rken handling of calls for K&R + changes that exposed
that even worse.

Status quo is restored by the patch below, but it's a stopgap - e.g.
void f();
void g(void)
{
	f(0, 0);
}
will warn about extra arguments as if we had void f(void); as sparse had
been doing all along.  B0rken.

Testcase for the segfault is
void f(x, y);
void g(void)
{
	f(0, 0);
}

Signed-off-by: Al Viro <[e-mail]>
---
--
To unsubscribe from this list: send the line "unsubscribe linux-sparse" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Comments

Christopher Li March 19, 2009, 11:11 p.m. UTC | #1

Thanks Al,

I will apply it later tonight.

If no one beats to me, I will try to add the warning for using preprocessor
directive inside macro expansion. It should be a better error message
than the current one.

Chris

On Thu, Mar 19, 2009 at 3:09 PM, Al Viro <[e-mail]> wrote:
> On Thu, Mar 19, 2009 at 09:52:50PM +0000, Al Viro wrote:
>> On Thu, Mar 19, 2009 at 01:04:20PM -0700, Christopher Li wrote:
>>
>> > We should stop the segfault though. I take a look at it. It seems that
>> > there is a SYM_NODE with base_type is NULL. I guess in some of
>> > the error path we result in an invalid AST three.
>>
>> We are getting some mess with K&R declarations.  Which is bloody likely
>> to be my fault; will check.
>
> Yeah...  It's an old b0rken handling of calls for K&R + changes that exposed
> that even worse.
>
> Status quo is restored by the patch below, but it's a stopgap - e.g.
> void f();
> void g(void)
> {
>        f(0, 0);
> }
> will warn about extra arguments as if we had void f(void); as sparse had
> been doing all along.  B0rken.
>
> Testcase for the segfault is
> void f(x, y);
> void g(void)
> {
>        f(0, 0);
> }
>
> Signed-off-by: Al Viro <[e-mail]>
> ---
> diff --git a/parse.c b/parse.c
> index b9b96ba..87f6264 100644
> --- a/parse.c
> +++ b/parse.c
> @@ -2323,6 +2323,7 @@ static struct token *identifier_list(struct token *token, struct symbol *fn)
>                sym->ident = token->ident;
>                token = token->next;
>                sym->endpos = token->pos;
> +               sym->ctype.base_type = &incomplete_ctype;
>                add_symbol(list, sym);
>                if (!match_op(token, ',') ||
>                    token_type(token->next) != TOKEN_IDENT ||
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sparse" in
> the body of a message to [e-mail]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-sparse" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Patch

diff --git a/parse.c b/parse.c
index b9b96ba..87f6264 100644
--- a/parse.c
+++ b/parse.c
@@ -2323,6 +2323,7 @@  static struct token *identifier_list(struct token *token, struct symbol *fn)
 		sym->ident = token->ident;
 		token = token->next;
 		sym->endpos = token->pos;
+		sym->ctype.base_type = &incomplete_ctype;
 		add_symbol(list, sym);
 		if (!match_op(token, ',') ||
 		    token_type(token->next) != TOKEN_IDENT ||