1. error messages on a shrouded file
- Posted by George Walters <gwalters at sc.rr.com>
May 18, 2005
-
Last edited May 19, 2005
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.
2. Re: error messages on a shrouded file
- Posted by Mario Steele <eumario at trilake.net>
May 18, 2005
-
Last edited May 19, 2005
George Walters 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.
>
You are proabbly using an older version of Euphoria. Pre 2.5, shrouded all the
variable names, for security reasons. 2.5 no longer does that. However, in
thoes days of when shrouding effected everything in ex.err, there we're
utilities
made to write out variable data, but only in key sistuations, where you know it
would be crashing. One sure fire way to bypass this, is to implement a variable
stack.
EG:
sequence varVal, varName
varName = {}
varVal = {}
procedure defineVar(sequence name)
varName &={ name }
varVal &= 0
end procedure
procedure setVar(sequence name, object val)
integer i
i = find(name,varName)
if i then
varVal[i] = val
end if
end procedure
function getVar(sequence name)
integer i
i = find(name,varName)
if i then
return varVal[i]
end if
end function
This would leave the data intact, where you can easily see what variables
are being used. However, there are several downsides to this. Memory
consumption will increase, this will only work in the code you write, and
not in 3rd party libs. Unless you wish to re-write thoes 3rd party libs,
but thoes become bothersum. There's also other libraries in the archives,
that allow you to do debug information. Just search the archives for debug,
it should help you out.
Mario Steele
http://enchantedblade.trilake.net
Attaining World Dominiation, one byte at a time...
3. 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
4. Re: error messages on a shrouded file
Pete Lomax wrote:
>
> 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.
In 2.5, if you bind or shroud a program using the "-full_debug" option,
you'll get a full ex.err, the same as if you had run the program
with the interpreter. The file names and line numbers in the ex.err
will all be correct. So this problem no longer exists (unless you
are still clinging to 2.4 or earlier). Note that the source code
is not included, just the intermediate IL code, plus some line
number information.
Without "-full_debug" you'll get a much smaller, less informative ex.err,
but your bound or shrouded program will be somewhat smaller.
Some people prefer this because they have "secret" information
that they don't want exposed in ex.err if their program dies.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
