Deluge requested shutdown

[Shryp]

There is a memory leak in the GTK runtimes that deluge uses on Windows any time the screen gets redrawn. My suggestion is make sure you leave Deluge on a window/tab that isn't active when you aren't using it. Cas' solution on thin client setup means only the client will crash and the back end will keep downloading and seeding for you. It will also allow you to close the window and clean up the memory when you aren't actively manipulating your torrents.

[gddeluca]

Shryp: Does that mean if I leave it alone running in the taskbar, it should be relatively 'fine'. Since it seems to 'last' about a day right now, maybe I should just schedule it to re-cycle overnight at some point.

George

[Shryp]

I use the labelplus plugin and just make sure I leave it on a label that has no active torrents as well as minimized. I didn't bother closing to tray most of the time because of the other windows bug with resuming from the tray at half screen. I am using linux right now and it works better with linux and doesn't have those issue. I used windows and only had it crash about 3-5 times in 3 months. I could see the memory usage going up in the task manager though.

[gddeluca]

OK, I converted to running DelugeD as recommended, Deluge still crashes occasionally.

Today a new version of deluge was released and I installed it. Now Deluge crashes just about every hour.

Where are the developers? How can something like this just be accepted? I'd be bloody embarrassed if I were on the Deluge team and couldn't put out a product that even stayed up when it's just sitting there.

I'm really going to have to switch to something else, this is just too painful.

Oops, there it goes again, I just restarted it before starting this post, and it has already crashed. Pathetic!

George

[Shryp]

1.3.12 hasn't crashed on me yet. Been running it for a couple days now.

[galneon]

I never experienced this crash on 1.3.11, but finally did on 1.3.12 today. My client did not crash--only the daemon on my server.

[Cas]

There is a new libtorrent 1.0.6 included in Deluge 1.3.12 and the only way to determine the issue with crashes is the run a debug version of libtorrent and get a trace: http://dev.deluge-torrent.org/wiki/Buil ... tonWindows

Since I nor other main developers use Windows it is up to users to help diagnose the problem.

[galneon]

A more detailed second window popped up upon termination this time.

Again, this is 1.3.12 py2.7.

[galneon]

After experiencing this crash roughly two dozen times by now and manually restoring my automated backups because the .bak files Deluge creates disappear, I've concluded the integrated backup system, which sought to fix state losses in certain situations (e.g. spontaneous loss of power) is in fact causing this new crash. This crash never happened on 1.3.11 and the timing of the crash suggests to me the cause. It seems to me the error occurs when one of the .bak files cannot be written.

I've attempted to log this in the past, but deluged-console insta-crashes when I attempt to specify a configuration location as well as -L ERROR -l "<log path>". Not specifying a config location isn't possible for me. I take it only so many switches are supported.

Is there a commandline switch I can use to disable the auto-backup procedure? Have any potential problems been resolved regarding the backup feature in between the release of 1.3.12 and the upcoming 1.3.13? I've already checked the bug tracker and saw nothing relevant. It's causing me more headaches than it could possibly save.

If the auto-backup procedure can't be disabled on my end and no one else is able or willing to log the crash, then send me a 1.3.12 for python 2.7 deluged.exe compiled with backups disabled. If it's stable in my demanding torrent environment for a month, we can conclude it's a problem with the auto-backups.

[Cas]

Due to a bug need to use lower case level for logging with deluged-debug.exe

There is a new set of fixes for upcoming 1.3.13 release.