Re: Buffer overruns stuff
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
...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
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
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
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
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
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.