nzbget 0.4.0 oom killed during par2 repair

Get help, report and discuss bugs.
forest

RE: nzbget 0.4.0 oom killed during par2 repai

Post by forest » 10 May 2008, 20:15

I recompiled with configure --enable-debug, and the segfault went away. That was a couple weeks ago.

More recently, I rebuilt without --enable-debug, and tried to reproduce the segfault under gdb. I still couldn't reproduce it. Since the nzb file I was using to reproduce segfaults refers to articles that have now expired, I'm not sure what made the difference, my rebuild or the nzb file.

I'll keep an eye on it, and report back if I see the segfault again.


forest

RE: nzbget 0.4.0 oom killed during par2 repai

Post by forest » 11 May 2008, 19:14

Okay, I rebuilt with CFLAGS and CXXFLAGS set to "-g -fno-stack-protector", ran under gdb, and got some more seg faults. Unfortunately, gdb seems unable to get a meaningful backtrace. It either lists the current function as "??", or shows an infinite stack of "pthread_start_thread" calls. (Could there be a bug in gdb regarding the arm/armel CPU archetecture?)

Anyway, here's what I got:

[DETAIL] Waiting 10 sec to retry

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 4210694 (LWP 5646)]
0xbddffabc in ?? ()
(gdb) info thread
260 Thread 4227079 (LWP 5647) 0x404a6e80 in clone () from /lib/libc.so.6
* 259 Thread 4210694 (LWP 5646) 0xbddffabc in ?? ()
6 Thread 65541 (LWP 5086) 0x40193d80 in __pthread_sigsuspend ()
from /lib/libpthread.so.0
5 Thread 49156 (LWP 5085) 0x40193d80 in __pthread_sigsuspend ()
from /lib/libpthread.so.0
4 Thread 32771 (LWP 5084) 0x404783dc in nanosleep () from /lib/libc.so.6
3 Thread 16386 (LWP 5083) 0x40197f70 in accept () from /lib/libpthread.so.0
2 Thread 32769 (LWP 5082) 0x4049e5ec in poll () from /lib/libc.so.6
1 Thread 16384 (LWP 5079) 0x404783dc in nanosleep () from /lib/libc.so.6
warning: Couldn't restore frame in current thread, at frame 0
0xbddffabc in ?? ()
(gdb) bt
#0 0xbddffabc in ?? ()
(gdb) thread 6
[Switching to thread 6 (Thread 65541 (LWP 5086))]#0 0x40193d80 in __pthread_sigsuspend () from /lib/libpthread.so.0
(gdb) bt
#0 0x40193d80 in __pthread_sigsuspend () from /lib/libpthread.so.0
#1 0x40192a7c in __pthread_wait_for_restart_signal ()
from /lib/libpthread.so.0
#2 0x40195b54 in __pthread_alt_lock () from /lib/libpthread.so.0
#3 0x401925a0 in pthread_mutex_lock () from /lib/libpthread.so.0
#4 0x0006eb8c in Mutex::Lock (this=0x99d98) at Thread.cpp:79
#5 0x00056f98 in QueueCoordinator::LockQueue (this=0x99d48)
at QueueCoordinator.cpp:503
#6 0x0004fa44 in PrePostProcessor::CheckPostQueue (this=0x9c480)
at PrePostProcessor.cpp:336
#7 0x00050a4c in PrePostProcessor::Run (this=0x9c480)
at PrePostProcessor.cpp:163
#8 0x0006ec2c in Thread::thread_handler (pObject=0x9c480) at Thread.cpp:274
#9 0x40190fb0 in pthread_start_thread () from /lib/libpthread.so.0
#10 0x40190fb0 in pthread_start_thread () from /lib/libpthread.so.0
#11 0x40190fb0 in pthread_start_thread () from /lib/libpthread.so.0
#12 0x40190fb0 in pthread_start_thread () from /lib/libpthread.so.0
#13 0x40190fb0 in pthread_start_thread () from /lib/libpthread.so.0
#14 0x40190fb0 in pthread_start_thread () from /lib/libpthread.so.0
#15 0x40190fb0 in pthread_start_thread () from /lib/libpthread.so.0
#16 0x40190fb0 in pthread_start_thread () from /lib/libpthread.so.0
[...etc...]
---Type <return> to continue, or q <return> to quit---q
Quit
(gdb) thread 5
[Switching to thread 5 (Thread 49156 (LWP 5085))]#0 0x40193d80 in __pthread_sigsuspend () from /lib/libpthread.so.0
(gdb) bt
#0 0x40193d80 in __pthread_sigsuspend () from /lib/libpthread.so.0
#1 0x40192a7c in __pthread_wait_for_restart_signal ()
from /lib/libpthread.so.0
#2 0x40193c40 in pthread_create@@GLIBC_2.1 () from /lib/libpthread.so.0
#3 0x0006eda0 in Thread::Start (this=0xb56c0) at Thread.cpp:226
#4 0x00058ce0 in QueueCoordinator::StartArticleDownload (this=0x99d48,
pFileInfo=0x9fe70, pArticleInfo=0xb4838, pConnection=0x90db0)
at QueueCoordinator.cpp:470
#5 0x0005a0b8 in QueueCoordinator::Run (this=0x99d48)
at QueueCoordinator.cpp:148
#6 0x0006ec2c in Thread::thread_handler (pObject=0x99d48) at Thread.cpp:274
#7 0x40190fb0 in pthread_start_thread () from /lib/libpthread.so.0
#8 0x40190fb0 in pthread_start_thread () from /lib/libpthread.so.0
#9 0x40190fb0 in pthread_start_thread () from /lib/libpthread.so.0
#10 0x40190fb0 in pthread_start_thread () from /lib/libpthread.so.0
#11 0x40190fb0 in pthread_start_thread () from /lib/libpthread.so.0
[...etc...]
---Type <return> to continue, or q <return> to quit---q

hugbug

RE: nzbget 0.4.0 oom killed during par2 repair

Post by hugbug » 13 May 2008, 09:35

Sometimes (if connections-errors occur) nzbget can create too many threads. The option "ThreadLimit" limits the number of threads by default to 100.

I wonder why nzbget created so many threads (260) on your machine. Have you changed the option "ThreadLimit"? If so, set it to 100, it should help.

forest

RE: nzbget 0.4.0 oom killed during par2 repai

Post by forest » 13 May 2008, 16:07

> I wonder why nzbget created so many threads (260) on your machine. Have you
> changed the option "ThreadLimit"? If so, set it to 100, it should help.

I have ThreadLimit=40.

I'm not an expert at reading gdb backtraces, but it looks to me like it's showing us thread IDs, not a count of active threads. In other words, maybe nzbget has been starting and ending threads since it began, and eventually reached thread ID 260, but only had 7 or 8 threads running at a time?

Post Reply

Who is online

Users browsing this forum: No registered users and 14 guests