Re: error messages on a shrouded file
On Wed, 18 May 2005 14:06:55 -0700, George Walters
<guest at RapidEuphoria.com> wrote:
>I was trying out a bound file (e.g. "program.exe") which got an error when it
>was
>executed. The resulting error file (ex.err) didn't seem too useful. All the
>vars were
>encoded, etc. Is there a way to make sense of this when it happens in an
>installed situation? I was thinking of emailing to myself the ex.err file when
>this happens, but only if I can make something of it.
short answer: use bind -clear
long answer:
Disclaimer: I still use 2.4, so this may have changed since, but it is
likely some of the principles remain. I think Rob said he wants to
improve this, but I can't remember what he said. Anyway:
If you bind a collection of files, I've found the line numbers to be
useless, however if you first shroud -clear, then you have a clue.
It may be off by a few lines (maybe that's me, examining a 1.5 shroud
for a 1.4 bug?), but you definately get into the rough area. Be warned
these files (with win32lib etc) will be ~60,000 lines.
So, my recommendation is to shroud -clear -list first (and save the
resulting file and any deleted.txt, which can contain some help vis
renamed vars), _then_ bind that file.
There is another trick I used: if the routine is global in the
top-level file, it is not renamed. There is possibly another trick
regarding global routines and using routine_id (somewhere; anywhere)
with an expression -- which I hope you understand as I would struggle
to explain fully; it also leaves them un-named (sometimes).
There is a fairly obvious mapping of the allocated variable names and
parameters/local vars, for example if you have:
procedure myProc(integer id, integer msg, atom wParam, object lParam)
integer d,e
and you (somehow) know that myProc is the routine the problem occurs
in, then in the ex.err file, the renamed vars zJ, zK, zL, zM, zN map
fairly obviously to id,msg,wParam,lParam,d,e. The trick, of course, is
leaving myProc un-renamed, or somehow other determining the exact
routine you are in.
Rob, if you are reading, is there any chance of adding:
demo_treeviews.exw:130 in function treeHandler() [line 125]
attempt to divide by 0
... called from arwen.ew:5681 in function WndProc() [line 5345]
As I think that would be helpful for bound/shrounded programs.
Lastly, and most obviously, you should deliberately plant a few ?9/0
in your code, package, and test to see if you can logically track down
that line from the info you get in the ex.err file.
Presonally, I've resorted to bind -clear, as at least for now that is
probably quite sufficient. One thing that surprised me when I did that
is the zipped executables are /much/ smaller.
Let me know how you get on.
Regards,
Pete
|
Not Categorized, Please Help
|
|
