1. EU 3.0.1 -- there's probably a bug in there somewhere
- Posted by Andy Serpa <ac at onehorseshy.com>
Jan 31, 2007
-
Last edited Feb 01, 2007
Some of my code that runs fine on Eu 2.5 crashes with a machine exception with
Eu 3.0.1. I've verified that I'm not doing anything I shouldn't in terms of
allocating/poking/freeing, etc, so I don't believe I'm corrupting any memory. It
always occurs when executing the return statement of a function, so I imagine
there is a reference-counting problem somewhere or some such thing that is over
my head.
The programs this occurs with are way too complex to try to demonstrate the
problem, and so I don't have a repeatable simple example I can show (although
these errors are repeatable and consistent), but they do involve manipulating
large sequences and complicated operations.
I did try running the code through the Euphoria-coded interpreter (exw.exe ->
eu.exw -> myprogram.exw) and it did not crash. Also translated versions of the
same code run fine as well.
So anyone who knows what they are looking at might want to examine whatever the
interpreter does when exiting a function that is different from v2.5 and see if
they can find anything. This is 2.5 compatible code -- no tasking stuff in there
at all. If I'm able to come up with a simple example I'll post it...
2. Re: EU 3.0.1 -- there's probably a bug in there somewhere
Andy Serpa wrote:
> Some of my code that runs fine on Eu 2.5 crashes with a machine exception with
> Eu 3.0.1. I've verified that I'm not doing anything I shouldn't in terms of
> allocating/poking/freeing, etc, so I don't believe I'm corrupting any memory.
> It always occurs when executing the return statement of a function, so I
> imagine
> there is a reference-counting problem somewhere or some such thing that is
> over
> my head.
>
> The programs this occurs with are way too complex to try to demonstrate the
> problem, and so I don't have a repeatable simple example I can show (although
> these errors are repeatable and consistent), but they do involve manipulating
> large sequences and complicated operations.
>
> I did try running the code through the Euphoria-coded interpreter (exw.exe ->
> eu.exw -> myprogram.exw) and it did not crash. Also translated versions of
> the same code run fine as well.
>
> So anyone who knows what they are looking at might want to examine whatever
> the interpreter does when exiting a function that is different from v2.5 and
> see if they can find anything. This is 2.5 compatible code -- no tasking
> stuff
> in there at all. If I'm able to come up with a simple example I'll post it...
Yes, I'd like to see it, if you can set up a simple example.
So far no one has reported any similar crashes to yours.
If you or anyone else is serious about tracking this down right away,
you might build a debug version of the exw.exe interpreter,
or at least one with some added print statements,
and try to find where exactly in the interpreter it is crashing.
At a return, there is often some storage recycling which could
crash if something on the heap has been corrupted (either by the
user program or the interpreter).
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
3. Re: EU 3.0.1 -- there's probably a bug in there somewhere
Robert Craig wrote:
>
>
> Yes, I'd like to see it, if you can set up a simple example.
>
> So far no one has reported any similar crashes to yours.
> If you or anyone else is serious about tracking this down right away,
> you might build a debug version of the exw.exe interpreter,
> or at least one with some added print statements,
> and try to find where exactly in the interpreter it is crashing.
> At a return, there is often some storage recycling which could
> crash if something on the heap has been corrupted (either by the
> user program or the interpreter).
>
I've been running 3.0.1 for a just a couple weeks -- had no problems with
anything but these most complex programs using lots of memory. (Had a similar
crash on something else a couple days ago, but didn't bother to track it down.)
So a "simple example" may be an impossibility. If I change the order of
statements in the crashing function or just add do-nothing statements (but so
that the logic remains the same), it will still crash, but maybe on a different
call to the function at a different time.
Also, it may be helpful to know that in the ex.err file it produces, all of the
variable values for the function in question are listed as <no value>, so
apparently it is happening as or just after it has dereferenced those. I assume
something is not getting cleaned up properly. Have you changed anything along
these lines from v2.5 to 3.0?
I'll see if I can produce a debug version, but it may be beyond me...
4. Re: EU 3.0.1 -- there's probably a bug in there somewhere
- Posted by Robert Craig <rds at RapidEuphoria.com>
Feb 01, 2007
-
Last edited Feb 02, 2007
Andy Serpa wrote:
> I've been running 3.0.1 for a just a couple weeks -- had no problems with
> anything
> but these most complex programs using lots of memory. (Had a similar crash
> on something else a couple days ago, but didn't bother to track it down.) So
> a "simple example" may be an impossibility. If I change the order of
> statements
> in the crashing function or just add do-nothing statements (but so that the
> logic remains the same), it will still crash, but maybe on a different call
> to the function at a different time.
>
> Also, it may be helpful to know that in the ex.err file it produces, all of
> the
> variable values for the function in question are listed as <no value>,
> so apparently it is happening as or just after it has dereferenced those. I
> assume something is not getting cleaned up properly. Have you changed
> anything
> along these lines from v2.5 to 3.0?
Yes, there were changes in subroutine call/return to support multitasking.
These changes can affect programs even if they don't use multitasking.
If you are doing recursion, that might be of particular interest in
solving this.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
5. Re: EU 3.0.1 -- there's probably a bug in there somewhere
Robert Craig wrote:
>
> Andy Serpa wrote:
> > I've been running 3.0.1 for a just a couple weeks -- had no problems with
> > anything
> > but these most complex programs using lots of memory. (Had a similar crash
> > on something else a couple days ago, but didn't bother to track it down.)
> > So
> > a "simple example" may be an impossibility. If I change the order of
> > statements
> > in the crashing function or just add do-nothing statements (but so that the
> > logic remains the same), it will still crash, but maybe on a different call
> > to the function at a different time.
> >
> > Also, it may be helpful to know that in the ex.err file it produces, all of
> > the
> > variable values for the function in question are listed as <no value>,
> > so apparently it is happening as or just after it has dereferenced those. I
> > assume something is not getting cleaned up properly. Have you changed
> > anything
> > along these lines from v2.5 to 3.0?
>
> Yes, there were changes in subroutine call/return to support multitasking.
> These changes can affect programs even if they don't use multitasking.
> If you are doing recursion, that might be of particular interest in
> solving this.
>
I'm slowly narrowing in on this. There is no way I will be able to do anything
with the source code to help here -- it is simply over my head. I've found two
instances of this now that I can reliably repeat. This is code I've been using
for years. Both crashes occur when exiting functions that are being called as
methods in Mike Nelson's Diamond. Which means they are being called via
routine-id. If I call them directly (which does involve changing a few things
because certain Diamond calls won't work that way) I can't get them to crash. So
does calling a function via call_func/routine-id affect things, or maybe that is
just a coincidence? Or maybe it because of recursion -- Diamond has its own call
stack, so calling anything at all in Diamond might involve some recursion.
One of the functions is actually only two lines long:
function save_forest
put_obj(get_property(this(),"savepath")&"for_"&get_property(this(),"name")&".ent",save_entity(this()))
return NIL
end function
What this does is save the Diamond entity to the hard drive. The call
"save_entity(this())" converts the current entity into a byte sequence -- that's
a recursive function very similar to the one in EDS that converts Eu objects into
byte sequences for storage. The other parts grab filepaths and filenames, the
procedure "put_obj" simply opens up the filename for binary writing, and puts()
the second argument to disk.
The other function that crashes is much more complex, but it does call some
other functions which are also recursive.
Another thing I've verified is that the return value itself seems unimportant;
it crashes with anything, even just an integer 0.
It is important to note that everything in the function gets done, and done
correctly -- it just crashes on exit. (For instance, in the first example, the
entity is successfully saved to disk before the crash.)
Also, they don't crash every time the function is called -- conditions have to
right. I don't know what the right conditions are, but in my case they involve
doing a bunch of complicated sequence building, and if the initial conditions are
the same, it will crash reliably at the same point. But as usual with these
things, just changing a line here or there or adding a reference will cause it to
no longer crash, or to crash at a different point, even if the logic of the
program is the same.
For instance, if I change the above the function to :
function save_forest
sequence e
e = save_entity(this())
put_obj(get_property(this(),"savepath")&"for_"&get_property(this(),"name")&".ent",e)
return NIL
end function
then it no longer crashes. It is because the bug no longer occurs when written
like that, or it is just because I've changed the conditions and it would still
crash in other conditions? Can't tell.
6. Re: EU 3.0.1 -- there's probably a bug in there somewhere
Andy Serpa wrote:
>
> For instance, if I change the above the function to :
>
> }}}
<eucode>
> function save_forest
> sequence e
> e = save_entity(this())
>
> put_obj(get_property(this(),"savepath")&"for_"&get_property(this(),"name")&".ent",e)
> return NIL
> end function
> </eucode>
{{{
>
> then it no longer crashes. It is because the bug no longer occurs when
> written
> like that, or it is just because I've changed the conditions and it would
> still
> crash in other conditions? Can't tell.
>
Actually, scratch that. Just tested it again, and it crashes that way too.
7. Re: EU 3.0.1 -- there's probably a bug in there somewhere
Found another example in a different program -- how can no one else be having
this problem? This time it crashed as it was exiting a procedure, so I guess
functions aren't special. Also this was a non-Diamond program, no calls via
routine-id, so I guess that isn't it either. This program is much simpler, so
maybe I can come up with an example to show you. I will investigate further...
8. Re: EU 3.0.1 -- there's probably a bug in there somewhere
Ok, I got it. Recursion does cause the problem. Get yourself a copy of kanarie
v1.8b and try this:
[I'm using exw.exe here on an Athlon XP Pro system, btw.]
include kanarie.e -- kanarie version 1.8b (gotta be that version cause its got
recursion)
include machine.e
without warning
clear_screen()
integer D, L1, L2
set_rand(11) -- with rand seeding at 11, I get a crash on iteration 20
for crashtrycount = 1 to 25 do
? crashtrycount
D = createData()
setValue(D,"value1",sprint(rand(10000)))
setValue(D,"value2",sprint(rand(10000)))
-- make some lists, ensuring recursion later
for i = 1 to rand(100) do
L1 = addListItem(D,"list1")
setValue(L1,"listval1",sprint(rand(10000)))
setValue(L1,"listval2",sprint(rand(10000)))
setValue(L1,"listval3",sprint(rand(10000)))
setValue(L1,"listval4",sprint(rand(10000)))
setValue(L1,"listval5",sprint(rand(10000)))
setValue(L1,"listval6",sprint(rand(10000)))
for j = 1 to rand(20) do -- add list inside list to cause further recursion
L2 = addListItem(L1,"list2_nested")
setValue(L2,"list2val1",sprint(rand(10000)))
setValue(L2,"list2val1",sprint(rand(10000)))
setValue(L2,"list2val1",sprint(rand(10000)))
setValue(L2,"list2val1",sprint(rand(10000)))
end for
end for
setValue(D,"value3",sprint(rand(10000)))
setValue(D,"value4",sprint(rand(10000)))
closeData(D) -- this will close D recursively
end for
9. Re: EU 3.0.1 -- there's probably a bug in there somewhere
I don't suppose this is much help in isolating the bug but I had a program crash
on me a couple of weeks ago using exu 3.01 (it actually shut down the computer).
Unfortunately I don't have the code but it involved manipulating a large sequence
(100,000 integers) and used a return statement in a procedure. I'm just playing
around now with similar code (as I remember) and will let you know if I get a
crash.
10. Re: EU 3.0.1 -- there's probably a bug in there somewhere
Andy Serpa wrote:
>
>
> Ok, I got it. Recursion does cause the problem. Get yourself a copy of
> kanarie
> v1.8b and try this:
>
> [I'm using exw.exe here on an Athlon XP Pro system, btw.]
>
Here's some simpler code that causes a crash. However, after rebuilding
from source, I wasn't getting the crash (with the vanilla rds source, nor
with ooeu source). Also, the traceback only goes to 100 levels before it
quits...and looking at the source, I see:
#define MAX_TRACEBACK 100 /* maximum number of levels of traceback to show */
However, I suspect that it's not checking entirely correctly very well to
make sure we don't go past this (I don't think this was an issue with
Andy's stuff, since he didn't go as deep).
puts(1, "Starting\n")
integer count
count = 0
procedure recurse(integer r )
count += 1
if r = 0 then
? count
return
else
recurse( r - 1 )
end if
end procedure
recurse( 12000 )
puts(1,"Done\n")
if getc(0) then
end if
11. Re: EU 3.0.1 -- there's probably a bug in there somewhere
> Here's some simpler code that causes a crash. However, after rebuilding
> from source, I wasn't getting the crash (with the vanilla rds source, nor
> with ooeu source). Also, the traceback only goes to 100 levels before it
> quits...and looking at the source, I see:
>
> #define MAX_TRACEBACK 100 /* maximum number of levels of traceback to show */
>
> However, I suspect that it's not checking entirely correctly very well to
> make sure we don't go past this (I don't think this was an issue with
> Andy's stuff, since he didn't go as deep).
>
> }}}
<eucode>
> puts(1, "Starting\n")
> integer count
> count = 0
> procedure recurse(integer r )
> count += 1
> if r = 0 then
> ? count
> return
> else
> recurse( r - 1 )
> end if
> end procedure
>
> recurse( 12000 )
>
> puts(1,"Done\n")
> if getc(0) then
>
> end if
> </eucode>
{{{
No crashing on my system...
12. Re: EU 3.0.1 -- there's probably a bug in there somewhere
- Posted by Andy Serpa <ac at onehorseshy.com>
Feb 02, 2007
-
Last edited Feb 03, 2007
Matt Lewis wrote:
>
> Andy Serpa wrote:
> >
> >
> > Ok, I got it. Recursion does cause the problem. Get yourself a copy of
> > kanarie
> > v1.8b and try this:
> >
> > [I'm using exw.exe here on an Athlon XP Pro system, btw.]
> >
>
> Here's some simpler code that causes a crash. However, after rebuilding
> from source, I wasn't getting the crash (with the vanilla rds source, nor
> with ooeu source). Also, the traceback only goes to 100 levels before it
> quits...and looking at the source, I see:
>
> #define MAX_TRACEBACK 100 /* maximum number of levels of traceback to show */
>
> However, I suspect that it's not checking entirely correctly very well to
> make sure we don't go past this (I don't think this was an issue with
> Andy's stuff, since he didn't go as deep).
>
> }}}
<eucode>
> puts(1, "Starting\n")
> integer count
> count = 0
> procedure recurse(integer r )
> count += 1
> if r = 0 then
> ? count
> return
> else
> recurse( r - 1 )
> end if
> end procedure
>
> recurse( 12000 )
>
> puts(1,"Done\n")
> if getc(0) then
>
> end if
> </eucode>
{{{
Confirmed. Crashes on mine too. My work here is done.
Now someone smart fix it... :)
13. Re: EU 3.0.1 -- there's probably a bug in there somewhere
- Posted by Kenneth Rhodes <ken_rhodes30436 at yahoo.com>
Feb 02, 2007
-
Last edited Feb 03, 2007
Matt Lewis wrote:
>
> Andy Serpa wrote:
> >
> >
> > Ok, I got it. Recursion does cause the problem. Get yourself a copy of
> > kanarie
> > v1.8b and try this:
> >
> > [I'm using exw.exe here on an Athlon XP Pro system, btw.]
> >
>
> Here's some simpler code that causes a crash. However, after rebuilding
> from source, I wasn't getting the crash (with the vanilla rds source, nor
> with ooeu source). Also, the traceback only goes to 100 levels before it
> quits...and looking at the source, I see:
>
> #define MAX_TRACEBACK 100 /* maximum number of levels of traceback to show */
>
> However, I suspect that it's not checking entirely correctly very well to
> make sure we don't go past this (I don't think this was an issue with
> Andy's stuff, since he didn't go as deep).
>
Doesn't crash on my system...
-- 3.01 crash test
puts(1, "Starting\n")
integer count
count = 0
procedure recurse(integer r )
count += 1
if r = 0 then
? count
return
else
recurse( r - 1 )
end if
end procedure
recurse( 12000 )
puts(1,"Done\n")
if getc(0) then
end if
ken@linux:~/euprogs> exu crash.ex
Starting
12001
Done
Ken Rhodes
Folding at Home: http://folding.stanford.edu/
100% MicroSoft Free
SuSE Linux 10.0
No AdWare, SpyWare, or Viruses!
Life is Good, 
14. Re: EU 3.0.1 -- there's probably a bug in there somewhere
- Posted by Pete Lomax <petelomax at blueyonder.co.uk>
Feb 02, 2007
-
Last edited Feb 03, 2007
Matt Lewis wrote:
> Here's some simpler code that causes a crash.
Confirmed here too, on 3.0.0 but not 2.4, 2.5, or cb-3.0.1.
> However, after rebuilding from source, I wasn't getting the crash
No way to know if a source mod fixes it then...
I had a quick hack and it appears to be crashing on my system in routine
restore_privates, in the code:
// restore the current task's private data (will always be there)
block = load_private_block(this_routine, current_task);
// private vars
sym = this_routine->next;
while (sym != NULL && sym->scope <= S_PRIVATE) {
sym->obj = *block++;
sym = sym->next;
}
it crashes on the sym->obj = *block statement. A chunk of heap ends at #004D5FFF
and when it crashes block is #004D6000. sym is correctly pointing at the
parameter r. I have not studied load/save_private_block, but that is where my
suspicions would lie. A random thought I had is that if it were saving and
loading everything out-by-one, it might well appear to work fine in 99.9% of
cases. Or maybe not.
Regards,
Pete
15. Re: EU 3.0.1 -- there's probably a bug in there somewhere
- Posted by Derek Parnell <ddparnell at bigpond.com>
Feb 02, 2007
-
Last edited Feb 03, 2007
Andy Serpa wrote:
> Confirmed. Crashes on mine too. My work here is done.
>
> Now someone smart fix it... :)
It seem like a 'stack size' issue.
On my Windows XP SP2 machine, it worked at depth 3210 but failed after that
depth. I then added a local integer to cause it allocate a larger stack frame on
each iteration and the depth threshold fell to 3094.
--
Derek Parnell
Melbourne, Australia
Skype name: derek.j.parnell
16. Re: EU 3.0.1 -- there's probably a bug in there somewhere
- Posted by Robert Craig <rds at RapidEuphoria.com>
Feb 02, 2007
-
Last edited Feb 03, 2007
Pete Lomax wrote:
>
> Matt Lewis wrote:
> > Here's some simpler code that causes a crash.
> Confirmed here too, on 3.0.0 but not 2.4, 2.5, or cb-3.0.1.
> > However, after rebuilding from source, I wasn't getting the crash
> No way to know if a source mod fixes it then...
>
> I had a quick hack and it appears to be crashing on my system in routine
> restore_privates,
> in the code:
>
> // restore the current task's private data (will always be there)
>
> block = load_private_block(this_routine, current_task);
>
> // private vars
> sym = this_routine->next;
> while (sym != NULL && sym->scope <= S_PRIVATE) {
> sym->obj = *block++;
> sym = sym->next;
> }
>
> it crashes on the sym->obj = *block statement. A chunk of heap ends at
> #004D5FFF
> and when it crashes block is #004D6000. sym is correctly pointing at the
> parameter
> r. I have not studied load/save_private_block, but that is where my suspicions
> would lie. A random thought I had is that if it were saving and loading
> everything
> out-by-one, it might well appear to work fine in 99.9% of cases. Or maybe not.
Thanks to everyone for helping pin this down.
I'll be able to look at this later today (in a few hours).
As you sugggest, it could be that I'm allocating slightly less memory
than I need in some cases. That would cause occasional crashes
that might go away with just a trivial change in the user's program.
Thanks,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
17. Re: EU 3.0.1 -- there's probably a bug in there somewhere
Robert Craig wrote:
> Pete Lomax wrote:
> > Matt Lewis wrote:
> > > Here's some simpler code that causes a crash.
> > Confirmed here too, on 3.0.0 but not 2.4, 2.5, or cb-3.0.1.
> > > However, after rebuilding from source, I wasn't getting the crash
> > No way to know if a source mod fixes it then...
> >
> > I had a quick hack and it appears to be crashing on my system in routine
> > restore_privates,
> > in the code:
> >
> > // restore the current task's private data (will always be there)
> >
> > block = load_private_block(this_routine, current_task);
> >
> > // private vars
> > sym = this_routine->next;
> > while (sym != NULL && sym->scope <= S_PRIVATE) {
> > sym->obj = *block++;
> > sym = sym->next;
> > }
> >
> > it crashes on the sym->obj = *block statement. A chunk of heap ends at
> > #004D5FFF
> > and when it crashes block is #004D6000. sym is correctly pointing at the
> > parameter
> > r. I have not studied load/save_private_block, but that is where my
> > suspicions
> > would lie. A random thought I had is that if it were saving and loading
> > everything
> > out-by-one, it might well appear to work fine in 99.9% of cases. Or maybe
> > not.
>
> Thanks to everyone for helping pin this down.
> I'll be able to look at this later today (in a few hours).
> As you suggest, it could be that I'm allocating slightly less memory
> than I need in some cases. That would cause occasional crashes
> that might go away with just a trivial change in the user's program.
I wasn't able to duplicate the crash, but I've found a bug
in load_private_block() that could very well be the cause.
static object *load_private_block(symtab_ptr routine, int task)
// Retrieve a private block and remove it from the list for this routine.
// We know that the block will be there, often near the start of the list.
{
struct private_block *p;
struct private_block *prev_p;
struct private_block *defunct;
object *block;
p = routine->u.subp.saved_privates; // won't be NULL
prev_p = NULL;
while (TRUE) {
if (p->task_number == task) {
block = (object *)&(p->block);
// unlink it
if (prev_p == NULL) {
routine->u.subp.saved_privates = p->next;
}
else {
prev_p->next = p->next;
}
EFree(p); // BUG: too soon!!!
return block;
}
prev_p = p;
p = p->next;
}
}
In the C code above, I've made the mistake of freeing block p,
*then* returning a pointer into it. The caller uses that pointer
to retrieve some data. EFree() would usually just put p onto a
list, but if the storage cache is getting too full (over 2000 blocks),
it will actually call free(), which, on Windows, could occasionally
result in modification of the freed block, perhaps merging it with
an adjacent block, shrinking the heap or something.
(Originally, "block" was a separately allocated block of memory,
but for efficiency, I combined it into block p using a C coding trick.)
The fix is easy since load_private_block() is only called
from one place. I just have to retrieve the data from block p,
*before* calling EFree().
I'll check the new code in tomorrow.
Maybe we need 3.0.2 soon.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
18. Re: EU 3.0.1 -- there's probably a bug in there somewhere
Pete Lomax wrote:
> it crashes on the sym->obj = *block statement. A chunk of heap ends at
> #004D5FFF
> and when it crashes block is #004D6000.
Since pages of memory managed by the O/S are on 4K (hex 1000) boundaries,
I strongly suspect that as the recursion was unwinding, and blocks
were getting freed, a full page became free and the O/S reclaimed it,
removing it from the heap space for the exw.exe process,
thereby making #004D6000 an invalid virtual address for exw.exe
(that would be caught by the hardware).
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
19. Re: EU 3.0.1 -- there's probably a bug in there somewhere
I fixed the bug in load_private_block() and checked in the new
source (be_execute.c), and new executables.
I actually got it to crash on my machine before fixing it.
If anyone wants to test them, the new Windows interpreters
are at:
http://www.rapideuphoria.com/uploads/exw.exe
and
http://www.rapideuphoria.com/uploads/exwc.exe
The fix will officially be in 3.0.2 when it's released,
hopefully fairly soon. That release will also fix the
Windows translator bug with multitasking.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
20. Re: EU 3.0.1 -- there's probably a bug in there somewhere
Robert Craig wrote:
>
> Pete Lomax wrote:
> > it crashes on the sym->obj = *block statement. A chunk of heap ends at
> > #004D5FFF
> > and when it crashes block is #004D6000.
>
> Since pages of memory managed by the O/S are on 4K (hex 1000) boundaries,
> I strongly suspect that as the recursion was unwinding, and blocks
> were getting freed, a full page became free and the O/S reclaimed it,
> removing it from the heap space for the exw.exe process,
> thereby making #004D6000 an invalid virtual address for exw.exe
> (that would be caught by the hardware).
Thanks for fully detailing that. I was a little bit worried, but the above
confirms that you actually understood wot I said way better than I did 
).
>I actually got it to crash on my machine before fixing it.
Doubly good. I have tested and the new exw[c].exe works fine here.
Regards,
Pete
21. Re: EU 3.0.1 -- there's probably a bug in there somewhere
> The fix will officially be in 3.0.2 when it's released,
> hopefully fairly soon. That release will also fix the
> Windows translator bug with multitasking.
>
Seems to have taken care of it...
