1. machine level exception in file.e again
It happened again. I still see no reason for it.
Kat
2. Re: machine level exception in file.e again
Kat wrote:
>
>
> It happened again. I still see no reason for it.
>
> Kat
I assume in the same place with the same ex.err?
--
A complex system that works is invariably found to have evolved from a simple
system that works.
--John Gall's 15th law of Systemantics.
"Premature optimization is the root of all evil in programming."
--C.A.R. Hoare
j.
3. Re: machine level exception in file.e again
Jason Gade wrote:
>
> Kat wrote:
> >
> >
> > It happened again. I still see no reason for it.
> >
> > Kat
>
> I assume in the same place with the same ex.err?
Same error, same place in the code, but much further along in the 15gig file
it's reading from. Thing is, the dir() is obviously NOT handling the 15gig file,
just the dir with 450 megabytes and 97,000 files in it. This is a level well
within winxp and eu abilities, and the drive has not failed at any other time,
only with this machine call in file.e. And if i restart the app, it runs a few
more days, and then crashes again the same way.
Kat
4. Re: machine level exception in file.e again
Kat wrote:
>
> Same error, same place in the code, but much further along in the 15gig file
> it's reading from. Thing is, the dir() is obviously NOT handling the 15gig
> file,
> just the dir with 450 megabytes and 97,000 files in it. This is a level well
> within winxp and eu abilities, and the drive has not failed at any other time,
> only with this machine call in file.e. And if i restart the app, it runs a few
> more days, and then crashes again the same way.
>
I have run a test for Kat on my Windows Vista box. I created a directory and
made an app that created 100,000 files in that directory. I then did a dir() in
Euphoria. It took a little under 3 seconds to return the sequence and print a
length() on the sequence. I ran it 20 times w/no error.
I am not sure what this means or if it means anything. Just providing more
information.
--
Jeremy Cowgar
http://jeremy.cowgar.com
5. Re: machine level exception in file.e again
Jeremy Cowgar wrote:
>
> I have run a test for Kat on my Windows Vista box. I created a directory and
> made an app that created 100,000 files in that directory. I then did a dir()
> in Euphoria. It took a little under 3 seconds to return the sequence and print
> a length() on the sequence. I ran it 20 times w/no error.
>
> I am not sure what this means or if it means anything. Just providing more
> information.
>
Oh, In Linux the exact same program took 0.298s and completed w/o problem.
--
Jeremy Cowgar
http://jeremy.cowgar.com
6. Re: machine level exception in file.e again
Jeremy Cowgar wrote:
>
> Kat wrote:
> >
> > Same error, same place in the code, but much further along in the 15gig file
> > it's reading from. Thing is, the dir() is obviously NOT handling the 15gig
> > file,
> > just the dir with 450 megabytes and 97,000 files in it. This is a level well
> > within winxp and eu abilities, and the drive has not failed at any other
> > time,
> > only with this machine call in file.e. And if i restart the app, it runs a
> > few
> > more days, and then crashes again the same way.
> >
>
> I have run a test for Kat on my Windows Vista box. I created a directory and
> made an app that created 100,000 files in that directory. I then did a dir()
> in Euphoria. It took a little under 3 seconds to return the sequence and print
> a length() on the sequence. I ran it 20 times w/no error.
>
> I am not sure what this means or if it means anything. Just providing more
> information.
It runs fast on winxp-sp2 also, except when it crashes. I have added a counter
to see if there is a maxdircount per crash or something.... without a huge_seek()
tho, it may take till tomorrow just to get back to where it was, and resume.
Kat
7. Re: machine level exception in file.e again
Kat wrote:
>
> Jason Gade wrote:
> >
> > Kat wrote:
> > >
> > >
> > > It happened again. I still see no reason for it.
> > >
> > > Kat
> >
> > I assume in the same place with the same ex.err?
>
> Same error, same place in the code, but much further along in the 15gig file
> it's reading from. Thing is, the dir() is obviously NOT handling the 15gig
> file, just the dir with 450 megabytes and 97,000 files in it. This is a
> level well within winxp and eu abilities, and the drive has not failed at
> any other time, only with this machine call in file.e. And if i restart the
> app, it runs a few more days, and then crashes again the same way.
Does it always crash on a dir with a 15gig file? There could be an overflow
in there that's causing problems. You might try Greg H's win_dir
libary:
http://www.rapideuphoria.com/win_dir.zip
Matt
8. Re: machine level exception in file.e again
Matt Lewis wrote:
>
> Kat wrote:
<snip>
> > it's reading from. Thing is, the dir() is obviously NOT handling the 15gig
> > file, just the dir with 450 megabytes and 97,000 files in it. This is a
<snip>
> Does it always crash on a dir with a 15gig file? There could be an overflow
1) the 15 gig file is not handled, not seen, by dir
2) the 15 gig file is never in a folder i run dir on
3) the 15 gig file may be on another drive
4) i have had dir troubles before on win95 and winxp-sp2
5) the 15 gig file is not an issue
6) i am getting real sorry i mentioned the topic
7) this is about dir, which doesn't open the files
8) if dir cracked up on a particular file, i'd have said so
> in there that's causing problems. You might try Greg H's win_dir
> libary:
>
> <a
> href="http://www.rapideuphoria.com/win_dir.zip">http://www.rapideuphoria.com/win_dir.zip</a>
>
I have it, it seems to be a program to munge normal dir output. Munging such
data cannot be the problem if dir never returns. I asked if i can trap the
non-returning dir, called in file.e, in the machine call, and been told no, so i
don't see why another lib of eu code could.
Kat
9. Re: machine level exception in file.e again
- Posted by Bernie Ryan <xotron at ?luef?og.com>
May 16, 2008
-
Last edited May 17, 2008
Kat wrote:
>
> Matt Lewis wrote:
> >
> > Kat wrote:
>
> <snip>
>
> > > it's reading from. Thing is, the dir() is obviously NOT handling the 15gig
> > > file, just the dir with 450 megabytes and 97,000 files in it. This is a
>
> <snip>
>
> > Does it always crash on a dir with a 15gig file? There could be an overflow
>
> 1) the 15 gig file is not handled, not seen, by dir
> 2) the 15 gig file is never in a folder i run dir on
> 3) the 15 gig file may be on another drive
> 4) i have had dir troubles before on win95 and winxp-sp2
> 5) the 15 gig file is not an issue
> 6) i am getting real sorry i mentioned the topic
> 7) this is about dir, which doesn't open the files
> 8) if dir cracked up on a particular file, i'd have said so
>
> > in there that's causing problems. You might try Greg H's win_dir
> > libary:
> >
> > <a
> > href="http://www.rapideuphoria.com/win_dir.zip">http://www.rapideuphoria.com/win_dir.zip</a>
> >
>
> I have it, it seems to be a program to munge normal dir output. Munging such
> data cannot be the problem if dir never returns. I asked if i can trap the
> non-returning
> dir, called in file.e, in the machine call, and been told no, so i don't see
> why another lib of eu code could.
>
Kat:
I took a look at win_dir and I see that WIN32_FIND_DATA structure is
commented out and greg is using a constant that computes to
size of 32819 bytes.
constant WIN32_FIND_DATA_SIZE = 40 + 32767 + 12
When I use my software to calculate the structure size
using a MAX_PATH of 260 bytes (win32 default) and TCHAR as a UNICODE
character.
My software says that WIN32_FIND_DATA_SIZE should be 592 bytes.
The wrong size structure could be causing windows to over-write something
in memory causing the exception problem. But maybe greg is using a different
path size for his calculation but I don't think it would be that different.
Bernie
My files in archive:
WMOTOR, XMOTOR, W32ENGIN, MIXEDLIB, EU_ENGIN, WIN32ERU, WIN32API
Can be downloaded here:
http://www.rapideuphoria.com/cgi-bin/asearch.exu?dos=on&win=on&lnx=on&gen=on&keywords=bernie+ryan
10. Re: machine level exception in file.e again
- Posted by Kat <KAT12 at co?sahs.n?t>
May 16, 2008
-
Last edited May 17, 2008
Bernie Ryan wrote:
>
> Kat wrote:
> >
> > Matt Lewis wrote:
> > >
> > > Kat wrote:
> >
> > <snip>
> >
> > > > it's reading from. Thing is, the dir() is obviously NOT handling the
> > > > 15gig
> > > > file, just the dir with 450 megabytes and 97,000 files in it. This is a
> >
> > <snip>
> >
> > > Does it always crash on a dir with a 15gig file? There could be an
> > > overflow
> >
> > 1) the 15 gig file is not handled, not seen, by dir
> > 2) the 15 gig file is never in a folder i run dir on
> > 3) the 15 gig file may be on another drive
> > 4) i have had dir troubles before on win95 and winxp-sp2
> > 5) the 15 gig file is not an issue
> > 6) i am getting real sorry i mentioned the topic
> > 7) this is about dir, which doesn't open the files
> > 8) if dir cracked up on a particular file, i'd have said so
> >
> > > in there that's causing problems. You might try Greg H's win_dir
> > > libary:
> > >
> > > <a
> > > href="http://www.rapideuphoria.com/win_dir.zip">http://www.rapideuphoria.com/win_dir.zip</a>
> > >
> >
> > I have it, it seems to be a program to munge normal dir output. Munging such
> > data cannot be the problem if dir never returns. I asked if i can trap the
> > non-returning
> > dir, called in file.e, in the machine call, and been told no, so i don't see
> > why another lib of eu code could.
> >
>
> Kat:
>
> I took a look at win_dir and I see that WIN32_FIND_DATA structure is
>
> commented out and greg is using a constant that computes to
>
> size of 32819 bytes.
>
> constant WIN32_FIND_DATA_SIZE = 40 + 32767 + 12
>
> When I use my software to calculate the structure size
>
> using a MAX_PATH of 260 bytes (win32 default) and TCHAR as a UNICODE
>
> character.
>
> My software says that WIN32_FIND_DATA_SIZE should be 592 bytes.
>
> The wrong size structure could be causing windows to over-write something
>
> in memory causing the exception problem. But maybe greg is using a different
>
> path size for his calculation but I don't think it would be that different.
Thanks, Bernie. The app is currently running, but again i don't know for how
long. I do suspect that if it's a "length of dir contents" problem, it should
crash the very next time i dir() that dir it crashed on? So far, since yesterday
when i restarted it, it's dir()'d ~130,000 times (i added a counter yesterday),
at about 3 dir()s per second. In this app, dir() is merely verifying the path
exists that i want to write a file to, else dropping to code to createDir()
(win32fil.ew by Jeffrey Fielding and Brian Broker -- come on guys, add some more
stuff!) if it doesn't exist. I don't use the dir listing in this app, i only
verify it's not -1. Any how, 130k+ times to run dir(), and it runs ok so far, it
must be an oddball problem that's causing the crash. Next crash, i'll include
win_dir and give that a try.
Kat
11. Re: machine level exception in file.e again
- Posted by Matt Lewis <matthewwalkerlewis at gmail??om>
May 16, 2008
-
Last edited May 17, 2008
Kat wrote:
>
> > http://www.rapideuphoria.com/win_dir.zip
> >
>
> I have it, it seems to be a program to munge normal dir output. Munging such
> data cannot be the problem if dir never returns. I asked if i can trap the
> non-returning
> dir, called in file.e, in the machine call, and been told no, so i don't see
> why another lib of eu code could.
Yeah, this is basically what I was thinking: the c-library routine for
dir choked on the big file size. Which is why I asked about that file.
You could build a debug version of euphoria, and use the watcom debugger to
step through. This won't go into the internals of the c-library, though.
I was talking about the munging going on to prepare the data returned by dir.
Since Greg's library uses Win32 calls, I thought it might avoid a potential
problem with the watcom runtime library.
I promise not to try to be helpful on this thread anymore.
Matt
12. Re: machine level exception in file.e again
- Posted by Kat <KAT12 at coosahs??et>
May 16, 2008
-
Last edited May 17, 2008
Matt Lewis wrote:
>
> Kat wrote:
> >
> > > <a
> > > href="http://www.rapideuphoria.com/win_dir.zip">http://www.rapideuphoria.com/win_dir.zip</a>
> > >
> >
> > I have it, it seems to be a program to munge normal dir output. Munging such
> > data cannot be the problem if dir never returns. I asked if i can trap the
> > non-returning
> > dir, called in file.e, in the machine call, and been told no, so i don't see
> > why another lib of eu code could.
>
> Yeah, this is basically what I was thinking: the c-library routine for
> dir choked on the big file size. Which is why I asked about that file.
What big file? Dir() is seeing only a lot of ~100K files, i don't think but a
few are 2 megabytes or so, and many are under 1k bytes.
> You could build a debug version of euphoria, and use the watcom debugger to
> step through. This won't go into the internals of the c-library, though.
I keep asking where watcom is, why when i look for it that it's not sold or
supported anymore, and i never get a source for it, so i don't have it. Not in
all the time i have been using Euphoria. Besides, i'd need it to run full speed
til there's an abnormality, and since there are legitimate -1 returned, sitting
here for day after day watching it ask me "is this ok?", "is this ok?" every few
minutes would just be too much. I believe Jeremy is now compiling eu v4.0 on
openwatcom, which isn't the same beast as watcom.
> I was talking about the munging going on to prepare the data returned by dir.
> Since Greg's library uses Win32 calls, I thought it might avoid a potential
> problem with the watcom runtime library.
That's a possibility, yeas. Doesn't dir() use such win32 calls? Does it use bios
calls?
> I promise not to try to be helpful on this thread anymore.
I think our emails are crossing, and this conversation is desync'd. I appreciate
your help, but atm i think we don't have a clue what the other is talking about.
I know i am confused why people think i keep running dir() with a huge file in
the dir, and thinking it's the problem, and why i don't move it to another dir,
when in fact it's been in other dirs and different drives all this time.
Kat
13. Re: machine level exception in file.e again
- Posted by Jason Gade <jaygade at yah?o?com>
May 16, 2008
-
Last edited May 17, 2008
I was going to look at your error dump again, but I guess it was
removed/expired.
Memory problems can be notoriously hard to track down. I was going to suggest
stack overflow in the interpreter but it seems like the only stuff that gets
allocated on the stack are pointers.
I see some Euphoria allocations that I don't know how/when they get freed back
up again but they might be garbage collected somewhere else.
Hmm.
--
A complex system that works is invariably found to have evolved from a simple
system that works.
--John Gall's 15th law of Systemantics.
"Premature optimization is the root of all evil in programming."
--C.A.R. Hoare
j.
