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 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.
