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.
