Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Crashing VFP from error handler
Message
From
20/12/2021 13:36:23
 
 
To
20/12/2021 11:38:44
General information
Forum:
Visual FoxPro
Category:
Troubleshooting
Miscellaneous
Thread ID:
01682978
Message ID:
01683028
Views:
56
>>>>>Hi Tamar,
>>>>>
>>>>>
>>>>>		insert into ERRORLOG ;
>>>>>              (DATE, TIME, USER, TERMINAL, CUSTOMER, ALIAS,;
>>>>>               RECNUM, KEYFLD, ERRMSG1, ERRMSG2, ERRMSG3, ACTION, ;
>>>>>				MEMVARS, DETAILS, CALLSTACK) ;
>>>>>		   values ;
>>>>>		      (date(), time(), gcUSER_NAME, SysZero(), space(len(customer)), lcALIAS, ;
>>>>>               lnREC, lcKEY, lcLINE1, lcLINE2, lcLINE3, 'REBOOT',;
>>>>>               '', m.lcDetails, m.lcStackInfo)
>>>>>
>>>>>
>>>>>- Could SysZero() change alias() or insert a log row itself or otherwise interfere with the insert midstream?
>>>>>
>>>>
>>>>Nope, SysZero reads one environmental variable (GETENV()) and cleans up and returns the result.
>>>>
>>>>>- and -
>>>>>
>>>>>Does space(len(customer)) rely on selected alias? If it's a variable, try with mdot or what happens if you replace with "" ?
>>>>
>>>>Nope, Customer here is a field in ErrorLog, so just inserting an empty value there. Guess I could try just the empty string. (Inherited code, and policy through the app is to use space(len(field)) for empty values, but certainly makes no difference here.
>>>>
>>>>The weird thing, of course, is that all this is working for everyone else, so it has to be something local.
>>>>
>>>>Tamar
>>>
>>>Does it fail every time, or is there something that a bit feels random? If the later I would look for the hardware. Some corrupted memory that will only be reached if you log. While use of memory looks like random, in many cases it is not. Anyway, scanning the memory might be not a bad idea.
>>
>>It's crashing whenever this error handler code runs. The only thing that's at all random is whether I get an error message first.
>>
>>I can certainly run some hardware checks, though.
>>
>>Thanks,
>>Tamar
>
>Sounds like the problem isn't the error handler itself, but the error that triggers it. Can you reproduce by calling the error handler directly?

Interesting idea. It's any error that fires the error handler (I've been doing my testing by having ERROR 11 early in the application, for example), but good question. Does calling this program cause the problem? Adding to my list.

Tamar
Previous
Reply
Map
View

Click here to load this message in the networking platform