1. RE: EuGrid - was Runs w/Interpreter but not as .exe
Hi Jonas,
I haven't made any changes to tk_mem usage for 1.1 (all it uses is
acquire_mem/release_mem). I *am* using a number of new windows system
dll functions and there is more message handling code to do with combo
box columns.
I vaguely remember getting a similar sort of error during development
when I managed to inadvertantly generate a recursive windows message
call. As far as I knew I had fixed this but although I have tested
EuGrid on 95,98 & win 2k pro this was all done using exw.exe and not a
bound program.
A couple of questions:
- Does the app fail immediately, or after a specific action?
- What version of win32lib are you using?
Regards,
Phil
Jonas Temple wrote:
> 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
Phil,
In answer to your questions, the app fails immediately before any
windows are displayed. I'm using win32lib v57.9.
I also noticed you mentioned that you're doing more message handling of
combo boxes. The odd thing here is I've narrowed down the failure to a
createEx() call to create a dropdown list. I changed the control type
to combobox, simplecombo, etc. all with the same results.
Jonas
Phil Russell wrote:
> Hi Jonas,
>
> I haven't made any changes to tk_mem usage for 1.1 (all it uses is
> acquire_mem/release_mem). I *am* using a number of new windows system
> dll functions and there is more message handling code to do with combo
> box columns.
>
> I vaguely remember getting a similar sort of error during development
> when I managed to inadvertantly generate a recursive windows message
> call. As far as I knew I had fixed this but although I have tested
> EuGrid on 95,98 & win 2k pro this was all done using exw.exe and not a
> bound program.
>
> A couple of questions:
>
> - Does the app fail immediately, or after a specific action?
> - What version of win32lib are you using?
>
> Regards,
>
> Phil
>
3. RE: EuGrid - was Runs w/Interpreter but not as .exe
Phil,
I also should clarify that the failing createEx() happens BEFORE the
include of eugrid. This would probably sugget that it's not related to
EuGrid, but it sure seems strange that my program never bombs with the
previous version of eugrid, just the new one.
Weird...huh?
Jonas
Jonas Temple wrote:
> Phil,
>
> In answer to your questions, the app fails immediately before any
> windows are displayed. I'm using win32lib v57.9.
>
> I also noticed you mentioned that you're doing more message handling of
> combo boxes. The odd thing here is I've narrowed down the failure to a
> createEx() call to create a dropdown list. I changed the control type
> to combobox, simplecombo, etc. all with the same results.
>
> Jonas
>
4. RE: EuGrid - was Runs w/Interpreter but not as .exe
Jonas,
Yep - very weird. I have been working on windows for long enough now
that I barely feel the pain any more, but I can still remember the
disbelief I felt when I first moved from IBM AS400 to PC development
(3.1) and it fell over every 10 minutes...
I assume that this must be some kind of weird memory allocation problem
(perhaps due to the larger size of the new eugrid include...?). Have
you tried moving the code around a bit to get variables allocated in a
different order, or allocating zero to the dropdown list id before
calling CreateEx?
BTW I ended up coding the following in EuGrid in the scrollbar code:
elsif scrolltype = SB_PAGEUP then
-- No idea why, but removing this line gives a page fault on Win95
GridTopRow[grid] -= 0
--...so dont remove it!!!!!
GridTopRow[grid] -= GridDraw[grid][MAX_VISIBLE_ROWS]
>From which I conclude that Euphoria's memory management is not *quite*
perfect...
If you want me to take a look at the code then by all means send it to
me at pg_russellnospam at hotmail.com (removing 'nospam').
Cheers,
Phil
Jonas Temple wrote:
> Phil,
>
> I also should clarify that the failing createEx() happens BEFORE the
> include of eugrid. This would probably sugget that it's not related to
> EuGrid, but it sure seems strange that my program never bombs with the
> previous version of eugrid, just the new one.
>
> Weird...huh?
>
> Jonas
> Jonas Temple wrote:
> > Phil,
> >
> > In answer to your questions, the app fails immediately before any
> > windows are displayed. I'm using win32lib v57.9.
> >
> > I also noticed you mentioned that you're doing more message handling of
> > combo boxes. The odd thing here is I've narrowed down the failure to a
> > createEx() call to create a dropdown list. I changed the control type
> > to combobox, simplecombo, etc. all with the same results.
> >
> > Jonas
> >
>
5. RE: EuGrid - was Runs w/Interpreter but not as .exe
Phil,
Isn't it a small world! I STILL develop on the AS/400, but of course
you now know it's called iSeries.
This particular program is a part of a larger project project to join
Euphori with the iSeries through the Client Access APIs. I've got an
application explorer that runs .exes off the IFS. May not go anywhere
but it's been an educational experience!
I'll try moving things around and see what that does!
Jonas
Phil Russell wrote:
> Jonas,
>
> Yep - very weird. I have been working on windows for long enough now
> that I barely feel the pain any more, but I can still remember the
> disbelief I felt when I first moved from IBM AS400 to PC development
> (3.1) and it fell over every 10 minutes...
>
> I assume that this must be some kind of weird memory allocation problem
> (perhaps due to the larger size of the new eugrid include...?). Have
> you tried moving the code around a bit to get variables allocated in a
> different order, or allocating zero to the dropdown list id before
> calling CreateEx?
>
> BTW I ended up coding the following in EuGrid in the scrollbar code:
>
> elsif scrolltype = SB_PAGEUP then
> -- No idea why, but removing this line gives a page fault on Win95
> GridTopRow[grid] -= 0
> --...so dont remove it!!!!!
> GridTopRow[grid] -= GridDraw[grid][MAX_VISIBLE_ROWS]
>
> >From which I conclude that Euphoria's memory management is not *quite*
> perfect...
>
> If you want me to take a look at the code then by all means send it to
> me at pg_russellnospam at hotmail.com (removing 'nospam').
>
> Cheers,
>
> Phil
>
> Jonas Temple wrote:
> > Phil,
> >
> > I also should clarify that the failing createEx() happens BEFORE the
> > include of eugrid. This would probably sugget that it's not related to
> > EuGrid, but it sure seems strange that my program never bombs with the
> > previous version of eugrid, just the new one.
> >
> > Weird...huh?
> >
> > Jonas
> > Jonas Temple wrote:
> > > Phil,
> > >
> > > In answer to your questions, the app fails immediately before any
> > > windows are displayed. I'm using win32lib v57.9.
> > >
> > > I also noticed you mentioned that you're doing more message handling of
> > > combo boxes. The odd thing here is I've narrowed down the failure to a
> > > createEx() call to create a dropdown list. I changed the control type
> > > to combobox, simplecombo, etc. all with the same results.
> > >
> > > Jonas
> > >
> >
6. RE: EuGrid - was Runs w/Interpreter but not as .exe
Phil,
Boy, this is like finding a needle in a haystack! I tried the
non-glamorous approach by just putting puts() calls in various sections
of my code to try to track this down. The funny thing is I could put
the puts() in a certain section, rebind and then the program ran fine.
In another section the bug would appear and it almost seemed completely
ramdom!
I can't spend any more time on this so unfortunately I went back to the
older version of EuGrid and no matter what I do or how I arrange the
code, the program runs fine every time. I looked at EuGrid and the only
thing I noticed (which shouldn't have caused a problem) is the call to
DrawEdge (which you didn't even use) declares the first parm as a
pointer when it should be a handle. Other than that, I'm stumped! The
only way I can let you look at the program is if you have Client Access
Express from IBM installed otherwise I'm on my own.
Jonas
> Phil Russell wrote:
> > Jonas,
> >
> > Yep - very weird. I have been working on windows for long enough now
> > that I barely feel the pain any more, but I can still remember the
> > disbelief I felt when I first moved from IBM AS400 to PC development
> > (3.1) and it fell over every 10 minutes...
> >
> > I assume that this must be some kind of weird memory allocation problem
> > (perhaps due to the larger size of the new eugrid include...?). Have
> > you tried moving the code around a bit to get variables allocated in a
> > different order, or allocating zero to the dropdown list id before
> > calling CreateEx?
> >
> > BTW I ended up coding the following in EuGrid in the scrollbar code:
> >
> > elsif scrolltype = SB_PAGEUP then
> > -- No idea why, but removing this line gives a page fault on Win95
> > GridTopRow[grid] -= 0
> > --...so dont remove it!!!!!
> > GridTopRow[grid] -= GridDraw[grid][MAX_VISIBLE_ROWS]
> >
> > >From which I conclude that Euphoria's memory management is not *quite*
> > perfect...
> >
> > If you want me to take a look at the code then by all means send it to
> > me at pg_russellnospam at hotmail.com (removing 'nospam').
> >
> > Cheers,
> >
> > Phil
> >
> > Jonas Temple wrote:
> > > Phil,
> > >
> > > I also should clarify that the failing createEx() happens BEFORE the
> > > include of eugrid. This would probably sugget that it's not related to
> > > EuGrid, but it sure seems strange that my program never bombs with the
> > > previous version of eugrid, just the new one.
> > >
> > > Weird...huh?
> > >
> > > Jonas
> > > Jonas Temple wrote:
> > > > Phil,
> > > >
> > > > In answer to your questions, the app fails immediately before any
> > > > windows are displayed. I'm using win32lib v57.9.
> > > >
> > > > I also noticed you mentioned that you're doing more message handling of
> > > > combo boxes. The odd thing here is I've narrowed down the failure to a
> > > > createEx() call to create a dropdown list. I changed the control type
> > > > to combobox, simplecombo, etc. all with the same results.
> > > >
> > > > Jonas
> > > >
> > >
7. RE: EuGrid - was Runs w/Interpreter but not as .exe
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!
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.
I'll keep looking but I thought you might like to know...
Jonas
Phil Russell wrote:
> Jonas,
>
> Yep - very weird. I have been working on windows for long enough now
> that I barely feel the pain any more, but I can still remember the
> disbelief I felt when I first moved from IBM AS400 to PC development
> (3.1) and it fell over every 10 minutes...
>
> I assume that this must be some kind of weird memory allocation problem
> (perhaps due to the larger size of the new eugrid include...?). Have
> you tried moving the code around a bit to get variables allocated in a
> different order, or allocating zero to the dropdown list id before
> calling CreateEx?
>
> BTW I ended up coding the following in EuGrid in the scrollbar code:
>
> elsif scrolltype = SB_PAGEUP then
> -- No idea why, but removing this line gives a page fault on Win95
> GridTopRow[grid] -= 0
> --...so dont remove it!!!!!
> GridTopRow[grid] -= GridDraw[grid][MAX_VISIBLE_ROWS]
>
> >From which I conclude that Euphoria's memory management is not *quite*
> perfect...
>
> If you want me to take a look at the code then by all means send it to
> me at pg_russellnospam at hotmail.com (removing 'nospam').
>
> Cheers,
>
> Phil
>
> Jonas Temple wrote:
> > Phil,
> >
> > I also should clarify that the failing createEx() happens BEFORE the
> > include of eugrid. This would probably sugget that it's not related to
> > EuGrid, but it sure seems strange that my program never bombs with the
> > previous version of eugrid, just the new one.
> >
> > Weird...huh?
> >
> > Jonas
> > Jonas Temple wrote:
> > > Phil,
> > >
> > > In answer to your questions, the app fails immediately before any
> > > windows are displayed. I'm using win32lib v57.9.
> > >
> > > I also noticed you mentioned that you're doing more message handling of
> > > combo boxes. The odd thing here is I've narrowed down the failure to a
> > > createEx() call to create a dropdown list. I changed the control type
> > > to combobox, simplecombo, etc. all with the same results.
> > >
> > > Jonas
> > >
> >
8. RE: EuGrid - was Runs w/Interpreter but not as .exe
Derek,
Derek Parnell wrote:
> Jonas,
>
> 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.
Is lParam passed as a value in the onEvent handler? I'm not sure.
>
> How did you detect this anomoly, Jonas? Did using the safe-mode help you
> or
> not?
>
> Did you actually find anything wrong with my safe-mode tk_mem.e? If so,
> I'd
> like to fix it.
>
Actually there was nothing wrong your safe mode of tk_mem.e. I have
some other routines that were using Eu's allocate() and free() routines
so I also needed to use safe.e and since safe.e is not compatible with
tk_mem.e I just replaced the windows routines in tk_mem.e to
allocate/free memory with Euphoria's routines. The fetch() call in
EuGrid was just the first thing I ran into and all the time I had to
spend on it today (I also had to use register_block in several places to
omit checking of valid memory allocated in a .dll).
I'm telling you, this has me really frustrated. No matter how the
source is arranged it runs fine interpreted but as soon as it is bound
it starts bombing. I think using safe memory handling is the only way
to track this down. I'm not even convinced the problem is in EuGrid but
since I started having this problem when I began using the new version I
figured it was a good place to start.
What I hope to have after this is solved is a good handle on how to
track this down in the future, maybe even share how I went about finding
the problem (IF I find it, that is).
Jonas
9. RE: EuGrid - was Runs w/Interpreter but not as .exe
Phil/Derek,
> Is lParam passed as a value in the onEvent handler? I'm not sure.
For the WM_DRAWITEM message lParam is a pointer. His routine is right!
Jonas
10. RE: EuGrid - was Runs w/Interpreter but not as .exe
Hi Jonas,
Sorry I've not been in touch - been away from PC for a day or so.
Did your amendments to tk_mem/use of safe.e fix the problem?
Phil
Jonas Temple wrote:
> Phil/Derek,
>
> > Is lParam passed as a value in the onEvent handler? I'm not sure.
>
> For the WM_DRAWITEM message lParam is a pointer. His routine is right!
>
>
> Jonas
>
>
11. RE: EuGrid - was Runs w/Interpreter but not as .exe
Phil,
Unfortunately I cannot find the problem. Everything in your code looks
fine and I also went back and reviewed some of my own code. Still
nothing.
The funny thing is even when I use safe.e and a safe version of tk_mem
it binds and runs with no errors! As soon as I go back to the un-safe
versions it starts erroring.
At this point I went back to the prior version of EuGrid and everything
works fine. I'm stumped.
BTW, why did you leave the AS400 world?
Jonas
Phil Russell wrote:
> Hi Jonas,
>
> Sorry I've not been in touch - been away from PC for a day or so.
>
> Did your amendments to tk_mem/use of safe.e fix the problem?
>
> Phil
>
>
> Jonas Temple wrote:
> > Phil/Derek,
> >
> > > Is lParam passed as a value in the onEvent handler? I'm not sure.
> >
> > For the WM_DRAWITEM message lParam is a pointer. His routine is right!
> >
> >
> > Jonas
> >
> >
12. RE: EuGrid - was Runs w/Interpreter but not as .exe
Jonas,
It *really* sounds like a memory allocation problem then. Perhaps Rob
could take a look?
I am also going to try and replicate the problem myself (using
interpreted/bound programs and both versions of EuGrid). This might
take a few days as I only have the complete Eu edition at Home (on
win95) so I will have to transfer the code to my win2k machine at work.
I will let you know if I find anything...
<scrape barrel>
I noticed that Rob posted this yesterday:
By the way, if you see a line at the end of Win32Lib.ew
that is just two dashes: -- (and no new-line character),
you will need to remove it before binding with 2.3. This problem
has been fixed in the upcoming 2.4 binder.
He didn't say what problem it caused but worth a look perhaps...
</scrape barrel>
In reply to your question, I spent several years working on System/36
and AS400 boxes programming in RPGII and RPG/400. Getting fed up with
too much S/36 emulation work I moved to a job which had both AS400 and
Oracle-based systems. I had done a bit of Windows C programming as a
hobby and as a result (being the only person there with any windows
programming experience) ended up being asked to develop a client-server
system using SQLWindows and Oracle. Never really looked back after
that. I don't know what the iSeries is like now but when I stopped
using AS400s in 1996 the database support was still rather clunky - it
was just *much* easier to write database code in Oracle than in RPG /
Query/400 / DB/400 SQL. I can't remember much about the AS400 now so I
guess I'm stuck with Oracle...
Phil
Jonas Temple wrote:
> Phil,
>
> Unfortunately I cannot find the problem. Everything in your code looks
> fine and I also went back and reviewed some of my own code. Still
> nothing.
>
> The funny thing is even when I use safe.e and a safe version of tk_mem
> it binds and runs with no errors! As soon as I go back to the un-safe
> versions it starts erroring.
>
> At this point I went back to the prior version of EuGrid and everything
> works fine. I'm stumped.
>
> BTW, why did you leave the AS400 world?
>
> Jonas
> Phil Russell wrote:
> > Hi Jonas,
> >
> > Sorry I've not been in touch - been away from PC for a day or so.
> >
> > Did your amendments to tk_mem/use of safe.e fix the problem?
> >
> > Phil
> >
> >
> > Jonas Temple wrote:
> > > Phil/Derek,
> > >
> > > > Is lParam passed as a value in the onEvent handler? I'm not sure.
> > >
> > > For the WM_DRAWITEM message lParam is a pointer. His routine is right!
> > >
> > >
> > > Jonas
> > >
> > >
13. RE: EuGrid - was Runs w/Interpreter but not as .exe
Jonas,
Have you noticed Patrick Barnes' post (about meditor)? He is getting the
following problem:
<snip>
If there is an instance of the editor open already, and you open another
for editting... (c:\euphoria\bin\medit\editor.exe "<filename>" ) <-- How
I have my file associations set
then it opens a dialog window with:
"The instruction at 0041530d referenced memory at 00000000. The memory
could not be written"
This is on win2k, with the compiled version of the editor
</snip>
Sound familiar?
Phil
14. RE: EuGrid - was Runs w/Interpreter but not as .exe
Phil (and others),
I've done some more testing and here's where I stand:
So far only 1 of my bound programs are having this problem. The problem
is also not related to OS level as I can reproduce the problem on
Win95/Win98/Win2K. The exact error message I'm getting is:
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?
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.
The other consideration is the include file the problem is happening in.
Both the main .exw file and the .ew include file have a main window (0
parent). The window in the .ew file may or may not be displayed,
depending on the command line parameters passed. I wasn't sure if
having two windows as the main window would be a problem.
Jonas
The fix still is to use V1.0 of EuGrid.
Phil Russell wrote:
> Jonas,
>
> It *really* sounds like a memory allocation problem then. Perhaps Rob
> could take a look?
>
> I am also going to try and replicate the problem myself (using
> interpreted/bound programs and both versions of EuGrid). This might
> take a few days as I only have the complete Eu edition at Home (on
> win95) so I will have to transfer the code to my win2k machine at work.
>
> I will let you know if I find anything...
>
> <scrape barrel>
> I noticed that Rob posted this yesterday:
>
> By the way, if you see a line at the end of Win32Lib.ew
> that is just two dashes: -- (and no new-line character),
> you will need to remove it before binding with 2.3. This problem
> has been fixed in the upcoming 2.4 binder.
>
> He didn't say what problem it caused but worth a look perhaps...
> </scrape barrel>
>
> In reply to your question, I spent several years working on System/36
> and AS400 boxes programming in RPGII and RPG/400. Getting fed up with
> too much S/36 emulation work I moved to a job which had both AS400 and
> Oracle-based systems. I had done a bit of Windows C programming as a
> hobby and as a result (being the only person there with any windows
> programming experience) ended up being asked to develop a client-server
> system using SQLWindows and Oracle. Never really looked back after
> that. I don't know what the iSeries is like now but when I stopped
> using AS400s in 1996 the database support was still rather clunky - it
> was just *much* easier to write database code in Oracle than in RPG /
> Query/400 / DB/400 SQL. I can't remember much about the AS400 now so I
> guess I'm stuck with Oracle...
>
> Phil
>
>
> Jonas Temple wrote:
> > Phil,
> >
> > Unfortunately I cannot find the problem. Everything in your code looks
> > fine and I also went back and reviewed some of my own code. Still
> > nothing.
> >
> > The funny thing is even when I use safe.e and a safe version of tk_mem
> > it binds and runs with no errors! As soon as I go back to the un-safe
> > versions it starts erroring.
> >
> > At this point I went back to the prior version of EuGrid and everything
> > works fine. I'm stumped.
> >
> > BTW, why did you leave the AS400 world?
> >
> > Jonas
> > Phil Russell wrote:
> > > Hi Jonas,
> > >
> > > Sorry I've not been in touch - been away from PC for a day or so.
> > >
> > > Did your amendments to tk_mem/use of safe.e fix the problem?
> > >
> > > Phil
> > >
> > >
> > > Jonas Temple wrote:
> > > > Phil/Derek,
> > > >
> > > > > Is lParam passed as a value in the onEvent handler? I'm not sure.
> > > >
> > > > For the WM_DRAWITEM message lParam is a pointer. His routine is right!
> > > >
> > > >
> > > >
> > > > Jonas
> > > >
> > > >
15. RE: EuGrid - was Runs w/Interpreter but not as .exe
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
>
>
16. RE: EuGrid - was Runs w/Interpreter but not as .exe
Robert Craig wrote:
> 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.
No, the program does not crash in interpreted mode or using shroud
-clear. It only crashes when bound. It runs fine in interpreted or
shrouded form.
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 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.
>
I agree but there has to be a better way to track this down than the
"shooting in the dark and hope I find it" method. Again, if I had the
option as the programmer to trace a bound program then I could have
solved this two weeks ago.
Jonas
> Regards,
> Rob Craig
> Rapid Deployment Software
> http://www.RapidEuphoria.com
>
>
17. RE: EuGrid - was Runs w/Interpreter but not as .exe
Robert Craig wrote:
> 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.
>
Sorry, it's not in my nature as a programmer to relax. I work on a
problem until it's resolved. What better opportunity will I have? Will
it come in the form of V2.4? If you open the tracing feature to bound
programs and want someone to test, I'll be glad to.
The particular program I'm having the problem with is meant to be bound.
I need a stand-alone executable that the end user can run without
having the interpreter installed (it's a part of new features in my
iSeries Toolbox for Euphoria).
I'll wait if I have to, but it's gonna be hard!
Jonas
18. RE: EuGrid - was Runs w/Interpreter but not as .exe
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]
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
***********************************************************************
***********************************************************************
19. RE: EuGrid - was Runs w/Interpreter but not as .exe
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,
Thanks for the suggestion, I'll give it a try.
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...
Derek, I would also like to get the traceable version of win32lib as
well. Anything to help.
Now if I can just have some Tylenol and antacid delivered.....
Jonas
