It seems that you can't break on std::bad_alloc::bad_alloc, the constructor is probably optimized away.

I'm gonna make a small patch to get some usefull output.

Yea, that might be an option.
I tried using 'catch throw' and 'break __cxa_throw', but they both break on all exceptions. I think the cxa_throw thing could work with some additional condition. I'll try to build libstdc++ with debug symbols, maybe that helps...

Can you try this patch:

http://ktorrent.org/downloads/bad_alloc.patch

This will abort when the bad_alloc normally is thrown, this should result in a good backtrace.

Ok, so I patched the main.cpp and ran ktorrent a few times till it crashed. I'm not sure how helpful the backtraces actually will be, two of the four times it crashed inside of some Qt redrawing, the other two times while allocating the localwindow buffer for a new utp connection.

Also I paid more attention to the memory usage then before. I could watch the usage grow steadily over time from initially around 4% after startup up to 40%-70% where it crashed. That really surprised me, because I had only some uploads and no downloads running, and due to me being firewalled behind a nat and the torrents being near the end of their lifetime, ktorrent only transmitted maybe ~150 MiB during the 3-5 hours it ran.

So I guess it does look more like a memory leak situation than I realized.

I tried a few other things the last day on my own (like running gprof to see if constructor/destructor call numbers don't match, or running ktorrent inside valgrind) but I couldn't extract any useful information from that data yet.

Do you have any idea how many connections to peers there were, right before the crash ?

So clearly there is some sort of memory leak, and then it is just a matter of time before a bad_alloc is thrown somewhere.

Hm... I'd say there were maybe 5-7 established connection in 3 of the 4 crashes (not counting dht). The last one probably had more, since the syndication plugin started autodownloading a new file. From what I can tell, ktorrent is mostly trying to establish a new connection, but fails.

I made a comparison last night. While utp is deactivated, the memory usage stayed at 4.5% for over 7 hours. As soon as I turned utp back on, it started increasing. Now, two hours after turning it on again, the memory usage is at 9.4%, while the connections tab shows 2 connections to leechers, some spikes (one or two connected seeds for a short time) and 605 dht nodes.

I also attached part of the logfiles corresponding to the 4 crashes I posted last time. Don't know if there's anything useful in there though.

Can somebody try the following patch (on libktorrent trunk) ?

This should make the crashes go away, I would like some independent confirmation so I can close this issue.