Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Crashing while hashing since 3.9.5 #793

Closed
TheOne320 opened this issue Aug 2, 2019 · 12 comments
Labels

Comments

@TheOne320
Copy link

@TheOne320 TheOne320 commented Aug 2, 2019

VERSION INFORMATION

Server Version: 3.9.5

Desktop Version: 3.9.5

LOG FILE

EventLog1.txt
EventLog2.txt
2019-07-29.log
Since hashing has nothing to do with ShokoDesktop and ShokoDesktop was not open at the time, I will at this time not add a log for that. This ShokoServer log has trace=true .

DESCRIPTION

Shoko keeps crashing while hashing files. Only happens since 3.9.5. Since 3.9.4 sometimes hashing recognized files as being 0 bytes file size and a workaround was moving the file out of the watch folder and back in again.

STEPS TO REPRODUCE

Have qbittorrent download a file (incomplete torrents are kept in a folder not watched by Shoko with the option "keep incomplete torrents in") and when complete, the file is moved from the temp folder into an anime folder which is watched by Shoko. Shoko starts hashing the file. Shoko crashes with no visible error messages.

@Yhoogi1

This comment has been minimized.

Copy link

@Yhoogi1 Yhoogi1 commented Aug 12, 2019

I confirm the observation

While hashing the server seems unstable and crashes without any indication

@bigretromike

This comment has been minimized.

Copy link
Contributor

@bigretromike bigretromike commented Aug 13, 2019

[2019-07-29 19:34:51:651] Error|SVR_VideoLocal_Place.RefreshMediaInfo => AzureWebAPI.Get_Media => AzureWebAPI.GetDataJson Error(1) in AzureWebAPI.GetData: System.Net.WebException: The remote server returned an error: (403) Forbidden.
   at System.Net.HttpWebRequest.GetResponse()
   at Shoko.Server.Providers.Azure.AzureWebAPI.GetDataJson(String uri) in D:\Documents\GitHub\ShokoServer\Shoko.Server\Providers\Azure\AzureWebAPI.cs:line 466
[2019-07-29 19:34:52:083] Error|SVR_VideoLocal_Place.RefreshMediaInfo => AzureWebAPI.Send_Media => AzureWebAPI.SendData HTTP Status Code: 403
[2019-07-29 19:34:52:086] Error|SVR_VideoLocal_Place.RefreshMediaInfo => AzureWebAPI.Send_Media => AzureWebAPI.SendData Error(1) in XMLServiceQueue.SendData: System.Net.WebException: The remote server returned an error: (403) Forbidden.
   at System.Net.HttpWebRequest.GetResponse()
   at Shoko.Server.Providers.Azure.AzureWebAPI.SendData(String uri, String json, String verb) in D:\Documents\GitHub\ShokoServer\Shoko.Server\Providers\Azure\AzureWebAPI.cs:line 421

Maybe it make server unstable with some many issues (leak or something).
Maybe WebCache should be disabled temporary, imo

@Cazzar

This comment has been minimized.

Copy link
Member

@Cazzar Cazzar commented Aug 13, 2019

@bigretromike that error is completely unrelated, unless you have some evidence to the contrary other than speculation

@bigretromike

This comment has been minimized.

Copy link
Contributor

@bigretromike bigretromike commented Aug 13, 2019

it's last entry in log file, it executed spontaneously, it generate latency/load because if not setup correctly It won't retrieve any useful data.
That was just a suggestion, without memory dump all this is just speculation :-)

@bigretromike

This comment has been minimized.

Copy link
Contributor

@bigretromike bigretromike commented Aug 15, 2019

Ok, I'm joing 'crash team' . mine crashed twice now.
Every time on different file.
webcache set as 127.0.0.1 which spam logs like hell.

@Pontuzz

This comment has been minimized.

Copy link

@Pontuzz Pontuzz commented Aug 20, 2019

Hi, I've had my shoko server crash while hashing as well.
Though I was seemingly able to link the issue to shoko trying to move a file that was currently open in another program (deluge) as it successfully hashes & moves the file if I remove it from deluge manually.

@TheOne320

This comment has been minimized.

Copy link
Author

@TheOne320 TheOne320 commented Aug 20, 2019

Hi, I've had my shoko server crash while hashing as well.
Though I was seemingly able to link the issue to shoko trying to move a file that was currently open in another program (deluge) as it successfully hashes & moves the file if I remove it from deluge manually.

If Shoko really tries moving the file, when it wants to hash, then it is obvious why it is not working, as I too have the file open in qBittorrent and need to have it open to keep it seeded. In the past (pre 3.9.4) I never had this problem with Shoko. Why would Shoko need write access (or "move access") to a file, which it should only read?

@bigretromike

This comment has been minimized.

Copy link
Contributor

@bigretromike bigretromike commented Aug 20, 2019

I had this issue without torrent, no antivirus to lock it. Maybe shoko did want to hash it/scan it. Cant tell. Just saying.

@bigretromike

This comment has been minimized.

Copy link
Contributor

@bigretromike bigretromike commented Aug 21, 2019

The fastest way I was able to crash it was dropping file thru network (so it need few seconds to copy - more than 5 seconds) onto Watched Source ImportFolder.

@Cazzar

This comment has been minimized.

Copy link
Member

@Cazzar Cazzar commented Aug 21, 2019

I think the rhash is trying to grab a write lock on the file so we need to either move to our hasher again (max will need to help with that possibly) or check for the ability to create a write lock.

@bigretromike

This comment has been minimized.

Copy link
Contributor

@bigretromike bigretromike commented Aug 21, 2019

The function that sh!t itself is File.Open(filename, ..., mode, share.none) the one in Hasher command.
When you change Mode from Read to Write it will Stackoverflow, but if you leave it as Read then it will terminate in debbuger (at least in VS2017)

Instead of throwing exception that It cannot Lock files it terminate or stackoverflow; according to ms documentation.

It could be possible if there is a overwrite to File.Open but I didn't look for it because VS said it was simple System.IO.File module.

bigretromike added a commit that referenced this issue Aug 24, 2019
Tested few times, I was unable to crash it while transferring files and hashing;
@bigretromike

This comment has been minimized.

Copy link
Contributor

@bigretromike bigretromike commented Aug 24, 2019

Fixed. Thanks for testing guys !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
6 participants
You can’t perform that action at this time.