Page 1 of 1

Crashing

PostPosted: Fri Jan 13, 2006 2:27 pm
by demi
Everything was working ok until this mornig. The program would not start. Kept displaying and error and refused the key. After reboot it worked fine.

:?:

Demi

I sent the data to you also

PostPosted: Fri Jan 13, 2006 3:15 pm
by Aaron
Thanks Demi,

I'll get right onto it.

PostPosted: Fri Jan 13, 2006 4:43 pm
by Aaron
Hi Demi,

That's the most damnable error I’ve ever seen! Reading a text file, character by character, was returning the wrong value. This wasn't anything fancy either: good old fashioned fgetc(fp) was giving incorrect values. The best bit was that I could fix it by putting a 100-millisecond sleep in before starting to read the file. Something is very, very wrong with that. That should not work. Anyhow, I think I've fixed the problem (without really knowing why), so please download the latest update utility and have another go.

Best regrds,
Aaron.

PostPosted: Fri Jan 13, 2006 9:31 pm
by demi
It may be that I have a slower hard drive. It seemed to fix all the issues I was having. I started it 2 times then rebooted and tried again and it is working fine now. Thanks for the fix!

Demi

PostPosted: Fri Jan 13, 2006 11:31 pm
by Aaron
Oh good, I'm glad that voodoo worked. The frustrating thing is that hard-disk speed (or any other system metric) should not come into this - the OS is supposed to guarantee that when you read a file you always get the right bits. If the disk is slow, then the function should take longer to execute, but it should still return the same value. Hrumpfh!

PostPosted: Wed Feb 01, 2006 2:42 pm
by Aaron
Hello,

I've finally worked out the reason for and proper resolution to this bug.

When starting up, L3DT is loading several files and simultaneously writing to the debug.log file. Every time something is added to this file, L3DT flushes the file buffers to make sure the OS doesn't cache anything, which ensures everything gets written in case of a program crash. Flushing buffers, I now know, interferes with file loading operations. In single-threaded code you don't get this problem because everything is synchronous and sequential. However, the initialisation of L3DT is seriously multithreaded, so we get asynchronous and possibly parallel flush/read operations, which causes the train-wreck observed. By inserting a sleep, I've delayed one thread slightly, and bingo, no collision. A better option would be to set a semaphore when reading files that forbids buffer-flushing, but I'll only do this if the problem reoccurs (the sleep was an easy fix).

Cheers,
Aaron.

PostPosted: Wed Feb 01, 2006 10:37 pm
by demi
Glad you found the real issue. I will test this new update out and let you know if there is any problem.

Demi