Chasing a 'crash' in Foxypreview

[Bryan - Gendev]

To gather information on the cause of a crash in FoxyPreview where the same report and data runs in the standard VFP Reporting system I have set a coverage log to run.

After the crash I close my app and view the log file.

The final relevant output is

0.000291,_reportlistener,_reportlistener.unloadreport,8,c:\users\bryan\appdata\roaming\pathwiz9\pr_reportlistener.vct,14
0.000021,,on error,,,13

Is it possible to either

1 decode the error message - or

2 change the error handler to give more information

Thanks for any thoughts..

GenDev

 

[Olaf Doschke]

The log shows the error happened in line 8 of the unloadreport method of the _reportlistener class of the pr_reportlistener.vct (and vcx), and that was on stack level 14
Th next thing happening is ON ERROR on stack level 13, so you have an error, but that error isn't logged here, as no error handling is defined, obviously. Otherwise the cover.log would continue with log entries of which lines of code of an error handler are executed. Why don't you have an error handler, or have you cut the next lines? They are really not relevant, as they only show how many lines of your error handling run and how fast, but not which error, that would be in an error.log, if your error handler writes one.

The path to that vcx/vct makes me think: It's in your profile appdata roaming, looks like that should be elsewhere. Looks like you put the reportoutput.app of foxypreviewer somewhere it perhaps shouldn't be, looks like a redirect due to UAC.

If you want us to decode an error message, you have to post it, as said above that should be done by an error handler, no error info but the on error is logged via coverage. The cover.log is no error log, merely a log of lines executed. So what error happened should be in a seperate error log (,if your error handler writes one). So, what is your ON ERROR routine? Does it write a log? And what's in that log?

Bye, Olaf.

 

[Olaf Doschke]

ne more thing:

The benefit of a coverage actually would be to look back on more than just the last line before on error. Quite sure a few lines in the log, before the unloadreport, you can see what was happening before that. Sometimes, if there is not a single path, but many ways to come to a certain line, that can help see where a condition was set, that now caused that last line to error. You can't see very much, just which lines were executed, not how variable were set etc, this is all not in that log.

The line causing the ON ERROR can also be logged via a normal error handler, because PROGRAM(), LINENO() and some more will have that info about the line erroring, that's often already enough info to see the error, but if you don't take more than that last line from cover.log to have further analysis of how you came to that line of error, you're not making use of the coverage log. And if you don't make use of the further logging, you're really just wasting the time to write the coverage log.

Bye, Olaf.

 

[Bryan - Gendev]

Olaf,

I have an error handler

 

[Bryan - Gendev]

Olaf,

But the foxypreview error was not reported by my errorhandler

GenDev

 

[Olaf Doschke]

Well, we could now search in foxypreviewer code, if it redirects ON ERROR, but I assume foxypreviewer does not change that to it's own error handling.

If there is no entry in your error log, that would point to an c000:0005 erroor/exception, but then I wouldn't expect a line with ON ERROR in the cover.log

Sure you set your error handler before your REPORT FORM?

What you still can do is look into foxypreviewer source code of the _reportlistener class of the pr_reportlistener.vcx/vct, but you need to guess what error happened there.

Bye, Olaf.

 

[Olaf Doschke]

Line 8 of the unloadreport event of the _reportlistener class of pr_reportlistener.vcx is

IF NOT ISNULL(THIS.Successor)

Now find out why that causes an error and what type of error. The property window shows this is initialized with the Value NULL, so it wouldn't cause an error on it's own.

What about debugging this? Put a SET STEP ON right before that IF, recompile the foxypreviewer.app, put it where you use it and then run your report at design time, the debugger will chime in reight before the line that errors and you'll be able to see, what Successor is at that moment.

Bye, Olaf.

 

[Koen Piller]

Hi,

Your errorhandler says:

variable aData is not found
line of code with error: Insert into randData (aData) Values(RAND() * 100)
line nmbr: 67


So I would suggest to put a break at line 67 and see what happens to the array aData

Regards,

Jockey(2)

 

[Olaf Doschke]

Jockey,

nit sure, but that screenshot was merely demonstrating there is an error handler and error messages look that way. There was no log entry for the foxypreviewer error, even though the cover.log has a line with the ON ERROR in it.

I only see a chance with the specific c000:0005 exception or another ON("ERROR") state than the normal error handler. And the best thing to do is to debug what really happens. This has the advantage of being able to inspect variable values, etc. etc.

Bye, Olaf.

 

[Bryan - Gendev]

Jockey2

I made the bad code to show the form of my error messages as Olaf commented. Thanks

Olaf

I have received an offer of help from Cesar the author of foxypreview.

I have uploaded the whole coverage file ( as you said Olaf)

I will let you know of any results.

I will attempt the debug you suggest - thanks.

GenDev

 

[Bryan - Gendev]

Olaf,

I have debugged.

This.successor is .F. at that point - the next step is Store .T. To lTableError

This does not cause my error handler to output a message so there must be a separate one ???

GenDev

 

[Olaf Doschke]

Does the class have code in it's Error() event? This has precedence over ON ERROR.
In my version of foxypreviewer the Error event has this code in it, so the first code is LOCAL declarion and then THIS.HadError = .T.

LPARAMETERS m.nError, m.cMethod, m.nLine
LOCAL m.lcOnError,m.lcErrorMsg,m.lcCodeLineMsg
THIS.HadError = .T.
IF this.lIgnoreErrors OR _vfp.StartMode>0
	RETURN .F.
ENDIF
m.lcOnError=UPPER(ALLTRIM(ON("ERROR")))
IF NOT EMPTY(m.lcOnError)
	m.lcOnError=STRTRAN(STRTRAN(STRTRAN(lcOnError,"ERROR()","nError"), ;
			"PROGRAM()","cMethod"),"LINENO()","nLine")
	&lcOnError
	RETURN
ENDIF
m.lcErrorMsg = THIS.PrepareErrorMessage(m.nError,m.cMethod, m.nLine)
THIS.LastErrorMessage = m.lcErrorMsg

THIS.DoMessage(m.lcErrorMsg, MB_ICONSTOP )

#IF OUTPUTCLASS_DEBUGGING
    ERROR m.nError
#ENDIF

But I would expect lines of the Error() event logged in cover.log.
Are you perhaps using an outdated version of foxypreviewer?

Bye, Olaf.

 

[Olaf Doschke]

These lines are interesting:

m.lcOnError=UPPER(ALLTRIM(ON("ERROR")))
IF NOT EMPTY(m.lcOnError)
	m.lcOnError=STRTRAN(STRTRAN(STRTRAN(lcOnError,"ERROR()","nError"), ;
			"PROGRAM()","cMethod"),"LINENO()","nLine")
	&lcOnError

They take the call to the current global error handler, and replace ERROR(), PROGRAM(), LINENO() with the parameters the Error()-Method retrieves, so your own error handling runs with the right values.
But the Error() method also simply suppresses errors and returns .f. if the class is set to ignore errors or _vfp.startmode is >0, that means the error is ignored, when you run as something else than within the IDE, eg when the code runs as EXE. So here you have a different behavior in EXE and debugging in the IDE!

As you see something else as next line, it seems your error handler at that moment is set to ON ERROR Store .T. To lTableError, somewhere before you call the report.
Before you execute line 8, in the debugger Watch Window type in ON("ERROR") and see what is the current error handler, this is something I already suggested doing, inspect this and variable, etc, etc.

Bye, Olaf.

 

[Bryan - Gendev]

Olaf,

This is a bit of a stretch for me... I don't know how to put a set step on before that line 8 - sorry.

I put one in the init of the reportlistener but it sailed past that one.

GenDev

 

[cchalom]

Hi Olaf,

Thanks for your suggestions.
As you know, FoxyPreviewer is completely based in the "ReportListener" class.

I work with some subclasses, based on the FFC classes created by Lisa.
But the ReportListener base class is a sort of a "BlackBox", and we can't know exactly what each method / event does, when we have a DODEFA() that reaches the 1st method of the base class, understand?

So, in summary, the Render() event of the report called DODEFAULT(), that went with other DODEFA() through all parent classes, till reached the Base class, that decided to Unload the report without advice, or eror message, understand ?

Today I received a PM from "GenDev" telling that the issue happened because the variable that he was using to set the path for the image was empty.

Regards

Cesar

 

[Olaf Doschke]

I understand, yes, such inherited issues are hardly easy to find and fix. And in the base class the only thing you could try is nodefault, but surely not with something like the Unload.
In the end such things as an empty variable for the image path should lead to operator/operand errors and not to c5 errors, but who knows what happens on the lowest level.

Glad you and he figured it out. Another caae for prechecking configuration and other outsets.

Bye, Olaf.