OpenEuphoria

Re: machine level exception in file.e again

• Posted by Kat <KAT12 at co?sahs.n?t> May 16, 2008
• 661 views

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