Get help, report and discuss bugs.
-
vinnaaah
Post
by vinnaaah » 23 Feb 2005, 11:51
So now I'm testing with the patched SingleServerPool.cpp/h with the BSD patch (0.1.2-fp1)
But I'm seeing quite some changes between SingleServerPool-0.1.2 and 0.1.2-alt5, so the test I'm running prolly won't really show anything useful.
-
wfhiker
Post
by wfhiker » 23 Feb 2005, 11:58
Here the diff of original nzbget-0.1.2/SingleServerPool.cpp and nzbget-0.1.2-alt5/SingleServerPool.cpp is just a few deug messages.
-
vinnaaah
Post
by vinnaaah » 23 Feb 2005, 13:04
Hi Hiker,
Oh ok, you're probably right. I scanned through it, and it looked completely diffferent. But it appears I was mistaken.
So my test isn't useless after all, *whew* (it's still running OK btw)
grtV
-
vinnaaah
Post
by vinnaaah » 23 Feb 2005, 14:05
Next problem: loop in freeConnection..
[DEBUG]
SingleServerPool::freeConnection(NNTPConnection*) : Connection 0 freed
[DEBUG] SingleServerPool::freeConnection(NNTPConnection*) : Connection 1 freed
[DEBUG] SingleServerPool::freeConnection(NNTPConnection*) : Connection 1 freed
[DEBUG] SingleServerPool::freeConnection(NNTPConnection*) : Connection 0 freed
[DEBUG] SingleServerPool::freeConnection(NNTPConnection*) : Connection 0 freed
// give back free connection
for (int i = 0; i < this->max; i++)
{
if (this->connections == con) {
debug("SingleServerPool::freeConnection(NNTPConnection*) : Connection %d freed",i);
gets stuck in (i < this->max)? Or freeConnection gets called over and over again?
-
wfhiker
Post
by wfhiker » 23 Feb 2005, 15:36
How fast do you get these debug messages?
I should work this way: after a ArticleDownloader completed the download of a single article it will call freeConnection to give the next ArticleDownloader the chance to get a Connection. So depending of the size of an article and your connection speed you should get this debug message quite often, but not too fast.
-
vinnaaah
Post
by vinnaaah » 23 Feb 2005, 19:13
Hey hiker,
About one each second or so. The queue processing stops: in my case after a 44th part of a 107 parts file.
After posting I restarted nzbget and it hasn't crashed since. So it does not crash on a specific file of something.
-
rvkasper
Post
by rvkasper » 23 Feb 2005, 22:50
Hi Placebo and vinnaaah and hiker...
Well upon applying the alt5.1 patch (that patch and only that patch) to my source and recompiling I can preliminarily say that it has fixed the seg fault... I got through a several gig nzb file - I will continue to post backtrace info on any other downloads I run into trouble with. Good work!
FYI I am running it under FC2 - the reason my queues are so huge is that I tend to create nzb files off of my newzbin bookmarked posts list... with several posts in one nzb file.
Let me know if any questions, and keep up the good work all.
Ryan
-
vinnaaah
Post
by vinnaaah » 24 Feb 2005, 06:47
Another:
[DEBUG] FileDownloader::notify(Observable* caller)
[DEBUG] SingleServerPool::freeConnection(NNTPConnection*) : Connection 1 freed
[DEBUG] Job::Job(int)
free(): invalid pointer 0x8101250!
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16386 (LWP 14791)]
0x40312284 in mallopt () from /lib/libc.so.6
(gdb) bt
#0 0x40312284 in mallopt () from /lib/libc.so.6
#1 0x4031109f in free () from /lib/libc.so.6
#2 0x080596be in Frontend::printMessages (this=0x808dcc8)
at Frontend.cpp:116
#3 0x08059601 in Frontend::run (this=0x808dcc8) at Frontend.cpp:102
#4 0x080524ba in Thread::thread_handler (obj=0x808dcc8) at Thread.cpp:72
#5 0x4015ce51 in pthread_start_thread () from /lib/libpthread.so.0
#6 0x4015cecf in pthread_start_thread_event () from /lib/libpthread.so.0
#7 0x403776ea in clone () from /lib/libc.so.6
FYI, debian kernel 2.4.27, I've running 0.1.2 without problems foor like six months or so.
-
vinnaaah
Post
by vinnaaah » 24 Feb 2005, 15:56
Ok, I'm suspecting RAM problems because I got some crashes in phtread-native code.
I've replaced the (possibly) faulty module and I'm testing again..
-
placebodk
Post
by placebodk » 25 Feb 2005, 12:33
vinnaaah, it would be really great if it actually turns out it was RAM problems, since the last crash you posted the callstack from was in code that I haven't gotten around poking my greasy coder fingers into (at least not yet) - hence it should really be the same code as found in 0.1.2.
/placebodk
Who is online
Users browsing this forum: No registered users and 46 guests