- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
Long time reader, frist time commenter!
Admin
Can sumone be posting Java version of this code plz?
Admin
Should have just used a cron job.
Admin
I'm probably being a dumbass but apart from the fact that he made a desktop app instead of a service, where's the wtf? I'd also like to know how the code caused a page fault - I can't see a reason from the code...
Admin
Admin
Does this code do anything other than search for files over and over again on an infinite loop? I'm pretty rusty on VB..
Admin
The code is not something one would be very proud of but where is the WTF?
Also the author does not seem to know what a page fault is: http://en.wikipedia.org/wiki/Page_fault.
Admin
Admin
strIniFileLoc wasn't initialized, which may or may not cause the custom GetPathFromIni to fail.
We're also missing the implementation of SearchListForFile, which seems to be responsible for the brunt work.
Of course TRWTF is that Alex has no clue what a "page fault" is.
Admin
Keep in mind that, from the language used in the article, this wasn't the final code, just a checkpoint along the way. We don't even have the code that does the actual killing of files, just the crazy bad infinite looping structure and half assed (pseudo?)code.
Admin
Alex or Kevin?
Admin
Can VB6 even get page faults? It's a managed runtime.
I don't see anything wrong with this code, assuming the functions we don't see work properly. Is it the best solution? No, but it does the job.
Admin
It's so cute went application devs, and the OP/editor, try to talk about OS basics they nothing about.
Admin
FTFY
Admin
Admin
I think I speak for everyone when I say that anyone who codes like this shouldn't be let anywhere near the Windows API.
Admin
I worked with someone who did something like this. Platform was .NET though, but I think his implementation beats this one:
His app needed to 'watch' certain things (about 100 in total). He figured the best way to do this was to kick of a thread for each item, and each thread was running a timer. Thing was, he used the System.Timers.Timer, executes in a thread-pool. So for all his work to make sure each thread was truly executing 'individually', they ended up just waiting for the worker thread to be free.
The whole thing was built as a Windows Forms app so it was easier for him to test, then it just landed up on the server like that. You couln't just dump it in the starup items or schedule it either because some buttons/options needed to be selected to get it going.
Admin
Is that a Goto I see before me?
Admin
A page fault happens when Windows cannot find data in memory and has to go to the disk. The choice for this term is a bit unfortunate because there is not really a fault, just no matching piece in RAM and I/O is starting. For a script that takes care of files 50 page faults should happe quite fast.
Admin
First, captcha: transverbero Means transfix. I'm wondering what they meant by page fault, lol. Did they have really really slow disks, like page faults were handled by an old librarian finding the right pages in the book on some shelf in the basement? (Maybe they meant segfault, lol)
Admin
Why? It's a script that you write in 15 minutes with no hassle. You would of course go for an XML solution running in Framework 4.1 using more than 20 mandays for something that just has to run in the background.
Admin
Killed after 50 page faults? My dwm.exe produces two thousand each second. Killed after 50 segmentation faults? NOW that's patience.
transverbero:(1p sg. v. latin): (transitive) To render motionless, by arousing terror, amazement or awe. (transitive) To pierce with a sharp pointed weapon. (transitive) To fix or impale. [edit]
Admin
"After failing miserably to reason on other solutions, the code was deployed to production. After about the 50th page fault on the server, the 'service' was 'stopped' and promptly removed from existence."
I think he means that the service deleted itself. Notice how he put 'stopped' in quotes. The code sample is not good, but I don't see any obvious WTF.
Admin
The gut reaction of the arrogant programmer is to blame the nearest VB application for anything that goes wrong on a computer. This is clearly a hardware issue, and Kevin was wasting valuable uptime with his blame-shifting.
Admin
At least he used Option Explicit...
Admin
And the real WTF is, of course, the Option Explicit! VB6 is such a clean language, why do we need to bother with the pesky details of strong typing all of a sudden?
Admin
Wow, so much hate for the author...there must be a lot of VB6 enthusiasts reading today.
Admin
A page fault is a fault, generated at the hardware layer, saying the memory page you requested is not available right now. The OS deals with it, not the application. It is one of the few things an OS should be doing, as opposed to integrating with one of your web browsers, for instance.
Now an Invalid Page Fault, that's an entirely different animal. Back in the days of Windows 3.x you used to get GPFs (General Protection Faults) all the time. This is where Windows got its reputation for crashing 30 seconds after you back it out of the garage. People hated GPFs. So Microsoft came out with Windows 95 and in a big ad campaign (so effective it had people camping out to buy the software when they had no hardware!) they proclaimed they had gotten rid of all the GPFs! Yaaay!
Except they just renamed them to IPFs. It was still as crashy as ever.
Admin
And another great mind.
Admin
Admin
What does "WriteError" do? Is it spitting out the error to a file, then looping back to a module named "Main", or is it writing the word "Main" in the errorlog. If it is the first, then "stopping" the script by moving the ini file would be...an undocumented stability feature?
Admin
I have one!
blnLoopEternal = False Do Until blnLoopEternal = True
Note that it is never once set to true within the loop. By design, the loop is intended to end at some point, but there is never a clean termination of the loop. It relies on the raising of an exception somewhere. Seems very sloppy to me.
Here's another: Instead of making this script a scheduled task, the programmer opted to build in the timing mechanism. If the team decided that they wanted to run this script at different intervals, they would have to modify the code rather than just modifying the task.
TRWTF is no better solutions.
Admin
Would you mind enlightening us by explaining where the WTF is? No one has done that yet.
Admin
No, undoubtedly what was meant was Invalid Page Faults (i.e. page faults where there isn't supposed to be a page, rather than valid page faults, where the relevant page is not mapped into the process's address space right now). Unix-like systems match IPFs onto SIGSEGV, but it isn't normally a segmentation violation.
Funky code that writes using a CS: override will create a proper segmentation fault, of course, but it's hard to write that in VB.
(*) Strictly speaking, x86 doesn't have a flat mode. Flat mode would indicate that the segment registers aren't used at all, whereas even in what looks a lot like a 32-bit flat mode, the segment registers don't even contain the same value. They cannot contain the same value because CS must contain a selector for an executable or execute-read segment, and SS must contain a selector for a writeable segment. (Writeable is mutually exclusive with executable. This conundrum is the basis for the aforementioned NX hack.)
On Win32, CS = a 4GB read-execute (code) segment, DS=ES=SS = a 4GB read-write (data) segment, FS = a tiny segment containing the current thread's user-mode thread control block. It is normally used only by Structured Exception Handling. GS is not used.
On Win32s (Win32 on Win3.1), back in the day, the segments weren't even mapped to the beginning of the 32-bit linear address space, but both full-on Win32 in NT and Win32c in 9x mapped offset 0 to linear 0 (except FS:, duh), but linear 0 doesn't necessarily map to physical 0, paging being what it is, and isn't normally marked present either.
Admin
Would you mind enlightening us by explaining where the WTF is? No one has done that yet.
There, I can't edit so I'll just double post. Who the hell invented that "Reply to" shit anyway? Either make the "In reply to" more useful(tooltips would be fine) or just remove the "Reply" button and let people use the "quote" (they can always delete the quote anyway).
Admin
Admin
I think the true WTF is using "Oops" as a exception catching label. It's a distant cousin of "UhOh" and "OhShit"
Admin
"After failing miserably to reason on other solutions,"
Admin
What? No FreeFile()?
Admin
Remember that 'segment fault' is a UNIX term that predates the x86, and the x86 segment registers, by quite a bit. I agree with you that having a 'x86 segment register violation' is nigh impossible, that's not what a SEGV means. The segment in this case is the processes' legally addressable memory. You could get a SEGV on a 680x0 which never had segment registers.
captcha: the three ABIGOs.
Admin
The Lemming Switch
is a great title for a book or song or movie or something
Why can't I just copy and paste the captcha? transcribing it is so tedious.
Admin
And I, too, have worked on Unixalikes that didn't have segments as such, notably Ultrasparc III+s on Solaris, and IBM AIX machines. Those were weird, because either by hardware feature, OS design or local config, reading via NULL didn't SEGV your program. (It was a large vendor of financial information services, and had systems so large that IBM had to patch the OS to allow single executables to have more than 256MB in their .text segment.)
Admin
The page faults are caused by the OS processing of the ini file. Windows has APIs for dealing with ini files that produce locks (somewhere) that prevent another process from accessing an ini file while it is already being accessed. If you run a program like this and the look at it in detail in task manager you will see the page faults. These faults don't really cause a problem except for a very high OS overhead cost. If you do it often enough it will bring even a powerful server to it's knees. (Don't you just love windoze?)
I know this, unfortunately, because I made the same mistake when I was younger and even stupider than I am now. Fortunately, it was easy to find and fix. Used the database instead of an ini file.
Admin
WTF is the WTF?
Admin
TRWTF is that programming snobs look down upon VB.
Admin
Admin
[quote user=oldami]The page faults are caused by the OS processing of the ini file. Windows has APIs for dealing with ini files that produce locks (somewhere) that prevent another process from accessing an ini file while it is already being accessed.[/quote]
That's not a page fault, that's a file access violation. And as along as the other process wasn't writing to the .ini file, it's fine. And since this is a custom ini file and the application is single-threaded, the possibility of some other process having that init file open for writing at the same time is probably nil.
Perhaps there was another application whose job it was to delete the ini file (you know, like an admin app to stop this app), and instead of deleting upon command by an end-user, did it constantly in a loop.
(what was probably really happening was the files the app were attempting to delete were open by another application resulting in a file access violation)
Admin
I'm sorry, but this sounds like the biggest load of b******t I've heard in a long time :-) I fail to see a connection between locking a file and causing page faults.
Admin
Fault is a correct term. It just does not deserve the negative connotation when used in this context. Its a fault in that the MMU is basically saying "That is not here", which is not problem, the fault it handled by paging whatever "That" was into memory from disk or other type of secondary storage.
Think of it the same way you think about raising an exception in your code. Its a "bad" thing that an exception been raised, it only becomes bad if its not caught and handled in some way that prevents causes the application/process to fail; otherwise its just a fancy kind of branching.
Admin
For those not getting what is wrong with the code:
First, the loop is crazy. Get a list of files in a folder and then for every file in the folder, check to see if it is on the list. Especially since file system object has a way to check if a file exists, it is a whole lot of extra work as opposed to looping through the contents of the .ini file iteslf and just checking the folder to see if it exists -- much more effecient.
Of course that is minor. The major problem is that it does not clean up any resources. It keeps grabbing a file and folder handle each loop. It never sets the variable to "nothing", never giving it a chance to clean up before the next loop. Not that VB6 had any great garbage collection in the first place, but still not a good idea to keep grabbing handles to everything in the loop.
And finally -- it is a VB6 app that does this! Seriously, why would anyone think this is a good idea.