1. New Bug [Attn: Robert Craig]
- Posted by Mario Steele <eumario at trilake.net> Feb 15, 2005
- 485 views
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]
- Posted by Alexander Toresson <alexander.toresson at gmail.com> Feb 15, 2005
- 465 views
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]
- Posted by Robert Craig <rds at RapidEuphoria.com> Feb 15, 2005
- 460 views
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]
- Posted by Robert Craig <rds at RapidEuphoria.com> Feb 15, 2005
- 451 views
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
- 459 views
- 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]
- Posted by Mario Steele <eumario at trilake.net> Feb 16, 2005
- 497 views
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]
- Posted by Pete Lomax <petelomax at blueyonder.co.uk> Feb 17, 2005
- 472 views
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