1. EuGrid - was Runs w/Interpreter but not as .exe
Derek,
Please!!!! Tracking this bug down reminds me of my quality time spent
with C++! This is why I got away from it! Aaaarrgghh. You can send it
to me at jktemple at yhti.net.
The one thing I know now is that the program started doing this today.
The only major thing I changed was I realized I didn't have the latest
verion of EuGrid and when I created the bound program with the new
version that's when my trouble started.
Phil, did anything change in eugrid in relation to memory management?
Maybe the "safety" version of tk_mem will help.
Thanks everyone for the help!
Jonas
Derek Parnell wrote:
> Jonas,
> would like the version of tk_mem.e that does "safety" checks?
>
>
2. Re: EuGrid - was Runs w/Interpreter but not as .exe
Jonas,
On Tue, 26 Nov 2002 23:30:02 +0000, Jonas Temple <jktemple at yhti.net> wrote:
>
> Phil,
>
> I've been running my program using safe mode memory handling and one thing
> that came up is in the EGW_OnParentEvent routine around line 3350 there's
> a call to the fetch() routine in tk_mem.e that passes the lParam parm and
> the diHwndItem. I was under the impression that the lParam was not a
> pointer but a value. In the fetch() routine a peek4s() is being done at
> s[1] + struct + s[5]. If the lParam is a value then wouldn't this be a
> problem? If it's a pointer then I need to go back to the win32lib docs!
If lParam is a value and not a pointer, and Phil is using it as the FIRST
parameter to fetch() then there could be problems.
How did you detect this anomoly, Jonas? Did using the safe-mode help you or
not?
> I didn't get any further than that. What I did was I created a version of
> tk_mem.e that uses the Eu allocate() and free() instead of the windows
> memory routines. I then used safe.e in place of machine.e.
Did you actually find anything wrong with my safe-mode tk_mem.e? If so, I'd
like to fix it.
--
cheers,
Derek Parnell
3. Re: EuGrid - was Runs w/Interpreter but not as .exe
Jonas Temple writes:
> The instruction at 802584ad referenced memory at 802584ad
> The memory could not be read from
>
> What's interesting here is that the instruction and memory location are
> the same. Is this normal for Windows programs?
It's unusual, but I find those addresses are rarely helpful
for tracking things down.
> I've narrowed down the line causing the problem (by using puts)
> to a createEx call of a drop down list. However I feel that by
> moving code around it would probably happen in a different spot.
Remember to call flush() after each each call to puts()
or you may get a misleading result, because the last few
lines from puts() might not make it into your debug file
(or the screen).
You can also use Euphoria's trace(3):
with trace
trace(3)
It creates a "ctrace.out" file containing the last
500 lines leading up to the machine-level crash.
The line just before "=THE END=" is the one that
was being executed when the crash occurred.
Be aware that trace(3) will slow your program down,
maybe by a factor of 100.
If you do figure out the line where it is dying,
you could insert a trace(1) or a ? 1/0 to dump
out the variable values being used just prior to that line.
Before using Euphoria's trace with Win32Lib,
you might want to strip out the trace-related
statements that are in Win32Lib.ew and related files.
For instance:
without trace
appears in a few places.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
4. Re: EuGrid - was Runs w/Interpreter but not as .exe
- Posted by r.schr at t-online.de
Nov 30, 2002
Hi Jonas,
I know one case where you will not succeed with trace, i.e., if you open
a file in a subroutine and without closing. If you call this routine in
a loop often enough, every time a new file handle will be 'consumed',
and then your program will end without any error message, even with
trace!
Have a nice day, Rolf
Jonas Temple wrote:
>
>
> Rob,
>
> I followed your instructions, made sure every include had "with trace"
> and used trace(3) at the top of my main program file. I then bound the
> program and ran. I got the Windows crash message again but no
> ctrace.out. Is ctrace.out produced in bound mode?
>
> Jonas
> Robert Craig wrote:
> > You can also use Euphoria's trace(3):
> > with trace
> > trace(3)
> >
> > It creates a "ctrace.out" file containing the last
> > 500 lines leading up to the machine-level crash.
> > The line just before "=THE END=" is the one that
> > was being executed when the crash occurred.
> >
> > Be aware that trace(3) will slow your program down,
> > maybe by a factor of 100.
> >
> > If you do figure out the line where it is dying,
> > you could insert a trace(1) or a ? 1/0 to dump
> > out the variable values being used just prior to that line.
> >
> > Before using Euphoria's trace with Win32Lib,
> > you might want to strip out the trace-related
> > statements that are in Win32Lib.ew and related files.
> > For instance:
> > without trace
> > appears in a few places.
> >
> > Regards,
> > Rob Craig
> > Rapid Deployment Software
> > http://www.RapidEuphoria.com
> >
> >
>
>
5. Re: EuGrid - was Runs w/Interpreter but not as .exe
Jonas Temple writes:
> I followed your instructions, made sure every include had "with trace"
> and used trace(3) at the top of my main program file. I then bound the
> program and ran. I got the Windows crash message again but no
> ctrace.out. Is ctrace.out produced in bound mode?
For added security, there is no trace in bound mode.
You should run your program normally (unbound), or maybe
with shroud -clear. Hopefully it will crash, and ctrace.out will
show you where.
I still think this "bound vs. unbound" issue is a red herring.
It's just that your program is altered when bound,
so the memory addresses and contents are shuffled around.
By the way, you really just need a single "with trace" at the top
of your main file, but the included files should not contain
"without trace", because that will turn off tracing for those files,
and you won't see the crash point clearly if it happens inside one of them.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
6. Re: EuGrid - was Runs w/Interpreter but not as .exe
Jonas Temple writes:
> In this case I'm really dead in the water, aren't I? I have no way of
> knowing where or why my program is crashing. I even tried puts() and
> flush() as you suggested. When running the bound version with puts() it
> ran fine! I'm starting to think that if I, as a programmer, want to
> allow tracing of my bound program then that's my problem (unless the
> security issue has to do with the internals of the interpreter). Why
> can't this be an option when creating a bound program?
I'll reconsider the security issue for 2.4.
Meanwhile, if adding puts() made it work,
then maybe adding a few more calls to puts()
will make it crash again. Or switching the order of some
includes, or just about anything.
This is frustrating, but for C/C++ programmers
this is very common. They recompile their program
in debug mode and the crash goes away.
Or maybe just relax, run it unbound for a while,
and wait for a better opportunity to debug it.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
7. Re: EuGrid - was Runs w/Interpreter but not as .exe
I rarely come out of lurk mode and have been waiting for someone else to
suggest this and can't believe that no-one, even Rob, has. Rename
machine.e
to something else; rename safe.e to machine.e and run your program
unbound.
I have always tracked down errors of this nature this way. Not guaranteed
but worth a try.
chris.
----- Original Message -----
From: "Robert Craig" <rds at RapidEuphoria.com>
To: "EUforum" <EUforum at topica.com>
Sent: 01 December 2002 05:47
Subject: Re: EuGrid - was Runs w/Interpreter but not as .exe
>
> Jonas Temple writes:
> > In this case I'm really dead in the water, aren't I? I have no way of
> > knowing where or why my program is crashing. I even tried puts() and
> > flush() as you suggested. When running the bound version with puts()
it
> > ran fine! I'm starting to think that if I, as a programmer, want to
> > allow tracing of my bound program then that's my problem (unless the
> > security issue has to do with the internals of the interpreter). Why
> > can't this be an option when creating a bound program?
>
> I'll reconsider the security issue for 2.4.
> Meanwhile, if adding puts() made it work,
> then maybe adding a few more calls to puts()
> will make it crash again. Or switching the order of some
> includes, or just about anything.
>
> This is frustrating, but for C/C++ programmers
> this is very common. They recompile their program
> in debug mode and the crash goes away.
>
> Or maybe just relax, run it unbound for a while,
> and wait for a better opportunity to debug it.
>
> Regards,
> Rob Craig
> Rapid Deployment Software
> http://www.RapidEuphoria.com
>
>
>
>
8. Re: EuGrid - was Runs w/Interpreter but not as .exe
On Sun, Dec 01, 2002 at 11:29:35PM -0000, tubby.toast at ntlworld.com wrote:
>
> I rarely come out of lurk mode and have been waiting for someone else to
> suggest this and can't believe that no-one, even Rob, has. Rename
> machine.e
> to something else; rename safe.e to machine.e and run your program
> unbound.
> I have always tracked down errors of this nature this way. Not guaranteed
> but worth a try.
>
> chris.
>
He already tried a similar trick, and it worked bound and unbounded i think.
In fact, using puts() in the right spots got it to work.
A quick hack ... keep the puts() in the same spots, but change them to output
an empty string. Its a kludge, but it might work. Of course, it would be nice
to know why it worked tho. Personally, I think that odds are good if trace()
were available in bound mode, the program would automagically work anyways. :(
jbrown
> ----- Original Message -----
> From: "Robert Craig" <rds at RapidEuphoria.com>
> To: "EUforum" <EUforum at topica.com>
> Sent: 01 December 2002 05:47
> Subject: Re: EuGrid - was Runs w/Interpreter but not as .exe
>
>
> > Jonas Temple writes:
> > > In this case I'm really dead in the water, aren't I? I have no way of
> > > knowing where or why my program is crashing. I even tried puts() and
> > > flush() as you suggested. When running the bound version with puts()
> it
> > > ran fine! I'm starting to think that if I, as a programmer, want to
> > > allow tracing of my bound program then that's my problem (unless the
> > > security issue has to do with the internals of the interpreter). Why
> > > can't this be an option when creating a bound program?
> >
> > I'll reconsider the security issue for 2.4.
> > Meanwhile, if adding puts() made it work,
> > then maybe adding a few more calls to puts()
> > will make it crash again. Or switching the order of some
> > includes, or just about anything.
> >
> > This is frustrating, but for C/C++ programmers
> > this is very common. They recompile their program
> > in debug mode and the crash goes away.
> >
> > Or maybe just relax, run it unbound for a while,
> > and wait for a better opportunity to debug it.
> >
> > Regards,
> > Rob Craig
> > Rapid Deployment Software
> > http://www.RapidEuphoria.com
> >
> >
>
>
>
9. Re: EuGrid - was Runs w/Interpreter but not as .exe
I could put in a type of trace mechanism into Win32lib that would work in
bound and unbound programs.
Would this be a useful thing to anybody?
On Sun, 1 Dec 2002 21:02:22 -0500, <jbrown1050 at hotpop.com> wrote:
>
> On Sun, Dec 01, 2002 at 11:29:35PM -0000, tubby.toast at ntlworld.com wrote:
>>
>> I rarely come out of lurk mode and have been waiting for someone else to
>> suggest this and can't believe that no-one, even Rob, has. Rename
>> machine.e
>> to something else; rename safe.e to machine.e and run your program
>> unbound.
>> I have always tracked down errors of this nature this way. Not
>> guaranteed
>> but worth a try.
>>
>> chris.
>>
>
> He already tried a similar trick, and it worked bound and unbounded i
> think.
>
> In fact, using puts() in the right spots got it to work.
>
> A quick hack ... keep the puts() in the same spots, but change them to
> output
> an empty string. Its a kludge, but it might work. Of course, it would be
> nice
> to know why it worked tho. Personally, I think that odds are good if
> trace()
> were available in bound mode, the program would automagically work
> anyways. :(
>
> jbrown
>
>> ----- Original Message -----
>> From: "Robert Craig" <rds at RapidEuphoria.com>
>> To: "EUforum" <EUforum at topica.com>
>> Sent: 01 December 2002 05:47
>> Subject: Re: EuGrid - was Runs w/Interpreter but not as .exe
>>
>>
>> > Jonas Temple writes:
>> > > In this case I'm really dead in the water, aren't I? I have no way
>> of
>> > > knowing where or why my program is crashing. I even tried puts()
>> and
>> > > flush() as you suggested. When running the bound version with
>> puts()
>> it
>> > > ran fine! I'm starting to think that if I, as a programmer, want to
>> > > allow tracing of my bound program then that's my problem (unless the
>> > > security issue has to do with the internals of the interpreter).
>> Why
>> > > can't this be an option when creating a bound program?
>> >
>> > I'll reconsider the security issue for 2.4.
>> > Meanwhile, if adding puts() made it work,
>> > then maybe adding a few more calls to puts()
>> > will make it crash again. Or switching the order of some
>> > includes, or just about anything.
>> >
>> > This is frustrating, but for C/C++ programmers
>> > this is very common. They recompile their program
>> > in debug mode and the crash goes away.
>> >
>> > Or maybe just relax, run it unbound for a while,
>> > and wait for a better opportunity to debug it.
>> >
>> > Regards,
>> > Rob Craig
>> > Rapid Deployment Software
>> > http://www.RapidEuphoria.com
>> >
>> >
>
>
>
--
cheers,
Derek Parnell
10. Re: EuGrid - was Runs w/Interpreter but not as .exe
I'm thinking that it would be provided in an alternate library file, eg.
win32lib.tew. That way one would be normally using the standard library but
if you need to, you could rename stuff to use the trace-enabled library,
with its overheads.
On Mon, 2 Dec 2002 13:08:44 +1100, <Patrick.Barnes at transgrid.com.au> wrote:
>
> I think it would be useful to everybody.
>
> As long as it did not place too high an overhead on anybody not using the
> function.
>
> -----Original Message-----
> From: Derek Parnell [mailto:ddparnell at bigpond.com]
> Sent: Monday, 2 December 2002 13:04
> To: EUforum
> Subject: Re: EuGrid - was Runs w/Interpreter but not as .exe
>
>
> I could put in a type of trace mechanism into Win32lib that would work in
> bound
> and unbound programs.
>
> Would this be a useful thing to anybody?
>
>
> On Sun, 1 Dec 2002 21:02:22 -0500, <jbrown1050 at hotpop.com> wrote:
>
>>
>> On Sun, Dec 01, 2002 at 11:29:35PM -0000, tubby.toast at ntlworld.com
>> wrote:
>>>
>>> I rarely come out of lurk mode and have been waiting for someone else
>>> to
>>> suggest this and can't believe that no-one, even Rob, has. Rename
>>> machine.e
>>> to something else; rename safe.e to machine.e and run your program
>>> unbound.
>>> I have always tracked down errors of this nature this way. Not guaranteed
>>> but worth a try.
>>>
>>> chris.
>>>
>>
>> He already tried a similar trick, and it worked bound and unbounded i think.
>>
>> In fact, using puts() in the right spots got it to work.
>>
>> A quick hack ... keep the puts() in the same spots, but change them to output
>>
>> an empty string. Its a kludge, but it might work. Of course, it would be
>> nice to know why it worked tho. Personally, I think that odds are good
>> if trace() were available in bound mode, the program would automagically
>> work anyways. :(
>>
>> jbrown
>>
>>> ----- Original Message -----
>>> From: "Robert Craig" <rds at RapidEuphoria.com>
>>> To: "EUforum" <EUforum at topica.com>
>>> Sent: 01 December 2002 05:47
>>> Subject: Re: EuGrid - was Runs w/Interpreter but not as .exe
>>>
>>>
>>> > Jonas Temple writes:
>>> > > In this case I'm really dead in the water, aren't I? I have no way of
>>> > > knowing where or why my program is crashing. I even tried puts()
>>> and
>>> > > flush() as you suggested. When running the bound version with puts()
>>> it > > ran fine! I'm starting to think that if I, as a programmer,
>>> want to
>>> > > allow tracing of my bound program then that's my problem (unless
>>> the
>>> > > security issue has to do with the internals of the interpreter). Why
>>> > > can't this be an option when creating a bound program?
>>> >
>>> > I'll reconsider the security issue for 2.4.
>>> > Meanwhile, if adding puts() made it work,
>>> > then maybe adding a few more calls to puts()
>>> > will make it crash again. Or switching the order of some
>>> > includes, or just about anything.
>>> >
>>> > This is frustrating, but for C/C++ programmers
>>> > this is very common. They recompile their program
>>> > in debug mode and the crash goes away.
>>> >
>>> > Or maybe just relax, run it unbound for a while,
>>> > and wait for a better opportunity to debug it.
>>> >
>>> > Regards,
>>> > Rob Craig
>>> > Rapid Deployment Software
>>> > http://www.RapidEuphoria.com
>>> >
>>> >
--
cheers,
Derek Parnell
11. Re: EuGrid - was Runs w/Interpreter but not as .exe
> > > I rarely come out of lurk mode and have been waiting for someone else
to
> > > suggest this and can't believe that no-one, even Rob, has. Rename
> > > machine.e
> > > to something else; rename safe.e to machine.e and run your program
> > > unbound.
> > > I have always tracked down errors of this nature this way. Not
> > > guaranteed
> > > but worth a try.
> > >
> > > chris.
> > >
> And yes, I did try using safe.e in place of machine.e. Of course the
> problem you run into when using win32lib is that tk_mem uses the Windows
> memory management routines so when a routine in tk_mem does a peek or
> poke against that memory safe.e shows an error, which is not true. My
> solution was to create a version of tk_mem that uses Euphoria's allocate
> and free routines instead (I also had to use register_block in other
> places in my code as well). Of course the bound program ran fine
> then...
Ooops, obviously not paying as much attention as I thought. Always works
for me as I never upgraded beyond version 0.45r of win32lib. Back to lurk
mode then...
chris.
