c0000029 bug report sent to Microsoft

This is the bug report I sent to MS, in case anyone wants to play with this.


This is a Visual FoxPro bug about
FoxPro Version (pick one): 8.0 SP1
Reproduces (pick one): always
Hardware and Software Details:
Dell opteron 2.6 GHz Celeron
Windows 2000

Happens on other machines as well.

Other Development Environments? yes
If yes which? Visual Studio .net 2003

Steps to Reproduce:

1) First create a database, and put a table in it, put some records in it.
CREATE DATABASE ZOOT
CREATE TABLE ZOOT (Z1 C(10), Z2 C(10), CHANGE T )
INSERT INTO ZOOT (Z1) VALUES ('ZOOT')

2) Set record validation Rule - we want this procedure in the DBC to execute
when a record is changed:
setchange()

3) Create stored procedure in DBC called SetChange:
PROCEDURE setChange
TRY
IF glSetChange
REPLACE CHANGE WITH DATETIME()
ENDIF
CATCH
* WAIT WINDOW 'An error has occured'
ENDTRY

RETURN .T.
ENDPROC

4) Run this code:
USE ZOOT
SET STEP ON
REPLACE Z1 WITH 'NoZoot', Z2 WITH BadVarName

Notice that glSetChange is uninitialized. This is by design. Notice that
BadVarName is undefined. In order to reproduce this error, you need a two
part REPLACE, and the first one (Z1 WITH 'NoZoot') must be valid, and the
second one (Z2 WITH BadVarName) must be invalid IE have a runtime error such
as uninitialized variable or invalid table/field name, etc.

Observed Behavior:


I step through the code via the above SET STEP because if you dont,
sometimes VFP will just hard terminate, poof and it's gone. If you step
through it, when you get to this line:

TRY
IF glSetChange

You should get a c0000029.

It varies according to the code in SetChange, but it will consistently
crash. If I change the code slightly , I can get c0000005, c0000029. I also
get MS VC++ Runtime Library error, Buffer overrun detected error. The code I
posted above seems to consistently produce c0000029.

This, for example,

IF glSetChange .AND. 1 = 1

seems to produce a buffer overrun warning, other variations produce a
mismatched push/pop type of message.


Expected Behavior:
A trappable VFP error should be generated, not a hard crash.

Additional Information:

I can get a crash in VFP7 by using this code in SetChange:

PROCEDURE setChange
ON ERROR llZOOT = .T.
IF glSetChange
REPLACE CHANGE WITH DATETIME()
ENDIF
ON ERROR
RETURN .T.
ENDPROC

Since VFP7 does not support TRY/CATCH, I use traditional error trapping
instead.

In VFP9 the same process generates a c0000005 error.

Dan
Tue Jan 11 12:45:17 CST 2005

You may have brought some of this on yourself.

1) CHANGE is a reserved word. (Equivalent to EDIT.)
2) It's generally a bad idea for a stored procedure to write to the table
being validated. You cause validation again, which of course requires
calling your code again, which causes validation again....

Dan


Ook wrote:
> This is the bug report I sent to MS, in case anyone wants to play
> with this.
>
>
> This is a Visual FoxPro bug about
> FoxPro Version (pick one): 8.0 SP1
> Reproduces (pick one): always
> Hardware and Software Details:
> Dell opteron 2.6 GHz Celeron
> Windows 2000
>
> Happens on other machines as well.
>
> Other Development Environments? yes
> If yes which? Visual Studio .net 2003
>
> Steps to Reproduce:
>
> 1) First create a database, and put a table in it, put some records
> in it. CREATE DATABASE ZOOT
> CREATE TABLE ZOOT (Z1 C(10), Z2 C(10), CHANGE T )
> INSERT INTO ZOOT (Z1) VALUES ('ZOOT')
>
> 2) Set record validation Rule - we want this procedure in the DBC to
> execute when a record is changed:
> setchange()
>
> 3) Create stored procedure in DBC called SetChange:
> PROCEDURE setChange
> TRY
> IF glSetChange
> REPLACE CHANGE WITH DATETIME()
> ENDIF
> CATCH
> * WAIT WINDOW 'An error has occured'
> ENDTRY
>
> RETURN .T.
> ENDPROC
>
> 4) Run this code:
> USE ZOOT
> SET STEP ON
> REPLACE Z1 WITH 'NoZoot', Z2 WITH BadVarName
>
> Notice that glSetChange is uninitialized. This is by design. Notice
> that BadVarName is undefined. In order to reproduce this error, you
> need a two part REPLACE, and the first one (Z1 WITH 'NoZoot') must be
> valid, and the second one (Z2 WITH BadVarName) must be invalid IE
> have a runtime error such as uninitialized variable or invalid
> table/field name, etc.
>
> Observed Behavior:
>
>
> I step through the code via the above SET STEP because if you dont,
> sometimes VFP will just hard terminate, poof and it's gone. If you
> step through it, when you get to this line:
>
> TRY
> IF glSetChange
>
> You should get a c0000029.
>
> It varies according to the code in SetChange, but it will consistently
> crash. If I change the code slightly , I can get c0000005, c0000029.
> I also get MS VC++ Runtime Library error, Buffer overrun detected
> error. The code I posted above seems to consistently produce c0000029.
>
> This, for example,
>
> IF glSetChange .AND. 1 = 1
>
> seems to produce a buffer overrun warning, other variations produce a
> mismatched push/pop type of message.
>
>
> Expected Behavior:
> A trappable VFP error should be generated, not a hard crash.
>
> Additional Information:
>
> I can get a crash in VFP7 by using this code in SetChange:
>
> PROCEDURE setChange
> ON ERROR llZOOT = .T.
> IF glSetChange
> REPLACE CHANGE WITH DATETIME()
> ENDIF
> ON ERROR
> RETURN .T.
> ENDPROC
>
> Since VFP7 does not support TRY/CATCH, I use traditional error
> trapping instead.
>
> In VFP9 the same process generates a c0000005 error.

Ook
Tue Jan 11 13:10:44 CST 2005

The REPLACE line has nothing to do with the error, it just happens to have
been in the code sample that was initially causing the crash and I didn't
bother to remove it. I probably should have to prevent people from reaching
the same conclusion that you did. Remove the REPLACE line from SetChange,
and it still crashes.

I don't believe that a replace being called from the validation calls the
validation recursively. Stepping through the code does not show this, and
this code has been in place for quite a while without causing problems
(until someone mis-spelled a field name, at which point the below described
crash was triggered).


"Dan Freeman" <spam@microsoft.com> wrote in message
news:OesLz2A%23EHA.1188@tk2msftngp13.phx.gbl...
> You may have brought some of this on yourself.
>
> 1) CHANGE is a reserved word. (Equivalent to EDIT.)
> 2) It's generally a bad idea for a stored procedure to write to the table
> being validated. You cause validation again, which of course requires
> calling your code again, which causes validation again....
>
> Dan
>
>
> Ook wrote:
> > This is the bug report I sent to MS, in case anyone wants to play
> > with this.
> >
> >
> > This is a Visual FoxPro bug about
> > FoxPro Version (pick one): 8.0 SP1
> > Reproduces (pick one): always
> > Hardware and Software Details:
> > Dell opteron 2.6 GHz Celeron
> > Windows 2000
> >
> > Happens on other machines as well.
> >
> > Other Development Environments? yes
> > If yes which? Visual Studio .net 2003
> >
> > Steps to Reproduce:
> >
> > 1) First create a database, and put a table in it, put some records
> > in it. CREATE DATABASE ZOOT
> > CREATE TABLE ZOOT (Z1 C(10), Z2 C(10), CHANGE T )
> > INSERT INTO ZOOT (Z1) VALUES ('ZOOT')
> >
> > 2) Set record validation Rule - we want this procedure in the DBC to
> > execute when a record is changed:
> > setchange()
> >
> > 3) Create stored procedure in DBC called SetChange:
> > PROCEDURE setChange
> > TRY
> > IF glSetChange
> > REPLACE CHANGE WITH DATETIME()
> > ENDIF
> > CATCH
> > * WAIT WINDOW 'An error has occured'
> > ENDTRY
> >
> > RETURN .T.
> > ENDPROC
> >
> > 4) Run this code:
> > USE ZOOT
> > SET STEP ON
> > REPLACE Z1 WITH 'NoZoot', Z2 WITH BadVarName
> >
> > Notice that glSetChange is uninitialized. This is by design. Notice
> > that BadVarName is undefined. In order to reproduce this error, you
> > need a two part REPLACE, and the first one (Z1 WITH 'NoZoot') must be
> > valid, and the second one (Z2 WITH BadVarName) must be invalid IE
> > have a runtime error such as uninitialized variable or invalid
> > table/field name, etc.
> >
> > Observed Behavior:
> >
> >
> > I step through the code via the above SET STEP because if you dont,
> > sometimes VFP will just hard terminate, poof and it's gone. If you
> > step through it, when you get to this line:
> >
> > TRY
> > IF glSetChange
> >
> > You should get a c0000029.
> >
> > It varies according to the code in SetChange, but it will consistently
> > crash. If I change the code slightly , I can get c0000005, c0000029.
> > I also get MS VC++ Runtime Library error, Buffer overrun detected
> > error. The code I posted above seems to consistently produce c0000029.
> >
> > This, for example,
> >
> > IF glSetChange .AND. 1 = 1
> >
> > seems to produce a buffer overrun warning, other variations produce a
> > mismatched push/pop type of message.
> >
> >
> > Expected Behavior:
> > A trappable VFP error should be generated, not a hard crash.
> >
> > Additional Information:
> >
> > I can get a crash in VFP7 by using this code in SetChange:
> >
> > PROCEDURE setChange
> > ON ERROR llZOOT = .T.
> > IF glSetChange
> > REPLACE CHANGE WITH DATETIME()
> > ENDIF
> > ON ERROR
> > RETURN .T.
> > ENDPROC
> >
> > Since VFP7 does not support TRY/CATCH, I use traditional error
> > trapping instead.
> >
> > In VFP9 the same process generates a c0000005 error.
>
>

Ook
Tue Jan 11 13:15:38 CST 2005

PS - I agree with number one. They use "create" and "change" as field names,
and I argued against it but the powers that be thought it was a good idea,
and added these fields to all of the tables. Doh!!!


"Dan Freeman" <spam@microsoft.com> wrote in message
news:OesLz2A%23EHA.1188@tk2msftngp13.phx.gbl...
> You may have brought some of this on yourself.
>
> 1) CHANGE is a reserved word. (Equivalent to EDIT.)
> 2) It's generally a bad idea for a stored procedure to write to the table
> being validated. You cause validation again, which of course requires
> calling your code again, which causes validation again....
>
> Dan
>
>
> Ook wrote:
> > This is the bug report I sent to MS, in case anyone wants to play
> > with this.
> >
> >
> > This is a Visual FoxPro bug about
> > FoxPro Version (pick one): 8.0 SP1
> > Reproduces (pick one): always
> > Hardware and Software Details:
> > Dell opteron 2.6 GHz Celeron
> > Windows 2000
> >
> > Happens on other machines as well.
> >
> > Other Development Environments? yes
> > If yes which? Visual Studio .net 2003
> >
> > Steps to Reproduce:
> >
> > 1) First create a database, and put a table in it, put some records
> > in it. CREATE DATABASE ZOOT
> > CREATE TABLE ZOOT (Z1 C(10), Z2 C(10), CHANGE T )
> > INSERT INTO ZOOT (Z1) VALUES ('ZOOT')
> >
> > 2) Set record validation Rule - we want this procedure in the DBC to
> > execute when a record is changed:
> > setchange()
> >
> > 3) Create stored procedure in DBC called SetChange:
> > PROCEDURE setChange
> > TRY
> > IF glSetChange
> > REPLACE CHANGE WITH DATETIME()
> > ENDIF
> > CATCH
> > * WAIT WINDOW 'An error has occured'
> > ENDTRY
> >
> > RETURN .T.
> > ENDPROC
> >
> > 4) Run this code:
> > USE ZOOT
> > SET STEP ON
> > REPLACE Z1 WITH 'NoZoot', Z2 WITH BadVarName
> >
> > Notice that glSetChange is uninitialized. This is by design. Notice
> > that BadVarName is undefined. In order to reproduce this error, you
> > need a two part REPLACE, and the first one (Z1 WITH 'NoZoot') must be
> > valid, and the second one (Z2 WITH BadVarName) must be invalid IE
> > have a runtime error such as uninitialized variable or invalid
> > table/field name, etc.
> >
> > Observed Behavior:
> >
> >
> > I step through the code via the above SET STEP because if you dont,
> > sometimes VFP will just hard terminate, poof and it's gone. If you
> > step through it, when you get to this line:
> >
> > TRY
> > IF glSetChange
> >
> > You should get a c0000029.
> >
> > It varies according to the code in SetChange, but it will consistently
> > crash. If I change the code slightly , I can get c0000005, c0000029.
> > I also get MS VC++ Runtime Library error, Buffer overrun detected
> > error. The code I posted above seems to consistently produce c0000029.
> >
> > This, for example,
> >
> > IF glSetChange .AND. 1 = 1
> >
> > seems to produce a buffer overrun warning, other variations produce a
> > mismatched push/pop type of message.
> >
> >
> > Expected Behavior:
> > A trappable VFP error should be generated, not a hard crash.
> >
> > Additional Information:
> >
> > I can get a crash in VFP7 by using this code in SetChange:
> >
> > PROCEDURE setChange
> > ON ERROR llZOOT = .T.
> > IF glSetChange
> > REPLACE CHANGE WITH DATETIME()
> > ENDIF
> > ON ERROR
> > RETURN .T.
> > ENDPROC
> >
> > Since VFP7 does not support TRY/CATCH, I use traditional error
> > trapping instead.
> >
> > In VFP9 the same process generates a c0000005 error.
>
>

Andrew
Wed Jan 12 08:31:20 CST 2005

Dan Freeman wrote:
> You may have brought some of this on yourself.
>
> 1) CHANGE is a reserved word. (Equivalent to EDIT.)


I wish it checked for this in the GUI version of alter table and at least
gave a warning. I've inherited a system with a table called ORDER and it
causes no end of problems with SELECT statements.

--
Regards
Andrew Howell

GaryZ
Wed Jan 12 10:21:05 CST 2005

"Andrew Howell" wrote:

> I've inherited a system with a table called ORDER and it
> causes no end of problems with SELECT statements.
>
> --
> Regards
> Andrew Howell
>

In one of our old systems we had a table containing file indexing
information. The name of the table was "Index.DBF" and the name of the index
file was "Index.idx" The command line for opening the table would read:

USE index INDEX index

And that actually worked! Aint that hillarious!

GaryZ

Dan
Wed Jan 12 11:20:44 CST 2005

Ah, but it's not "illegal" -- it just "may" cause problems. (Usually when
you least expect them.)

I think it was David Frankenbach who tested something like this:

SELECT SELECT FROM FROM AS BY ORDER BY BY

<g>

Dan

Andrew Howell wrote:
> Dan Freeman wrote:
>> You may have brought some of this on yourself.
>>
>> 1) CHANGE is a reserved word. (Equivalent to EDIT.)
>
>
> I wish it checked for this in the GUI version of alter table and at
> least gave a warning. I've inherited a system with a table called
> ORDER and it causes no end of problems with SELECT statements.

Gene
Wed Jan 12 11:44:20 CST 2005

On Wed, 12 Jan 2005 08:21:05 -0800, "GaryZ"
<GaryZ@discussions.microsoft.com> wrote:

>"Andrew Howell" wrote:
>
>> I've inherited a system with a table called ORDER and it
>> causes no end of problems with SELECT statements.

>In one of our old systems we had a table containing file indexing
>information. The name of the table was "Index.DBF" and the name of the index
>file was "Index.idx" The command line for opening the table would read:
>
>USE index INDEX index
>
>And that actually worked! Aint that hillarious!

I have observed that using reserved words in VFP is usually
harmless. If the reserved word is valid in the context, it gets
interesting. HOWEVER, it is too easy to have the keyword valid in
some context in later commmands. I once injudiciously named a column
"status". During some debugging, list status did not do what I was
expecting. I quickly changed the name.

Sincerely,

Gene Wirchenko

GaryZ
Wed Jan 12 12:17:03 CST 2005

Expanding on this, I created two tables:

FROM.DBF containing the numeric field SELECT
I added the numbers 1 through 10 in random order.

JOIN.DBF containing the indexed numeric field JOIN
I added odd numbers 1 through 9 in random order.

and here we go:

SELECT select AS by ;
FROM from ;
INNER JOIN join ;
ON from.select = join.join ;
INTO CURSOR cursor ;
GROUP BY by ;
ORDER BY by

result as expected: 5 records in a cursor named cursor.

By by now.

"Dan Freeman" wrote:

> Ah, but it's not "illegal" -- it just "may" cause problems. (Usually when
> you least expect them.)
>
> I think it was David Frankenbach who tested something like this:
>
> SELECT SELECT FROM FROM AS BY ORDER BY BY
>
> <g>
>
> Dan
>
> Andrew Howell wrote:
> > Dan Freeman wrote:
> >> You may have brought some of this on yourself.
> >>
> >> 1) CHANGE is a reserved word. (Equivalent to EDIT.)
> >
> >
> > I wish it checked for this in the GUI version of alter table and at
> > least gave a warning. I've inherited a system with a table called
> > ORDER and it causes no end of problems with SELECT statements.
>
>
>

Dan
Wed Jan 12 12:51:56 CST 2005

ROFL!

GaryZ wrote:
> Expanding on this, I created two tables:
>
> FROM.DBF containing the numeric field SELECT
> I added the numbers 1 through 10 in random order.
>
> JOIN.DBF containing the indexed numeric field JOIN
> I added odd numbers 1 through 9 in random order.
>
> and here we go:
>
> SELECT select AS by ;
> FROM from ;
> INNER JOIN join ;
> ON from.select = join.join ;
> INTO CURSOR cursor ;
> GROUP BY by ;
> ORDER BY by
>
> result as expected: 5 records in a cursor named cursor.
>
> By by now.
>
> "Dan Freeman" wrote:
>
>> Ah, but it's not "illegal" -- it just "may" cause problems. (Usually
>> when you least expect them.)
>>
>> I think it was David Frankenbach who tested something like this:
>>
>> SELECT SELECT FROM FROM AS BY ORDER BY BY
>>
>> <g>
>>
>> Dan
>>
>> Andrew Howell wrote:
>>> Dan Freeman wrote:
>>>> You may have brought some of this on yourself.
>>>>
>>>> 1) CHANGE is a reserved word. (Equivalent to EDIT.)
>>>
>>>
>>> I wish it checked for this in the GUI version of alter table and at
>>> least gave a warning. I've inherited a system with a table called
>>> ORDER and it causes no end of problems with SELECT statements.

Paul
Wed Jan 12 13:06:02 CST 2005


"Andrew Howell" <ajh@work> wrote in message
news:%23lbAnNL%23EHA.3820@TK2MSFTNGP11.phx.gbl...
> I've inherited a system with a table called ORDER and it
> causes no end of problems with SELECT statements.


I inherited one with a field called VALUE, which worked OK until I added
buffering.

One of these days I expect to come across a table alias M, which will cause
havoc when trying to separate fields from variables.

Gene
Wed Jan 12 13:57:12 CST 2005

On Wed, 12 Jan 2005 10:17:03 -0800, "GaryZ"
<GaryZ@discussions.microsoft.com> wrote:

>Expanding on this, I created two tables:
>
>FROM.DBF containing the numeric field SELECT
>I added the numbers 1 through 10 in random order.
>
>JOIN.DBF containing the indexed numeric field JOIN
>I added odd numbers 1 through 9 in random order.
>
>and here we go:
>
>SELECT select AS by ;
> FROM from ;
> INNER JOIN join ;
> ON from.select = join.join ;
> INTO CURSOR cursor ;
> GROUP BY by ;
> ORDER BY by
>
>result as expected: 5 records in a cursor named cursor.

There are some of us who have names that are keywords or short
forms of them.

[snip]

Sincerely,

Gene "GENERAL" Wirchenko

Fred
Wed Jan 12 23:21:53 CST 2005

"Paul Pedersen" <no-reply@swen.com> wrote in message
news:e0I2DnN%23EHA.1296@TK2MSFTNGP10.phx.gbl...
>
> "Andrew Howell" <ajh@work> wrote in message
> news:%23lbAnNL%23EHA.3820@TK2MSFTNGP11.phx.gbl...
>> I've inherited a system with a table called ORDER and it
>> causes no end of problems with SELECT statements.
>
>
> I inherited one with a field called VALUE, which worked OK until I added
> buffering.
>
> One of these days I expect to come across a table alias M, which will
> cause havoc when trying to separate fields from variables.
>

Can't get there from here. Trying to open a table with an alias of "m" gets
you an "alias name is already in use" error. Even opening a table in area
13 won't get you an alias of "m".

--
Fred
Microsoft Visual FoxPro MVP

Andrew
Thu Jan 13 02:27:08 CST 2005

Fred Taylor wrote:
> Can't get there from here. Trying to open a table with an alias of
> "m" gets you an "alias name is already in use" error. Even opening a
> table in area 13 won't get you an alias of "m".

Although you can use it as a short alias in SQL:

m.test="STRING"
SELECT field ;
FROM table m ;
WHERE field=m.test

I did actually do this by accident once but only because I have a habit of
using the first letter of a table for its short alias and the table in
question was called "material"

--
Regards
Andrew Howell