Possible (new) sscanf bug

Possible (new) sscanf bug

[Charles Wilson]

This report is from Ben Wing on the XEmacs-nt mailing list.  Given his 
track record, if Ben thinks there's a bug in sscanf, there probably is. 
  I don't have a self-contained test case (but I'll try to gen one soon) 
-- but I did want to put this report "in the record".

I'm not going to have much time to track this down until the weekend; 
anybody who wants to take a look at it before then is more than welcome. :-)

--Chuck

Ben Wing wrote:

> i'm using 1.3.2.
> 
> i still wonder though whether i'm not seeing a sscanf bug, as i get a crash on a
> line with sscanf in it, and my char * pointer is getting corrupted [set to a
> small number] -- and it occurs on the stack, directly above the last variable
> that sscanf is supposed to be writing into.
> 
> here's the code:
> 
>       char *p = line;
>       int cp1, cp2, endcount;
>       int cp1high, cp1low;
>       int dummy;
> 
>       while (*p) /* erase all comments out of the line */
> 	{
> 	  if (*p == '#')
> 	    *p = '\0';
> 	  else
> 	    p++;
> 	}
>       /* see if line is nothing but whitespace and skip if so */
>       p = line + strspn (line, " \t\n\r\f");
>       if (!*p)
> 	continue;
>       if ((!ignore_first_column ?      <-------------------------------------
> 	   sscanf (p, "%i %i %n", &cp1, &cp2, &endcount) < 2 :
> 	   sscanf (p, "%i %i %i %n", &dummy, &cp1, &cp2, &endcount) < 3)
> 	  || *(line + endcount))
> 	{
> 	  warn_when_safe (intern ("unicode"), Qnotice,
> 			  "Unrecognized line in translation file %s:\n%s",
> 			  XSTRING_DATA (filename), line);
> 	  continue;
> 	}
>       if (cp1 >= st && cp1 <= en)
> 
> 
> GDB reports the crash on the line indicated, and reports p as 0x24 <address out
> of bounds>.
> 
> are you in contact with cygwin people?
> 
> 
> Charles Wilson wrote:
> 
>> 
>> Ben Wing wrote:
>> 
> 
>> > One problem I've
>> > noticed so far is with Cygwin w/Mule: you get a crash at startup in
>> > parse-unicode-translation-table.  I don't quite know what the problem is and
>> > haven't been able to debug it yet, as the debugger keeps locking up.  MS Win
>> > does the same code, though, without problems, so it almost looks like either a
>> > GCC bug or a bug in sscanf[].
> 
>> 
>> Which cygwin kernel are you using in your tests, Ben?
>> cygwin-1.3.0/1.3.1 had a significant bug in sscanf, but it was fixed by
>> 1.3.2.
>> 
>> --Chuck
> 



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Possible (new) sscanf bug

[Christopher Faylor]

I've forwarded this to the newlib mailing list.

sscanf is not in cygwin's domain.  It's maintained by another group.

cgf

On Tue, Sep 11, 2001 at 09:29:51AM -0400, Charles Wilson wrote:
>This report is from Ben Wing on the XEmacs-nt mailing list.  Given his 
>track record, if Ben thinks there's a bug in sscanf, there probably is. 
> I don't have a self-contained test case (but I'll try to gen one soon) 
>-- but I did want to put this report "in the record".
>
>I'm not going to have much time to track this down until the weekend; 
>anybody who wants to take a look at it before then is more than welcome. :-)
>
>--Chuck
>
>Ben Wing wrote:
>
>>i'm using 1.3.2.
>>
>>i still wonder though whether i'm not seeing a sscanf bug, as i get a crash 
>>on a
>>line with sscanf in it, and my char * pointer is getting corrupted [set to 
>>a
>>small number] -- and it occurs on the stack, directly above the last 
>>variable
>>that sscanf is supposed to be writing into.
>>
>>here's the code:
>>
>>      char *p = line;
>>      int cp1, cp2, endcount;
>>      int cp1high, cp1low;
>>      int dummy;
>>
>>      while (*p) /* erase all comments out of the line */
>>	{
>>	  if (*p == '#')
>>	    *p = '\0';
>>	  else
>>	    p++;
>>	}
>>      /* see if line is nothing but whitespace and skip if so */
>>      p = line + strspn (line, " \t\n\r\f");
>>      if (!*p)
>>	continue;
>>      if ((!ignore_first_column ?      <-------------------------------------
>>	   sscanf (p, "%i %i %n", &cp1, &cp2, &endcount) < 2 :
>>	   sscanf (p, "%i %i %i %n", &dummy, &cp1, &cp2, &endcount) < 3)
>>	  || *(line + endcount))
>>	{
>>	  warn_when_safe (intern ("unicode"), Qnotice,
>>			  "Unrecognized line in translation file %s:\n%s",
>>			  XSTRING_DATA (filename), line);
>>	  continue;
>>	}
>>      if (cp1 >= st && cp1 <= en)
>>
>>
>>GDB reports the crash on the line indicated, and reports p as 0x24 <address 
>>out
>>of bounds>.
>>
>>are you in contact with cygwin people?
>>
>>
>>Charles Wilson wrote:
>>
>>>
>>>Ben Wing wrote:
>>>
>>
>>>> One problem I've
>>>> noticed so far is with Cygwin w/Mule: you get a crash at startup in
>>>> parse-unicode-translation-table.  I don't quite know what the problem is 
>>>and
>>>> haven't been able to debug it yet, as the debugger keeps locking up.  MS 
>>>Win
>>>> does the same code, though, without problems, so it almost looks like 
>>>either a
>>>> GCC bug or a bug in sscanf[].
>>
>>>
>>>Which cygwin kernel are you using in your tests, Ben?
>>>cygwin-1.3.0/1.3.1 had a significant bug in sscanf, but it was fixed by
>>>1.3.2.
>>>
>>>--Chuck
>>
>
>
>
>--
>Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
>Bug reporting:         http://cygwin.com/bugs.html
>Documentation:         http://cygwin.com/docs.html
>FAQ:                   http://cygwin.com/faq/

-- 
cgf@cygnus.com                        Red Hat, Inc.
http://sources.redhat.com/            http://www.redhat.com/

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Possible (new) sscanf bug

[Charles Wilson]

Christopher Faylor wrote:

> I've forwarded this to the newlib mailing list.
> 
> sscanf is not in cygwin's domain.  It's maintained by another group.
> 


Yeah, I know.  I just figured the cygwin list should be aware of this 
*possible* bug given the current 1.3.3 work.  You are correct -- newlib 
is the correct list.  I probably should have cross-posted to both, and 
asked that replies be directed to newlib only.  Oh well.

--Chuck








--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/