1. New Bug [Attn: Robert Craig]
I know this isn't a fix to implement a new feature, unless you call machine
level exceptions on a regular basis a new feature.
Basically, what I'm doing, is creating a small pre-processor of sorts, that
loads a file up, tokenizes it, and spits it back out in the tokenized format,
to experiment with a few things.
When dealing with a large file, I figured that Sequence operations would be
slower, and I wanted to see about boosting speed. This is where I ran into
the problem. When I allocated a file, into Memory, and started using peeks
to gather the data I wanted, I started getting strange errors. These comming
up at random places, when I changed code.
When I first converted the functions from Sequence Operations to Memory, I
used strict machine_func()/machine_proc() to do it, to avoid any
dependencies on outside libraries to do what I want. When I got to executing
the code, it crashed out of no-where, at a statement that wasn't even dealing
with memory. So I figured, allright, I'll temporarly use machine.e, and
file.e to see if it might be what I'm writting that is causing the problems.
This worked for a time, till the program crashed again, with the same problem,
a machine level exception occured, and this time, it was totally on a
diffrent section of code, that, again, didn't have anything to do with the
normal peek() and poke().
After looking through both error files, to see if I can track down what was
going on, I came to find a Major bug. What I first thought was not memory
assignment errors on my part, turned out to be, memory handling by the
interpreter itself. In one instance, it was crashing on a if statement,
where it'd be getting the return from the function to the statement.
The next crash, came when I was assigning a Token to my sequence of tokens.
If I remember right, I ran into these problems before in 2.4, 2.3, and even
2.2 of the interpreter, but never got around to posting the bug report about
it, since they was all in final versions when I found the bug, and I didn't
think no more about it.
The only thing I can think of, is that the memory block is getting corrupted,
and somehow, Euphoria is thinking that I'm trying to access it's memory block,
which is doubtful, since both crashes occured no where near one of my memory
input routines. Or Euphoria is attempting to use my memory, or some peice
of memory very close to mine, and It's not liking it very much.
In either case, When I'm running the program, the program always crashes when
it get's to a point, of just doing straight reads, and no writting to my
memory blocks, only Euphoria's own memory blocks, or so I assume.
Hope this helps out, cause I don't want to release the code for this on the
list, as it's privitized code.
Mario Steele
2. Re: New Bug [Attn: Robert Craig]
Mario Steele wrote:
<snip>
> After looking through both error files, to see if I can track down what was
> going on, I came to find a Major bug. What I first thought was not memory
> assignment errors on my part, turned out to be, memory handling by the
> interpreter itself. In one instance, it was crashing on a if statement,
> where it'd be getting the return from the function to the statement.
Sounds like the problem I had trying to implement threads in eu. *shudders*
<snip>
> In either case, When I'm running the program, the program always crashes when
> it get's to a point, of just doing straight reads, and no writting to my
> memory blocks, only Euphoria's own memory blocks, or so I assume.
>
> Hope this helps out, cause I don't want to release the code for this on the
> list, as it's privitized code.
>
Would it be possible for you to make a small program that demonstrates the
error, so others could try to reprooduce it? Does it happen every time or
is it a "rare" problem?
Regards, Alexander Toresson
Assembly. Push 'till you pop.
3. Re: New Bug [Attn: Robert Craig]
Mario Steele wrote:
> I know this isn't a fix to implement a new feature, unless you call machine
> level exceptions on a regular basis a new feature.
>
> Basically, what I'm doing, is creating a small pre-processor of sorts, that
> loads a file up, tokenizes it, and spits it back out in the tokenized format,
> to experiment with a few things.
>
> When dealing with a large file, I figured that Sequence operations would be
> slower, and I wanted to see about boosting speed. This is where I ran into
> the problem. When I allocated a file, into Memory, and started using peeks
> to gather the data I wanted, I started getting strange errors. These comming
> up at random places, when I changed code.
>
> When I first converted the functions from Sequence Operations to Memory, I
> used strict machine_func()/machine_proc() to do it, to avoid any
> dependencies on outside libraries to do what I want. When I got to executing
> the code, it crashed out of no-where, at a statement that wasn't even dealing
> with memory. So I figured, allright, I'll temporarly use machine.e, and
> file.e to see if it might be what I'm writting that is causing the problems.
>
> This worked for a time, till the program crashed again, with the same problem,
> a machine level exception occured, and this time, it was totally on a
> diffrent section of code, that, again, didn't have anything to do with the
> normal peek() and poke().
>
> After looking through both error files, to see if I can track down what was
> going on, I came to find a Major bug. What I first thought was not memory
> assignment errors on my part, turned out to be, memory handling by the
> interpreter itself. In one instance, it was crashing on a if statement,
> where it'd be getting the return from the function to the statement.
>
> The next crash, came when I was assigning a Token to my sequence of tokens.
> If I remember right, I ran into these problems before in 2.4, 2.3, and even
> 2.2 of the interpreter, but never got around to posting the bug report about
> it, since they was all in final versions when I found the bug, and I didn't
> think no more about it.
>
> The only thing I can think of, is that the memory block is getting corrupted,
> and somehow, Euphoria is thinking that I'm trying to access it's memory block,
> which is doubtful, since both crashes occured no where near one of my memory
> input routines. Or Euphoria is attempting to use my memory, or some peice
> of memory very close to mine, and It's not liking it very much.
>
> In either case, When I'm running the program, the program always crashes when
> it get's to a point, of just doing straight reads, and no writting to my
> memory blocks, only Euphoria's own memory blocks, or so I assume.
>
> Hope this helps out, cause I don't want to release the code for this on the
> list, as it's privitized code.
If you use peeks and pokes it is almost certainly
your own bug. The fact that the location of the crash varies
after trivial changes to the code does not impress me much.
That's par for the course with this sort of memory corruption error.
You might be writing some data just one byte beyond the space
you allocated, thereby corrupting some Euphoria variable, and
causing an eventual crash far from where you did the poke.
The first thing you should do is read the instructions at
the top of safe.e in euphoria\include. By copying safe.e
into your current directory and using it in place of machine.e
you might catch your bug very easily.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
4. Re: New Bug [Attn: Robert Craig]
Alexander Toresson wrote:
> Sounds like the problem I had trying to implement threads in eu. *shudders*
I assume you were trying to add threads to translated code,
because the interpreter only has one call stack, suitable
for only one thread.
Also, I hope you know what the term "thread-safe library" means,
because not all Euphoria library routines are thread-safe,
nor are the C libraries that Euphoria uses. You will always
have "shudders" unless you resolve this issue.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
5. Re: New Bug [Attn: Robert Craig]
- Posted by Matt Lewis <matthewwalkerlewis at gmail.com>
Feb 15, 2005
-
Last edited Feb 16, 2005
Mario Steele wrote:
>
> I know this isn't a fix to implement a new feature, unless you call machine
> level exceptions on a regular basis a new feature.
>
> Basically, what I'm doing, is creating a small pre-processor of sorts, that
> loads a file up, tokenizes it, and spits it back out in the tokenized format,
> to experiment with a few things.
>
> When dealing with a large file, I figured that Sequence operations would be
> slower, and I wanted to see about boosting speed. This is where I ran into
> the problem. When I allocated a file, into Memory, and started using peeks
> to gather the data I wanted, I started getting strange errors. These comming
> up at random places, when I changed code.
I've run into lots of similar looking errors. I've always tracked it down
to some memory handling error on my part. Either writing something
incorrectly, or having the incorrect structure size, or something.
Matt Lewis
6. Re: New Bug [Attn: Robert Craig]
Robert Craig wrote:
> If you use peeks and pokes it is almost certainly
> your own bug. The fact that the location of the crash varies
> after trivial changes to the code does not impress me much.
> That's par for the course with this sort of memory corruption error.
> You might be writing some data just one byte beyond the space
> you allocated, thereby corrupting some Euphoria variable, and
> causing an eventual crash far from where you did the poke.
>
> The first thing you should do is read the instructions at
> the top of safe.e in euphoria\include. By copying safe.e
> into your current directory and using it in place of machine.e
> you might catch your bug very easily.
Actually, I just changed include machine.e into include safe.e, and again, it
was a red harring. After running with safe.e, I found that I was poking a
0 byte into memory, that wasn't allocated for my usage. With that, it was
destroying Euphoria's internal Memory Space. So with that in mind, I again
cried wolf. So, from now on, I will extensivly test stuff, and see if I
can't find a way around the bug, or if there's an error in my syntax, before
reporting anything.
Mario Steele
7. Re: New Bug [Attn: Robert Craig]
On Wed, 16 Feb 2005 07:30:49 -0800, Mario Steele
<guest at RapidEuphoria.com> wrote:
<snip>
>After running with safe.e, I found that I was poking a
>0 byte into memory, that wasn't allocated for my usage. With that, it was
>destroying Euphoria's internal Memory Space.
<snip>
> So with that in mind, I again cried wolf.
No you didn't. You asked for help and you got it. You were not to know
you were wrong. (OK, 20:20 hindsight would pick your new code over
Robs 12-year old tried and tested stuff..)
<snip>
> So, from now on, I will extensivly test stuff, and see if I
>can't find a way around the bug, or if there's an error in my syntax, before
>reporting anything.
I dunno, all I can say is it got the job done. Perhaps you worded
something harshly. If there is someone you (appear to) feel needs an
apology, fess up & say thanks. If not, who harmed who?
If you feel any feathers have been ruffled, soothe them.
Regards,
Pete
