Re: Buffer overruns stuff

2007-02-12 Thread Charlie Coleman
At 05:35 PM 2/7/2007 -0500, MB Software Solutions wrote:
  The source is a VFP cursor created by querying an MSSQL db. My app reads
  from  parses the data in the cursor into native VFP tables stored
  locally. There's no user interface. Crash about every 15min.
 
 

Use DotNet.   gdrvvf

Why? So it could crash every 5 minutes? I think the desire was to keep it 
from crashing...

;-)

-Charlie 



___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
** All postings, unless explicitly stated otherwise, are the opinions of the 
author, and do not constitute legal or medical advice. This statement is added 
to the messages for those lawyers who are too stupid to see the obvious.


RE: Buffer overruns stuff

2007-02-08 Thread John Weller
Sounds interesting - could you upload it perhaps?

John Weller
01380 723235
07976 393631 

 
 I wouldn't bother writing such a system (which I plan to do for my next
 projects) since I already have one that works quite well.  Let 
 me know if you
 are interested.  It gets around many of the issues with using the 
 debugger and
 works well if you accidentally leave the code in your application.  
 


___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
** All postings, unless explicitly stated otherwise, are the opinions of the 
author, and do not constitute legal or medical advice. This statement is added 
to the messages for those lawyers who are too stupid to see the obvious.


Re: Buffer overruns stuff

2007-02-08 Thread Derek Kalweit
 I wouldn't bother writing such a system (which I plan to do for my next
 projects) since I already have one that works quite well.  Let me know if you
 are interested.  It gets around many of the issues with using the debugger and
 works well if you accidentally leave the code in your application.

You should upload it to Ed's site so we can all take a look. I may
have to tweak it to make it work the way I want, but it could be a
good base. It shouldn't really be that complex-- just a dozen or two
lines of code at most...

http://leafe.com/dls/upload


-- 
Derek


___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
** All postings, unless explicitly stated otherwise, are the opinions of the 
author, and do not constitute legal or medical advice. This statement is added 
to the messages for those lawyers who are too stupid to see the obvious.


Re: Buffer overruns stuff

2007-02-07 Thread Derek Kalweit
 Totally unattended. It reads data from it's source, parses it and stores
 it as fast as the hard/software combo will allow. Absolutely no user
 input. Time bomb or messy code wouldn't surprise me at all.

What is the 'source' and 'destination'? I'm assuming one is MSSQL, but
what's the other? You say 'hard/software combo', so I'm wondering if
you might be interfacing with hardware? Or are you referring simply to
the local computer? How often is it crashing? Anything in the event
logs?


-- 
Derek


___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
** All postings, unless explicitly stated otherwise, are the opinions of the 
author, and do not constitute legal or medical advice. This statement is added 
to the messages for those lawyers who are too stupid to see the obvious.


RE: Buffer overruns stuff

2007-02-07 Thread Lew Schwartz
The source is a VFP cursor created by querying an MSSQL db. My app reads
from  parses the data in the cursor into native VFP tables stored
locally. There's no user interface. Crash about every 15min. 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Derek Kalweit
Sent: Wednesday, February 07, 2007 10:38 AM
To: [EMAIL PROTECTED]
Subject: Re: Buffer overruns  stuff

 Totally unattended. It reads data from it's source, parses it and 
 stores it as fast as the hard/software combo will allow. Absolutely no

 user input. Time bomb or messy code wouldn't surprise me at all.

What is the 'source' and 'destination'? I'm assuming one is MSSQL, but
what's the other? You say 'hard/software combo', so I'm wondering if you
might be interfacing with hardware? Or are you referring simply to the
local computer? How often is it crashing? Anything in the event logs?


--
Derek


[excessive quoting removed by server]

___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
** All postings, unless explicitly stated otherwise, are the opinions of the 
author, and do not constitute legal or medical advice. This statement is added 
to the messages for those lawyers who are too stupid to see the obvious.


Re: Buffer overruns stuff

2007-02-07 Thread MB Software Solutions
Lew Schwartz wrote:
 The source is a VFP cursor created by querying an MSSQL db. My app reads
 from  parses the data in the cursor into native VFP tables stored
 locally. There's no user interface. Crash about every 15min. 

   

Use DotNet.   gdrvvf

-- 
Michael J. Babcock, MCP
MB Software Solutions, LLC
http://mbsoftwaresolutions.com
http://fabmate.com
Work smarter, not harder, with MBSS custom software solutions!



___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
** All postings, unless explicitly stated otherwise, are the opinions of the 
author, and do not constitute legal or medical advice. This statement is added 
to the messages for those lawyers who are too stupid to see the obvious.


Re: Buffer overruns stuff

2007-02-07 Thread Derek Kalweit
 The source is a VFP cursor created by querying an MSSQL db. My app reads
 from  parses the data in the cursor into native VFP tables stored
 locally. There's no user interface. Crash about every 15min.

If it's that re-creatable, then it's time to start adding trace code,
IMO-- to find where the problem is happening. I use STRTOFILE for
this:

STRTOFILE(Some meaningful string + CHR(13) + CHR(10), c:\out.log, .T.)

This will append a line to the c:\out.log file-- change your strings
to something useful to know where in the code it's happening(put it in
key spots right before something you suspect to be the potential
problem-- it can be very high level in the code, especially at first).

You can also write a more robust tracing mechanism, which I plan to do
for my next projects. Basically, you call the function throughout your
code, and the function queries a setting to see if tracing is 'on',
and potentially at what level, and if so outputs it to the text file
with a date/time stamp, etc. I've used it in C++ programs as a
debugging mechanism and it's been extremely valuable. I turn it on
with a registry setting. One of the key things I like to do is add
start:functionname() and end:functionname() things to the beginning
and ending of functions/methods when I write my code initially-- this
lets me know very early on what overall function/method the crash is
occuring in...


-- 
Derek


___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
** All postings, unless explicitly stated otherwise, are the opinions of the 
author, and do not constitute legal or medical advice. This statement is added 
to the messages for those lawyers who are too stupid to see the obvious.


RE: Buffer overruns stuff

2007-02-07 Thread Fletcher Johnson
Derek,

I wouldn't bother writing such a system (which I plan to do for my next
projects) since I already have one that works quite well.  Let me know if you
are interested.  It gets around many of the issues with using the debugger and
works well if you accidentally leave the code in your application.  

Take care,

Fletcher

Fletcher Johnson
[EMAIL PROTECTED]
408-929-5678 - Cell
408-946-0960 - Work
501-421-9629 - Fax 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Derek Kalweit
Sent: Wednesday, February 07, 2007 2:56 PM
To: profox@leafe.com
Subject: Re: Buffer overruns  stuff

 The source is a VFP cursor created by querying an MSSQL db. My app 
 reads from  parses the data in the cursor into native VFP tables 
 stored locally. There's no user interface. Crash about every 15min.

If it's that re-creatable, then it's time to start adding trace code,
IMO-- to find where the problem is happening. I use STRTOFILE for
this:

STRTOFILE(Some meaningful string + CHR(13) + CHR(10), c:\out.log, .T.)

This will append a line to the c:\out.log file-- change your strings to
something useful to know where in the code it's happening(put it in key spots
right before something you suspect to be the potential
problem-- it can be very high level in the code, especially at first).

You can also write a more robust tracing mechanism, which I plan to do for my
next projects. Basically, you call the function throughout your code, and the
function queries a setting to see if tracing is 'on', and potentially at what
level, and if so outputs it to the text file with a date/time stamp, etc. I've
used it in C++ programs as a debugging mechanism and it's been extremely
valuable. I turn it on with a registry setting. One of the key things I like to
do is add
start:functionname() and end:functionname() things to the beginning and ending
of functions/methods when I write my code initially-- this lets me know very
early on what overall function/method the crash is occuring in...


--
Derek


[excessive quoting removed by server]

___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
** All postings, unless explicitly stated otherwise, are the opinions of the 
author, and do not constitute legal or medical advice. This statement is added 
to the messages for those lawyers who are too stupid to see the obvious.


RE: Buffer overruns stuff

2007-02-06 Thread Lew Schwartz
The problem predates SetMemory(), there are no other api calls. This is
XP pro. I haven't tested the difference between app's vs exe's. I'm
using apps for now, but a standalone exe is in the near future. I'll try
to see if there's a particular place or routine that blows up today, but
I don't think so.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Derek Kalweit
Sent: Monday, February 05, 2007 5:41 PM
To: [EMAIL PROTECTED]
Subject: Re: Buffer overrins  stuff

No, it isn't a native VFP error. VFP is written in MS c++ so 
 the undelying libraries have MS c++ error messages. When a pointer 
 references a memory location outside of the space allocated for vfp, 
 c++ generates this error. It's a boiler plate message; it never 
 changes and it never gives any additional information.

Yes-- I'm primarily making sure it's created by the VFP process and not
something you're observing through a c++ debugger you've attached to the
process or anything.


No flls or api calls in the app.

You are using API calls in Ed's setmemory.prg. What O/S are you running
under? interpretted and/or compiled?

Have you commented Ed's setmemory.prg to see if that's causing the
issue? I'm curious, considering you're bringing it up-- unless it's the
cause, it shouldn't matter-- a buffer over-run is an error in code and
shouldn't be related to available memory whatsoever.

Have you been able to narrow it down to any part of your code? I've had
many VFP functions with known buffer overrun problems, such as
TEXTMERGE() in VFP7. There was a work-around then that you can pass the
string with a chr(0) at the end(effectively zero-terminating the
c++ buffer properly). I wrote simple Z() and NZ() functions for this
purpose-- adding and removing the trailing nulls..


--
Derek


[excessive quoting removed by server]

___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
** All postings, unless explicitly stated otherwise, are the opinions of the 
author, and do not constitute legal or medical advice. This statement is added 
to the messages for those lawyers who are too stupid to see the obvious.


Re: Buffer overruns stuff

2007-02-06 Thread Derek Kalweit
 The problem predates SetMemory(), there are no other api calls. This is
 XP pro. I haven't tested the difference between app's vs exe's. I'm
 using apps for now, but a standalone exe is in the near future. I'll try
 to see if there's a particular place or routine that blows up today, but
 I don't think so.

Your OP indicated that you may have just upgraded to a dual-core CPU--
is that correct? That would indicate a potential
synchronization/multi-threading bug that hasn't presented itself until
the system actually could have synchronous threads.

Do you have the most recent updates for Windows XP?

Running the most recent VFP service pack? What version of VFP?

You also mention SQL connections-- is this MSSQL? What version? I'm
trusting you're using VFP's ODBC-based support for MySQL, or are you
using ADO?


-- 
Derek


___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
** All postings, unless explicitly stated otherwise, are the opinions of the 
author, and do not constitute legal or medical advice. This statement is added 
to the messages for those lawyers who are too stupid to see the obvious.


RE: Buffer overruns stuff

2007-02-06 Thread Lew Schwartz
Yep, dual core, although I've had the problem on my single processor
laptop. XP is up to date as is VFP (9/sp1). Yes, it's MSSQL, but the
driver isn't the problem since the manager for whom I'm developing the
project won't allow me to see the connection code/string. Accordingly,
I've copied all the data to my local hd  have tested from there. Still
had the problem (although to as often).

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Derek Kalweit
Sent: Tuesday, February 06, 2007 12:22 PM
To: [EMAIL PROTECTED]
Subject: Re: Buffer overruns  stuff

 The problem predates SetMemory(), there are no other api calls. This 
 is XP pro. I haven't tested the difference between app's vs exe's. I'm

 using apps for now, but a standalone exe is in the near future. I'll 
 try to see if there's a particular place or routine that blows up 
 today, but I don't think so.

Your OP indicated that you may have just upgraded to a dual-core CPU--
is that correct? That would indicate a potential
synchronization/multi-threading bug that hasn't presented itself until
the system actually could have synchronous threads.

Do you have the most recent updates for Windows XP?

Running the most recent VFP service pack? What version of VFP?

You also mention SQL connections-- is this MSSQL? What version? I'm
trusting you're using VFP's ODBC-based support for MySQL, or are you
using ADO?


--
Derek


[excessive quoting removed by server]

___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
** All postings, unless explicitly stated otherwise, are the opinions of the 
author, and do not constitute legal or medical advice. This statement is added 
to the messages for those lawyers who are too stupid to see the obvious.


RE: Buffer overruns stuff

2007-02-06 Thread Fletcher Johnson
Lew,

I was using a dual core cpu based XP system to work with an MS SQL database.
Using both remote views as well as SQL pass-through, I did not encounter this
problem.  The application is in use at locations throughout the U.S. again
without such a problem (although I doubt these installations are using similar
cpus)

I can offer you two ideas.

1) Try the basic approach of narrowing down the code to the fewest number of
lines that still reproduce the problem.  Just doing this often identifies it.
But if not, post that code and we can test it on our computers.  Unfortunately,
mine is in the shop until 2-20 so I hope others here can help you before then.

2) Does this happen when you are stepping through the code or only during run
time when the debugger is not active? If the latter, I have a debugging tool
that might still help you identify the problem, should you be so interested.

Take care 

Fletcher

Fletcher Johnson
[EMAIL PROTECTED]
408-929-5678 - Cell
408-946-0960 - Work
501-421-9629 - Fax 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Lew Schwartz
Sent: Tuesday, February 06, 2007 7:34 AM
To: profox@leafe.com
Subject: RE: Buffer overruns  stuff

The problem predates SetMemory(), there are no other api calls. This is XP pro.
I haven't tested the difference between app's vs exe's. I'm using apps for now,
but a standalone exe is in the near future. I'll try to see if there's a
particular place or routine that blows up today, but I don't think so.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Derek Kalweit
Sent: Monday, February 05, 2007 5:41 PM
To: [EMAIL PROTECTED]
Subject: Re: Buffer overrins  stuff

No, it isn't a native VFP error. VFP is written in MS c++ so 
 the undelying libraries have MS c++ error messages. When a pointer 
 references a memory location outside of the space allocated for vfp,
 c++ generates this error. It's a boiler plate message; it never
 changes and it never gives any additional information.

Yes-- I'm primarily making sure it's created by the VFP process and not
something you're observing through a c++ debugger you've attached to the
process or anything.


No flls or api calls in the app.

You are using API calls in Ed's setmemory.prg. What O/S are you running
under? interpretted and/or compiled?

Have you commented Ed's setmemory.prg to see if that's causing the
issue? I'm curious, considering you're bringing it up-- unless it's the
cause, it shouldn't matter-- a buffer over-run is an error in code and
shouldn't be related to available memory whatsoever.

Have you been able to narrow it down to any part of your code? I've had
many VFP functions with known buffer overrun problems, such as
TEXTMERGE() in VFP7. There was a work-around then that you can pass the
string with a chr(0) at the end(effectively zero-terminating the
c++ buffer properly). I wrote simple Z() and NZ() functions for this
purpose-- adding and removing the trailing nulls..


--
Derek


[excessive quoting removed by server]

___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
** All postings, unless explicitly stated otherwise, are the opinions of the 
author, and do not constitute legal or medical advice. This statement is added 
to the messages for those lawyers who are too stupid to see the obvious.


RE: Buffer overruns stuff

2007-02-06 Thread Lew Schwartz
Thanks, Fletcher. Since it never occurs in the same place twice, I can't
narrow down to a reproducable error. I have removed dbc events, changed
my on error from on error createobject(errorhandler) to the old
fashioned on error do ...  and threw in a sys(1104). Today, so far, no
explosions.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Fletcher Johnson
Sent: Tuesday, February 06, 2007 12:48 PM
To: [EMAIL PROTECTED]
Subject: RE: Buffer overruns  stuff

Lew,

I was using a dual core cpu based XP system to work with an MS SQL
database.
Using both remote views as well as SQL pass-through, I did not encounter
this problem.  The application is in use at locations throughout the
U.S. again without such a problem (although I doubt these installations
are using similar
cpus)

I can offer you two ideas.

1) Try the basic approach of narrowing down the code to the fewest
number of lines that still reproduce the problem.  Just doing this often
identifies it.
But if not, post that code and we can test it on our computers.
Unfortunately, mine is in the shop until 2-20 so I hope others here can
help you before then.

2) Does this happen when you are stepping through the code or only
during run time when the debugger is not active? If the latter, I have a
debugging tool that might still help you identify the problem, should
you be so interested.

Take care 

Fletcher

Fletcher Johnson
[EMAIL PROTECTED]
408-929-5678 - Cell
408-946-0960 - Work
501-421-9629 - Fax 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Lew Schwartz
Sent: Tuesday, February 06, 2007 7:34 AM
To: profox@leafe.com
Subject: RE: Buffer overruns  stuff

The problem predates SetMemory(), there are no other api calls. This is
XP pro.
I haven't tested the difference between app's vs exe's. I'm using apps
for now, but a standalone exe is in the near future. I'll try to see if
there's a particular place or routine that blows up today, but I don't
think so.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Derek Kalweit
Sent: Monday, February 05, 2007 5:41 PM
To: [EMAIL PROTECTED]
Subject: Re: Buffer overrins  stuff

No, it isn't a native VFP error. VFP is written in MS c++ so 
 the undelying libraries have MS c++ error messages. When a pointer 
 references a memory location outside of the space allocated for vfp,
 c++ generates this error. It's a boiler plate message; it never
 changes and it never gives any additional information.

Yes-- I'm primarily making sure it's created by the VFP process and not
something you're observing through a c++ debugger you've attached to the
process or anything.


No flls or api calls in the app.

You are using API calls in Ed's setmemory.prg. What O/S are you running
under? interpretted and/or compiled?

Have you commented Ed's setmemory.prg to see if that's causing the
issue? I'm curious, considering you're bringing it up-- unless it's the
cause, it shouldn't matter-- a buffer over-run is an error in code and
shouldn't be related to available memory whatsoever.

Have you been able to narrow it down to any part of your code? I've had
many VFP functions with known buffer overrun problems, such as
TEXTMERGE() in VFP7. There was a work-around then that you can pass the
string with a chr(0) at the end(effectively zero-terminating the
c++ buffer properly). I wrote simple Z() and NZ() functions for this
purpose-- adding and removing the trailing nulls..


--
Derek


[excessive quoting removed by server]

___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
** All postings, unless explicitly stated otherwise, are the opinions of the 
author, and do not constitute legal or medical advice. This statement is added 
to the messages for those lawyers who are too stupid to see the obvious.


RE: Buffer overruns stuff

2007-02-06 Thread Sales Info
Lew,

I have several VFP applications that have been running non-stop for
years. Every time a new release of VFP comes out, I've recompiled and
re-installed without problem.

One suggestion: You might try sprinkling some ...

strtofile( timestamp, global counter and some diagnostics or code
location, myapp.log, .T. )

throughout your code to see where you code is failing. When your system
fails, review the log and see if there's a pattern.

Malcolm


___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
** All postings, unless explicitly stated otherwise, are the opinions of the 
author, and do not constitute legal or medical advice. This statement is added 
to the messages for those lawyers who are too stupid to see the obvious.


RE: Buffer overruns stuff

2007-02-06 Thread Lew Schwartz
Your 2  4 look interesting since I have any number of abends,
delibretate and otherwise, during development. Plus, for reasons I don't
understand, my manager keeps the connection code secret. Is there such a
thing as a dangling connection and/or a way to detect it?
-Lew 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Fletcher Johnson
Sent: Tuesday, February 06, 2007 1:19 PM
To: [EMAIL PROTECTED]
Subject: RE: Buffer overruns  stuff

Lew,

Some things to try:

1) Run MSConfig and turn of everything unless you need it.  Including
anti virus, etc.  Then, do nothing but run the application.  

2) One problem I had that generated weird messages was when I was using
a connection that would occasionally disconnect and then reconnect.
Most apps worked well.  But my SQL connections did NOT like it.  This
took a while to track down

3) It could be that there is a call you are doing that has a memory
leak.  This call may be made a variable number of times.  One example
might be a test to see if the remote server exists before you try to
connect to it.  This would have a loop that would run until we got a
timeout or acknowledgement from the server.
Since the loop would run a variable amount of times each time it was
called, the effect of each call can vary.

4) Could you be leaving a connection open?  In one case, I had some code
that created a handle, but never specifically disconnected it.  Over
time, this would accumulate until the computer got upset.  And, in this
case, the connection was only created by a procedure that was doing a
verification - so it was easy to overlook that part of the code.

If this doesn't help, I may have some others for you.

Take care,

Fletcher

Fletcher Johnson
[EMAIL PROTECTED]
408-929-5678 - Cell
408-946-0960 - Work
501-421-9629 - Fax 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Lew Schwartz
Sent: Tuesday, February 06, 2007 9:54 AM
To: profox@leafe.com
Subject: RE: Buffer overruns  stuff

Thanks, Fletcher. Since it never occurs in the same place twice, I can't
narrow down to a reproducable error. I have removed dbc events, changed
my on error from on error createobject(errorhandler) to the old
fashioned on error do ...
and threw in a sys(1104). Today, so far, no explosions.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Fletcher Johnson
Sent: Tuesday, February 06, 2007 12:48 PM
To: [EMAIL PROTECTED]
Subject: RE: Buffer overruns  stuff

Lew,

I was using a dual core cpu based XP system to work with an MS SQL
database.
Using both remote views as well as SQL pass-through, I did not encounter
this problem.  The application is in use at locations throughout the
U.S. again without such a problem (although I doubt these installations
are using similar
cpus)

I can offer you two ideas.

1) Try the basic approach of narrowing down the code to the fewest
number of lines that still reproduce the problem.  Just doing this often
identifies it.
But if not, post that code and we can test it on our computers.
Unfortunately, mine is in the shop until 2-20 so I hope others here can
help you before then.

2) Does this happen when you are stepping through the code or only
during run time when the debugger is not active? If the latter, I have a
debugging tool that might still help you identify the problem, should
you be so interested.

Take care 

Fletcher

Fletcher Johnson
[EMAIL PROTECTED]
408-929-5678 - Cell
408-946-0960 - Work
501-421-9629 - Fax 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Lew Schwartz
Sent: Tuesday, February 06, 2007 7:34 AM
To: profox@leafe.com
Subject: RE: Buffer overruns  stuff

The problem predates SetMemory(), there are no other api calls. This is
XP pro.
I haven't tested the difference between app's vs exe's. I'm using apps
for now, but a standalone exe is in the near future. I'll try to see if
there's a particular place or routine that blows up today, but I don't
think so.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Derek Kalweit
Sent: Monday, February 05, 2007 5:41 PM
To: [EMAIL PROTECTED]
Subject: Re: Buffer overrins  stuff

No, it isn't a native VFP error. VFP is written in MS c++ so 
 the undelying libraries have MS c++ error messages. When a pointer 
 references a memory location outside of the space allocated for vfp,
 c++ generates this error. It's a boiler plate message; it never
 changes and it never gives any additional information.

Yes-- I'm primarily making sure it's created by the VFP process and not
something you're observing through a c++ debugger you've attached to the
process or anything.


No flls or api calls in the app.

You are using API calls in Ed's setmemory.prg. What O/S are you running
under?
interpretted and/or compiled?

Have you commented Ed's setmemory.prg to see if that's causing the
issue? I'm

RE: Buffer overruns stuff

2007-02-06 Thread Lew Schwartz
...already logging like a sob. 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Sales Info
Sent: Tuesday, February 06, 2007 1:31 PM
To: [EMAIL PROTECTED]
Subject: RE: Buffer overruns  stuff

Lew,

I have several VFP applications that have been running non-stop for
years. Every time a new release of VFP comes out, I've recompiled and
re-installed without problem.

One suggestion: You might try sprinkling some ...

strtofile( timestamp, global counter and some diagnostics or code
location, myapp.log, .T. )

throughout your code to see where you code is failing. When your system
fails, review the log and see if there's a pattern.

Malcolm


[excessive quoting removed by server]

___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
** All postings, unless explicitly stated otherwise, are the opinions of the 
author, and do not constitute legal or medical advice. This statement is added 
to the messages for those lawyers who are too stupid to see the obvious.


Re: Buffer overruns stuff

2007-02-06 Thread Derek Kalweit
 delibretate and otherwise, during development. Plus, for reasons I don't
 understand, my manager keeps the connection code secret. Is there such a

Maybe he wrote a time bomb?

What sort of application is this? Does it run un-attended? If it's
attended, what are you, as the user, doing at the time-- are you
clicking a save button that's writing data to SQL? opening something
that's loading data from SQL? Doing something after idle time?
Something else?


-- 
Derek


___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
** All postings, unless explicitly stated otherwise, are the opinions of the 
author, and do not constitute legal or medical advice. This statement is added 
to the messages for those lawyers who are too stupid to see the obvious.


RE: Buffer overruns stuff

2007-02-06 Thread Lew Schwartz
Totally unattended. It reads data from it's source, parses it and stores
it as fast as the hard/software combo will allow. Absolutely no user
input. Time bomb or messy code wouldn't surprise me at all. 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Derek Kalweit
Sent: Tuesday, February 06, 2007 3:08 PM
To: [EMAIL PROTECTED]
Subject: Re: Buffer overruns  stuff

 delibretate and otherwise, during development. Plus, for reasons I 
 don't understand, my manager keeps the connection code secret. Is 
 there such a

Maybe he wrote a time bomb?

What sort of application is this? Does it run un-attended? If it's
attended, what are you, as the user, doing at the time-- are you
clicking a save button that's writing data to SQL? opening something
that's loading data from SQL? Doing something after idle time?
Something else?


--
Derek


[excessive quoting removed by server]

___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
** All postings, unless explicitly stated otherwise, are the opinions of the 
author, and do not constitute legal or medical advice. This statement is added 
to the messages for those lawyers who are too stupid to see the obvious.


RE: Buffer overruns stuff

2007-02-06 Thread Fletcher Johnson
Lew,

The manager is probably protecting the connection code because it usually
includes a valid access account and password in an unencrypted format.  One way
I got around this was to have them create a QA account and use that in a
temporary connection until the problem was resolved.  Then they could just
disable that account until it was needed again in the future.

I don't know of a way off the top of my head to track when the connection
breaks, but there are ways to do it.  Windows can be set to notify you (usually
when using a wireless card) if the network connection breaks, so I would guess
there would be a similar ability to track data connections.  

Take care,

Fletcher

Fletcher Johnson
[EMAIL PROTECTED]
408-929-5678 - Cell
408-946-0960 - Work
501-421-9629 - Fax 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Lew Schwartz
Sent: Tuesday, February 06, 2007 11:18 AM
To: profox@leafe.com
Subject: RE: Buffer overruns  stuff

Your 2  4 look interesting since I have any number of abends, delibretate and
otherwise, during development. Plus, for reasons I don't understand, my manager
keeps the connection code secret. Is there such a thing as a dangling connection
and/or a way to detect it?
-Lew 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Fletcher Johnson
Sent: Tuesday, February 06, 2007 1:19 PM
To: [EMAIL PROTECTED]
Subject: RE: Buffer overruns  stuff

Lew,

Some things to try:

1) Run MSConfig and turn of everything unless you need it.  Including anti
virus, etc.  Then, do nothing but run the application.  

2) One problem I had that generated weird messages was when I was using a
connection that would occasionally disconnect and then reconnect.
Most apps worked well.  But my SQL connections did NOT like it.  This took a
while to track down

3) It could be that there is a call you are doing that has a memory leak.  This
call may be made a variable number of times.  One example might be a test to see
if the remote server exists before you try to connect to it.  This would have a
loop that would run until we got a timeout or acknowledgement from the server.
Since the loop would run a variable amount of times each time it was called, the
effect of each call can vary.

4) Could you be leaving a connection open?  In one case, I had some code that
created a handle, but never specifically disconnected it.  Over time, this would
accumulate until the computer got upset.  And, in this case, the connection was
only created by a procedure that was doing a verification - so it was easy to
overlook that part of the code.

If this doesn't help, I may have some others for you.

Take care,

Fletcher

Fletcher Johnson
[EMAIL PROTECTED]
408-929-5678 - Cell
408-946-0960 - Work
501-421-9629 - Fax 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Lew Schwartz
Sent: Tuesday, February 06, 2007 9:54 AM
To: profox@leafe.com
Subject: RE: Buffer overruns  stuff

Thanks, Fletcher. Since it never occurs in the same place twice, I can't narrow
down to a reproducable error. I have removed dbc events, changed my on error
from on error createobject(errorhandler) to the old fashioned on error do ...
and threw in a sys(1104). Today, so far, no explosions.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Fletcher Johnson
Sent: Tuesday, February 06, 2007 12:48 PM
To: [EMAIL PROTECTED]
Subject: RE: Buffer overruns  stuff

Lew,

I was using a dual core cpu based XP system to work with an MS SQL database.
Using both remote views as well as SQL pass-through, I did not encounter this
problem.  The application is in use at locations throughout the U.S. again
without such a problem (although I doubt these installations are using similar
cpus)

I can offer you two ideas.

1) Try the basic approach of narrowing down the code to the fewest number of
lines that still reproduce the problem.  Just doing this often identifies it.
But if not, post that code and we can test it on our computers.
Unfortunately, mine is in the shop until 2-20 so I hope others here can help you
before then.

2) Does this happen when you are stepping through the code or only during run
time when the debugger is not active? If the latter, I have a debugging tool
that might still help you identify the problem, should you be so interested.

Take care 

Fletcher

Fletcher Johnson
[EMAIL PROTECTED]
408-929-5678 - Cell
408-946-0960 - Work
501-421-9629 - Fax 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Lew Schwartz
Sent: Tuesday, February 06, 2007 7:34 AM
To: profox@leafe.com
Subject: RE: Buffer overruns  stuff

The problem predates SetMemory(), there are no other api calls. This is XP pro.
I haven't tested the difference between app's vs exe's. I'm using apps for now,
but a standalone exe is in the near future. I'll try to see if there's a
particular place

RE: Buffer overruns stuff

2007-02-06 Thread Sales Info
Lew,

Have a loader app (could be a batch file) that runs your main app in a
loop and only exits when a certain file is present locally.

Sample batch file (untested):

code
@echo off
:start
myapp.exe
if not exist myapp.quit goto start
del myapp.quit
/code

Have your main app exit every X minutes so it can get restarted by the
loader app.

Its a hack for sure, but desperate times often call for desperate
measures.

Malcolm


___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
** All postings, unless explicitly stated otherwise, are the opinions of the 
author, and do not constitute legal or medical advice. This statement is added 
to the messages for those lawyers who are too stupid to see the obvious.


RE: Buffer overruns stuff

2007-02-06 Thread Lew Schwartz
That's what it will come to if I can't nail this bug. 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Sales Info
Sent: Tuesday, February 06, 2007 4:26 PM
To: [EMAIL PROTECTED]
Subject: RE: Buffer overruns  stuff

Lew,

Have a loader app (could be a batch file) that runs your main app in a
loop and only exits when a certain file is present locally.

Sample batch file (untested):

code
@echo off
:start
myapp.exe
if not exist myapp.quit goto start
del myapp.quit
/code

Have your main app exit every X minutes so it can get restarted by the
loader app.

Its a hack for sure, but desperate times often call for desperate
measures.

Malcolm


[excessive quoting removed by server]

___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
** All postings, unless explicitly stated otherwise, are the opinions of the 
author, and do not constitute legal or medical advice. This statement is added 
to the messages for those lawyers who are too stupid to see the obvious.