[Chenko]

So after a while of trying different things to fix the problem it's time to make a thread. Basically, the issue is randomly fopen starts to return invalid file handles for every file it opens even though they all exist. Now I've used FileEx debugging to try and find the issue but that just keeps the server from crashing on the first instance of fopen returning an invalid file handle. It just keeps the server running with a non-functioning fopen and no files will open until the server is restarted.

The weird thing is there was no issues with fopen until we switched from dini to y_ini. I'm not sure if y_ini or improper usage of y_ini could be the problem but it's possible.

FileEx debugging:

Code:

[07/23/2013 13:55:21]  [DEBUG] <file_ex.inc> fopen() -> Failed to open or create file "Logs/Commands.log"
[07/23/2013 13:55:21]  [DEBUG] <file_ex.inc> fwrite() -> Attempted to write into file stream ( File:0 )
[07/23/2013 13:55:21]  [DEBUG] <file_ex.inc> fclose() -> Attempted to destroy a file stream with a NULL pointer ( File:0 )
[07/23/2013 13:55:21]  [DEBUG] <file_ex.inc> fopen() -> Failed to open or create file "Logs/Commands.log"
[07/23/2013 13:55:21]  [DEBUG] <file_ex.inc> fwrite() -> Attempted to write into file stream ( File:0 )
[07/23/2013 13:55:21]  [DEBUG] <file_ex.inc> fclose() -> Attempted to destroy a file stream with a NULL pointer ( File:0 )


[07/24/2013 11:20:28] [FileManager]: The file "scriptfiles/Logs/AdminActions.log" was moved to "scriptfiles/Logs/View/2013_07/AdminActions_1374661228.log"
[07/24/2013 11:20:28] [FileManager]: "scriptfiles/Logs/AdminActions.log" was created succesfully
[07/24/2013 11:20:56]  [DEBUG] <file_ex.inc> fopen() -> Failed to open or create file "Logs/AdminActions.log"
[07/24/2013 11:20:56]  [DEBUG] <file_ex.inc> fwrite() -> Attempted to write into file stream ( File:0 )
[07/24/2013 11:20:56]  [DEBUG] <file_ex.inc> fclose() -> Attempted to destroy a file stream with a NULL pointer ( File:0 )

Crash detect errors (only happens without FileEx debugging) :

Code:

[07/27/2013 04:28:51] [debug] Server crashed while executing VortexRoleplay.amx
[07/27/2013 04:28:51] [debug] AMX backtrace:
[07/27/2013 04:28:51] [debug] #0 native fwrite () [00405710] from samp-server.exe
[07/27/2013 04:28:51] [debug] #1 00166fcc in ICChatLog (string[]=@0x051b98e8 "[Canadian Accent] Rex McDougal...") at VortexRoleplay.pwn:1905
[07/27/2013 04:28:51] [debug] #2 004a1c24 in ?? (... <2 arguments>) at VortexRoleplay.pwn:20749
[07/27/2013 04:28:51] [debug] #3 0010ca70 in public OnPlayerText (playerid=64, text[]=@0x0427791c "Just wait till I get all my ga...") at C:\Program Files (x86)\pawno\include\YSI\y_hooks/impl.inc:885
[07/27/2013 04:28:51] [debug] Native backtrace:
[07/27/2013 04:28:51] [debug] #0 772e22b2 in ?? () from C:\Windows\SysWOW64\ntdll.dll
[07/27/2013 04:28:51] [debug] #1 004925a0 in ?? () from C:\Users\Administrator\Desktop\SAMPSrv\samp-server.exe
[07/27/2013 04:28:51] [debug] #2 0040534e in ?? () from C:\Users\Administrator\Desktop\SAMPSrv\samp-server.exe

Thanks for any help you can provide.

[Chenko]

Bump

[Westingham]

The problem described above is an incredibly frustrating one as there appears to be no rhyme or reason to it. Generally it happens after SaveGeneralData finishes and we initially thought it was related to our log rotation, but after some testing with the debug mode of FileManager we found that they were unrelated; additionally, the problem will occur nowhere near SaveGeneralData, almost completely randomly in fact.

Is there any history of fopen() simply refusing to work after a certain amount of time? Is there any way of obtaining more debug information than the file_ex include can provide? Any help that anybody can provide on this situation would be greatly appreciated.

[Chenko]

I'm going to bump this once more. As Westingham said the issue appears randomly with no indication of why. There must be someone who at least has some sort of clue as to why this is occurring or could be occurring.

[Westingham]

Nobody has any idea what could cause fopen() to spontaneously stop working?

[BigETI]

I'll list some reasons why this can happen:

• A process has no or limited privileges to open a file. (Try as administrator)
• The file is already being occupied by another process. Also happens, if the file handle wasn't closed properly. (Restart your machine)
• Your process simply ran out of memory to handle files.

[Westingham]

1.) It worked before, it works after, there is no reason for it to suddenly stop working.
2.) All file handles are closed after being opened. This has been checked multiple times. I'm also pretty certain the non-threaded nature of SAMP makes this not possible.
3.) With 8+ GB of RAM dedicated to a SAMP server that uses maybe 230 MB RAM, this doesn't seem likely.

[BigETI]

Quote:

Originally Posted by Westingham 1.) It worked before, it works after, there is no reason for it to suddenly stop working.

I remember when I had to experience that my server wasn't able to access files, means that a process CAN have a certain limit given by the OS. Most likely running as administrator will give the process FULL privilegs to handle with files.

Quote:

Originally Posted by Westingham 2.) All file handles are closed after being opened. This has been checked multiple times. I'm also pretty certain the non-threaded nature of SAMP makes this not possible.

If you say so. But still a file can be opened by another process (doesn't mean it has to be opened by the server itself) such as for example an editor, which internally keeps its file handle opened and the OS won't allow another processes to handle this file.

Quote:

Originally Posted by Westingham 3.) With 8+ GB of RAM dedicated to a SAMP server that uses maybe 230 MB RAM, this doesn't seem likely.

Doesn't matter, if a OS gives limits resources to a process. It only depends on how much it's set for processes on the OS.

[Westingham]

1.) This has been working for nearly 1.5 years, it only started happening to us when we switched to y_ini. The only confusing part is that our logs are not touched by y_ini at all.

2.) I think it's already being run/handled by administrator, I'll double-check, but again this has been working for so long and only now is it failing.

3.) I'll look into this, but I'm still pointing at the fact that this has been working for so long.