FileIOThread - internal crash Error

[gadget069]

I just upgraded to v 6.11 build 1342 today and now I cannot dowload a complete file, i get this error now, argh...

Code: Links not allowed for unregistered users

[13:57:03] ERROR   - FileIOThread - internal crash
[14:04:51] ERROR   - FileIOThread - internal crash
[14:06:00] ERROR   - FileIOThread - internal crash
[14:06:36] ERROR   - FileIOThread - internal crash

[patrickbrunet]

Funny, I was about to post regarding the exact same error I keep getting here. Although for me, it began before that version on some files, now I'm getting this error more and more often. Please help someone!

[patrickbrunet]

Just to add some details. The file downloads completely then the error happens and the file stays with _yEnc.nb2 instead of assembling it to the real filename.

[Quade]

Try 6.2. Released today.

[gadget069]

I'm getting this now

Code: Links not allowed for unregistered users

[17:58:30] ERROR   - INT_AssembleFile Crash

[DThor]

Any chance you're running 32 bit?

DT

[gadget069]

Any chance you're running 32 bit?

DT

Yes I am.

[Quade]

It's not clear to me whether you're seeing this AFTER upgrading to the 6.2 release or not.

[patrickbrunet]

Try 6.2. Released today.

I just downloaded it and it still doesn't work but the error message is now: [21:44:05] ERROR - INT_AssembleFile Crash
I'm running 64-bit.

[Quade]

Might be time wipe everything and start fresh then. I really don't know why a 64 bit user would have an issue. The problem with the 32 bit users seems to be that they run out of address space and the filemap fails, still I've forced filemap failures here and it doesn't crash anything. You see any other related notices? "CopyMode" or anything like that? Might be worth turning the log level to "Debug" in the advanced tab.

This isn't in a VM or anything weird like that is it? Is this happening with every file? PM me a subject and group and I'll check it out. Don't post it here.

[Quade]

I have a theory. How about PMing me the subject and group.

[gadget069]

I did install on my 64bit machine and all is well, but I'd like to keep newsbin on my 32bit XP pro. Ill pm you with the info when I get home from work.

Thanks for the help.

[Quade]

Typically on 32 bit machines, you can fix this by enabling the /3gb switch.

http://technet.microsoft.com/en-us/libr ... 0(EXCHG.65).aspx

I'm toying with the idea of removing file mapping altogether. It's an optimization that seems to be causing problems.

[gadget069]

Typically on 32 bit machines, you can fix this by enabling the /3gb switch.

http://technet.microsoft.com/en-us/libr ... 0(EXCHG.65).aspx

I'm toying with the idea of removing file mapping altogether. It's an optimization that seems to be causing problems.

I tried that, still the same issue. Is there anyway to get a previous version that does not have this issue. I really dont want to run this on my 64bit machine, mostly for gaming.

[Quade]

Pretty sure old ones had the same issue and the problem just had a different error string. Is this happening to every file or just some? You might want to exit, delete downloads.db3 and autopar2.db3 and see if the symptoms change. The will wipe the download list and the autopar state.

You can run any version you want.

[gadget069]

Pretty sure old ones had the same issue and the problem just had a different error string. Is this happening to every file or just some? You might want to exit, delete downloads.db3 and autopar2.db3 and see if the symptoms change. The will wipe the download list and the autopar state.

You can run any version you want.

I don't remember what version i was running before upgrading and everything was fine. I've been running newsbin for 5yrs without any issues until now.

Thanks again for the help.

[tl]

Typically on 32 bit machines, you can fix this by enabling the /3gb switch.

However, it should also be mentioned that there's a good reason why this setting isn't the default, doing this will break some Windows installs (some drivers refuse to load, a few can even cause corruption!) and that some graphics cards won't work properly with it.

In addition there's a small number of programs that breaks, because the memory layout is different even for non-LARGEADDRESSAWARE binaries. Yes, if it breaks the program is doing unsupported things but it's still broken by this change.

Doing this also reduces the available kernel memory space (1GB instead of 2GB) which in turn makes Windows much more vulnerable to programs that either uses a lot of kernel memory or fragment one or both of the kernel heaps. Depending on what programs and drivers you run "kernel memory space exhaustion" can be the leading cause of needing to to reboot even without this switch! Enabling /3GB will make it a lot more likely and a lot more people will be affected, note that Windows itself uses quite a bit of that space there so in reality the non-OS "usable" area is probably reduced by a factor somewhere between 3 and 5, not simply cut in half.

I'm toying with the idea of removing file mapping altogether. It's an optimization that seems to be causing problems.

On a 64-bit OS it's a viable method but I think it'll make a big difference. With 32-bit binaries I think it's a bad idea except in very special cases when you know the files will always be very small. Theoretically you could switch method depending on size, but I think it's better to just go with regular IO on 32-bit binaries.

[gadget069]

Typically on 32 bit machines, you can fix this by enabling the /3gb switch.

However, it should also be mentioned that there's a good reason why this setting isn't the default, doing this will break some Windows installs (some drivers refuse to load, a few can even cause corruption!) and that some graphics cards won't work properly with it.

In addition there's a small number of programs that breaks, because the memory layout is different even for non-LARGEADDRESSAWARE binaries. Yes, if it breaks the program is doing unsupported things but it's still broken by this change.

Doing this also reduces the available kernel memory space (1GB instead of 2GB) which in turn makes Windows much more vulnerable to programs that either uses a lot of kernel memory or fragment one or both of the kernel heaps. Depending on what programs and drivers you run "kernel memory space exhaustion" can be the leading cause of needing to to reboot even without this switch! Enabling /3GB will make it a lot more likely and a lot more people will be affected, note that Windows itself uses quite a bit of that space there so in reality the non-OS "usable" area is probably reduced by a factor somewhere between 3 and 5, not simply cut in half.

I'm toying with the idea of removing file mapping altogether. It's an optimization that seems to be causing problems.

On a 64-bit OS it's a viable method but I think it'll make a big difference. With 32-bit binaries I think it's a bad idea except in very special cases when you know the files will always be very small. Theoretically you could switch method depending on size, but I think it's better to just go with regular IO on 32-bit binaries.

I did have some system "lag" issues enabling the 3gb switch (windows explorer not responding right away). Hopefully there will be a fix soon.

[Quade]

It's not saying filemap error though so, this might be a wild goose chase. I have another theory but it can't be tested till later. A filemap failure doesn't cause an internal crash any more.

[gadget069]

Thanks for the help, i re-installed 5.59 and everything is working fine again.

[Quade]

Patrick tells me this was all caused by a bad RAID array and he's since fixed the issue. I've removed filemapping for 6.3 so, as an issue file mapping will go away with the first 6.3 beta.