아래에 select()에서 가끔 발생하는 세그먼트폴트에 대한 궁금증

malloc 해서 쓰는 메모리가 많은가보군요;;

음... backtrace로 알수 있는 정보는
죽은 지점 정도만 알수 있구요.

실제로 분석을 할려면,
스텍 프레임을 옮겨 다니면서 값들을 체크 해봐야 해요..
스텍 프레임을 옮겨 다는 것은
up, down 명령어가 있는데, 각 스택 프레임 별로
info local을 실행해서 로컬 변수의 상태를 봐야겠죠.

또 몇가지 체크 포인트가 있는데 core파일이 있으면
요런 분석이 쉬워지거든요;; 압축해서 웹서버나 ftp에
올려주시고 url을 메일로 알려주세요.

gdb 사용법은..

http//www.gnu.org/manual/gdb-5.1.1/gdb.html
여기 메뉴얼만한게 없는것 같군요;;

근데 올리신 글을 보니 쓰레딩을 사용하시는거 같은데,
시그널이 문제가 될수 있습니다.

알람 종류들은 시그널을 사용하는데,
이 시그널이 멀티쓰레딩 환경에서는 그 알람을
셋팅한 쓰레드에서 받는게 아니란 거죠..;;
(누가 받을지 몰라요.. )

오렐리에서 나온 pthread 책중에서 시그널 처리에
관한 부분을 보시길 권합니다...

또 쓰레드 관리하기 위해서 pthread 라이브러리가
sigusr1 sigusr2를 사용하니 이 시그널을 사용하시는 것도 안됩니다.

http//pauillac.inria.fr/~xleroy/linuxthreads/faq.html
LinuxThreads Frequently Asked Questions
(with answers)
중에서 쓰레드와 시그널 관련글입니다.

J. Signals and threads
J.1 When it comes to signals, what is shared between
threads and what isn't?
Signal handlers are shared between all threads when a
thread calls sigaction(), it sets how the signal is handled
not only for itself, but for all other threads in the
program as well.
On the other hand, signal masks are per-thread each thread
chooses which signals it blocks independently of others. At
thread creation time, the newly created thread inherits the
signal mask of the thread calling pthread_create(). But
afterwards, the new thread can modify its signal mask
independently of its creator thread.

J.2 When I send a SIGKILL to a particular thread using
pthread_kill, all my threads are killed!
That's how it should be. The POSIX standard mandates that
all threads should terminate when the process (i.e. the
collection of all threads running the program) receives a
signal whose effect is to terminate the process (such as
SIGKILL or SIGINT when no handler is installed on that
signal). This behavior makes a lot of sense when you
type "ctrl-C" at the keyboard, or when a thread crashes on
a division by zero or a segmentation fault, you really want
all threads to stop immediately, not just the one that
caused the segmentation violation or that got the SIGINT
signal. (This assumes default behavior for those signals;
see question J.3 if you install handlers for those signals.)
If you're trying to terminate a thread without bringing the
whole process down, use pthread_cancel().

J.3 I've installed a handler on a signal. Which thread
executes the handler when the signal is received?
If the signal is generated by a thread during its execution
(e.g. a thread executes a division by zero and thus
generates a SIGFPE signal), then the handler is executed by
that thread. This also applies to signals generated by raise
().
If the signal is sent to a particular thread using
pthread_kill(), then that thread executes the handler.

If the signal is sent via kill() or the tty interface (e.g.
by pressing ctrl-C), then the POSIX specs say that the
handler is executed by any thread in the process that does
not currently block the signal. In other terms, POSIX
considers that the signal is sent to the process (the
collection of all threads) as a whole, and any thread that
is not blocking this signal can then handle it.

The latter case is where LinuxThreads departs from the
POSIX specs. In LinuxThreads, there is no real notion of
``the process as a whole'' in the kernel, each thread is
really a distinct process with a distinct PID, and signals
sent to the PID of a thread can only be handled by that
thread. As long as no thread is blocking the signal, the
behavior conforms to the standard one (unspecified) thread
of the program handles the signal. But if the thread to
which PID the signal is sent blocks the signal, and some
other thread does not block the signal, then LinuxThreads
will simply queue in that thread and execute the handler
only when that thread unblocks the signal, instead of
executing the handler immediately in the other thread that
does not block the signal.

This is to be viewed as a LinuxThreads bug, but I currently
don't see any way to implement the POSIX behavior without
kernel support.

J.3 How shall I go about mixing signals and threads in my
program?
The less you mix them, the better. Notice that all
pthread_* functions are not async-signal safe, meaning that
you should not call them from signal handlers. This
recommendation is not to be taken lightly your program can
deadlock if you call a pthread_* function from a signal
handler!
The only sensible things you can do from a signal handler
is set a global flag, or call sem_post on a semaphore, to
record the delivery of the signal. The remainder of the
program can then either poll the global flag, or use
sem_wait() and sem_trywait() on the semaphore.

Another option is to do nothing in the signal handler, and
dedicate one thread (preferably the initial thread) to wait
synchronously for signals, using sigwait(), and send
messages to the other threads accordingly.

J.4 When one thread is blocked in sigwait(), other threads
no longer receive the signals sigwait() is waiting for!
What happens?
It's an unfortunate consequence of how LinuxThreads
implements sigwait(). Basically, it installs signal
handlers on all signals waited for, in order to record
which signal was received. Since signal handlers are shared
with the other threads, this temporarily deactivates any
signal handlers you might have previously installed on
these signals.
Though surprising, this behavior actually seems to conform
to the POSIX standard. According to POSIX, sigwait() is
guaranteed to work as expected only if all other threads in
the program block the signals waited for (otherwise, the
signals could be delivered to other threads than the one
doing sigwait(), which would make sigwait() useless). In
this particular case, the problem described in this
question does not appear.

One day, sigwait() will be implemented in the kernel, along
with others POSIX 1003.1b extensions, and sigwait() will
have a more natural behavior (as well as better
performances).

sleep(), nanosleep()는 시그널을 사용하구요
select()는 시그널이랑은 무관하구요;;;

지금 세그멘테이션 폴트난 쓰레드가 원인이 아니라,
다른 쓰레드가 세그멘테이션 폴트난 쓰레드의
영역을 침범해서 문제가 될수도 있을듯 하군요..

아래는 시스템콜 트레이스 입니다.
=== sleep 사용시

close(3) = 0
mprotect(0x40074000, 970752, PROT_READ|PROT_WRITE) = 0
mprotect(0x40074000, 970752, PROT_READ|PROT_EXEC) = 0
personality(PER_LINUX) = 0
getpid() = 13634
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
rt_sigaction(SIGCHLD, NULL, {SIG_DFL}, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
nanosleep({10, 0}, {10, 0}) = 0
fstat64(0x1, 0xbffff0e0) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x40169000
ioctl(1, TCGETS, {B9600 opost isig icanon echo ...}) = 0
write(1, "object is at 0xbffff8f0\n", 24object is at 0xbffff8f0) = 24
munmap(0x40169000, 4096) = 0
_exit(0) = ?

=== select 사용시

close(3) = 0
mprotect(0x40074000, 970752, PROT_READ|PROT_WRITE) = 0
mprotect(0x40074000, 970752, PROT_READ|PROT_EXEC) = 0
personality(PER_LINUX) = 0
getpid() = 13660
select(1, NULL, NULL, NULL, {5, 0}) = 0 (Timeout)
fstat64(0x1, 0xbffff0e0) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x40169000
ioctl(1, TCGETS, {B9600 opost isig icanon echo ...}) = 0
write(1, "object is at 0xbffff8f0\n", 24object is at 0xbffff8f0) = 24
munmap(0x40169000, 4096) = 0
_exit(0) = ?