Closed madhwang closed 8 years ago
안녕하세요. 항상 발생하나요? 아니면 간헐적으로 발생하나요?
항상 발생합니다. 로그아웃 후 다시 로그인해서 사용하다보면 또 발생하니까요. 추가로, 커널은 4.4.0-13 인데요. 예전에 3.19 버전 쓸때도 같은 현상이 발생했었습니다.
아무래도 이클립스가 dasom에게 영향을 끼쳐서 dasom이 죽는 것 같은데, 그 영향이 뭔지 궁금해서요. 혹시 추가로 정보가 필요하신 경우 알려주시면 찾아서 올리도록 하겠습니다.
혹시라도, 상세한 로그를 생성하는 디버깅용(?) 버전 같은 것이 있다면, 다운로드 링크 알려주시면 설치 후 사용 하다가 에러 발생시 로그 전달 드리도록 하겠습니다.
이클립스로 작업하실 때 편집창을 몇 개 정도 열어놓고 작업하시나요?
터미널에서.. 아래 명령을 주면 디버깅 메시지가 나옵니다.
export G_MESSAGES_DEBUG=dasom
eclipse | grep dasom_im_new
dasom_im_new
함수가 몇번이나 실행되었는지 알고 싶습니다.
아...이게 그때 그때 다른데요..보통은 10개 미만이고, 가끔 히스토리 볼때만 20개 남짓 정도 입니다. 디버깅 메시지 띄워서 사용 후 다시 말씀 드리겠습니다.
데비안 Jessie, Stretch, 우분투 16.04 에서 재현이 되지 않습니다.
재현 방법을 알려주세요. 그리고,
아래 명령을 하면 숫자가 나올텐데요.. 그걸 좀 알려주세요.
lsof -c dasom-daemon | grep unix | wc -l
아..그럼 제 로컬 개발 환경이 문제인가 보네요...T_T 알려주신 명령으로 사용하면 현재는 620인데요. 어제 다시 띄운후로 아직까지는 괜찮으니, 더 사용해보고 말씀 드리겠습니다.
바쁘실텐데..신경써주셔서 감사합니다( )
소켓이 약 620개 이상 열려 있다는 의미인데 그 정도로 죽지는 않습니다. 아... 죽기 직전에 숫자를 보기가 어렵죠. 나중에 시간날 때 민트와 이클립스를 설치하여 테스트해 보겠습니다. 어딘가에서 소켓이라던가 IPC 라던가 실행 중에 커널 제한을 넘어가는 것 같거든요.
아...회사 PC여서 계속 켜놓고, 이클립스도 끄지 않고, 계속 띄워놓은 상태에서 사용하고 있으니... 말씀하신대로라면, 계속 누적되서 언젠가는 그럴 수 밖에 없지 않나요? 그렇다고 하시면..결국 저의 사용 방식이 원인이겠네요
그렇지는 않고요. 누적되는 방식이 아닙니다. 어딘가에 누수(leak) 버그가 있는 것 같습니다.
원인 파악이 어려우니 이러한 문제를 겪고 계신 분들은 말씀해주세요.
lsof -c dasom-daemon | grep unix | wc -l 이 명령을 1초 단위로 콘솔에 찍도록 돌려놓고 작업 중이었는데, 한 번은 1009까지, 두번은 994까지 찍히고 죽었습니다.
1009에서 죽은 케이스는 이클립스가 아니라, 사내에서 쓰는 이클립스를 기반으로 만들어진 툴을 실행시키다 죽었습니다. (가장 많이 쓰는게, 이클립스와 이 툴입니다. 이클립스는 한번 띄우면 계속 쓰는데 반해서, 이 툴은 필요할때 마다 종료했다가 실행하는 패턴입니다.)
나머지 두번은 이클립스에서 파일을 열다가 죽었습니다.
여태까지는 이클립스에서 작업 중에 죽어서 이클립스와 충돌이 있는 건가 생각했는데, 이클립스와의 문제가 있을거라는 제 생각이 틀렸습니다.
아, dasom-daemon이 죽은 다음에 다시 띄우면 죽기 전에 띄워져 있던 프로그램들에서는 한글 입력이 안되는 현상도 있습니다.
리눅스 민트 17.3 과 eclipse 를 가상 머신이 아닌 물리적인 컴퓨터에 설치하여 테스트를 하였습니다. Test*.java 파일을 20개 생성하였습니다.
lsof | wc -l
60286
lsof | grep unix | wc -l
24759
lsof -c dasom-daemon | grep unix | wc -l
413
이런 값들이 나옵니다. 에러는 발생하지 않았습니다. 재현되지 않습니다. 제 생각엔 사내에서 쓰는 이클립스를 기반으로 만들어진 툴에 누수 버그가 있을 것으로 짐작이 됩니다. 다솜 입력기 버그가 아닙니다.
아, dasom-daemon이 죽은 다음에 다시 띄우면 죽기 전에 띄워져 있던 프로그램들에서는 한글 입력이 안되는 현상도 있습니다.
dasom-daemon 과 통신이 끊겨서 나타나는 이 현상은 버그가 아닙니다. 클라이언트에 재접속을 시도하는 코드를 넣으면 되긴 하지만, 원인을 파악하지 않은 상태에서 재접속하여 사용하는 것은 원인 파악을 더욱 어렵게 하고 또다시 접속이 끊기는 상황이 발생될 것이기 때문입니다.
말씀 드린 툴은 실행시키지 않은 상태에서 바로 위에 있는 명령어들을 터미널에 1초마다 찍히게 한 후
이클립스에서 파일을 계속 열다보니 lsof -c dasom-daemon | grep unix | wc -l 이 명령의 결과값이 1000이 넘으면 죽습니다. 제가 확인한 최대값은 1013 입니다. 보통 한번 열때 10~20 정도 증가하니 1013에서 값을 늘리려다 에러내며 죽는 것 같습니다. 1013 이상에서 가장 익숙한 값은 1024 인데..
커널 설정 어딘가에 1024개로 정해져 있는게 아닌지 의심스럽습니다.
dasomlog.sh :
while true do lsof | wc -l lsof | grep unix | wc -l lsof -c dasom-daemon | grep unix | wc -l echo "===" sleep 1 done
madhwang@madhwang:~/Downloads/temp$ ./dasomlog.sh
...
...
209512 62990
219543 70997
224616 73252
228180 77486
233457 81977
117489 4790
lsof | wc -l
값이 233457 에서 117489 변경된 것으로 보아 dasom-daemon 외에 죽은 프로그램이 더 있을 것으로 보입니다.
다음 명령을 실행하여 결과값을 알려주세요.
ulimit -a
위에서 다솜 외에 죽은 것은 이클립스 입니다. 이클립스에서 파일을 열다가 1013 넘으면서 다솜이 죽는 것과 동시에 이클립스가 죽습니다. 즉, 다솜과 파일 오픈 제한 카운트를 초래한 어플이 죽고, 다른 사용 중인 프로그램들은 이상없이 실행되고 있습니다.
백그라운드로 실행되는 다른 데몬들도 죽었다면...이는 확인할 방법을 모르겠네요^^;;;
core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-i) 47714 max locked memory (kbytes, -l) 64 max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) 47714 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited
실행 결과 입니다.
이거.. open files (-n) 1024 요 값이 문제인거 같은데요? 맞나요?
open files (-n) 1024 이 값이 문제였던 것 같습니다.
http://ithubinfo.blogspot.kr/2013/07/how-to-increase-ulimit-open-file-and.html 여기를 참고해서 저 값을 65535까지 늘린 후 테스트 해보니
lsof -c dasom-daemon | grep unix | wc -l 결과 값이 1156이 넘었음에도 죽지않습니다. 야호!!!~~
이제 마음껏 쓸 수 있겠네요. ^^
덕분에 저도 많이 배웠습니다.
바쁘신 와중에도 시간 내주셔서 정말 감사드립니다.(^0^) ( )
P.S : 이슈는 제가 닫으면 될까요?
일단은 그렇게 사용하시면 될 것 같습니다. im comtext 가 1000개 넘어가는 상황이 없을 것이라 생각했었는데 1000개가 넘어가는 상황이 쉽게 발생하는군요. 추후, 보다 나은 설계를 고려하겠습니다. 이슈는 닫아주시면 되겠습니다. 감사합니다.
님프(Nimf) 입력기는 다솜 입력기를 계승하는 프로젝트입니다. 이클립스를 사용하다보면 님프/다솜 input context 에 연결된 socket 개수가 1024개를 초과하는 경우가 쉽게 발생됩니다. 이는 이클립스에서 쓸데없이 너무 많이 gtk im context 를 생성하기 때문입니다.(이클립스 버그) 현재 님프/다솜 입력기가 im context 당 socket 1개를 사용하도록 되어 있습니다. nimf_im_new() 함수를 호출하면 서버에 소켓으로 접속하는 구조로 되어 있기 때문입니다. 그런데 열린 소켓이 너무 많은 상태가 되면 성능이 저하되므로 클라이언트 프로세스 당 1개의 소켓을 열어서 소켓 1개로 통신을 하는 구조로 변경하는 작업을 하고 있습니다. 이 변경 작업은 까다로워서 오랜 시간을 필요로 하기 때문에 다솜 입력기에는 적용하지 않고 님프 입력기에만 적용하겠습니다. 감사합니다.
안녕하세요( )
아래와 같은 환경에서 dasom 을 사용 중인데요. OS : 리눅스 민트 17.3 x64 개발환경 : 이클립스 4.4.2 jdk8
이클립스에서 작업을 진행하다 보면 가끔씩 아래와 같은 로그를 내뱉으며, dasom-damon을 죽는 것과 동시에 이클립스도 죽어버립니다.
이클립스에서만 그런거 보니, 이클립스 문제로 충돌이 나는 것 같은데, 제 짧은 지식으로는 알 수가 없네요 ^^;;
혹시 충돌을 회피해서 죽는 일 없이 쓸 수 있지 않을까 해서, 이슈 남깁니다. (아이디는 마스킹 처리 했습니다.)
덕분에 너무 잘쓰고 있습니다 감사합니다~~(__)
kern.log Apr 7 12:00:08 ma* kernel: [75479.839016] traps: dasom-daemon[9470] trap int3 ip:7f105b804c13 sp:7ffe57a0c5b0 error:0 Apr 7 12:00:08 ma* kernel: [75479.845001] traps: java[7927] trap int3 ip:7f1d991fcc13 sp:7f1dfceb6f30 error:0
syslog Apr 7 12:00:08 ma* dasom-daemon[9470]: GLib-ERROR : Creating pipes for GWakeup: 열린 파일이 너무 많음 Apr 7 12:00:08 ma* kernel: [75479.839016] traps: dasom-daemon[9470] trap int3 ip:7f105b804c13 sp:7ffe57a0c5b0 error:0 Apr 7 12:00:08 ma* dasom-indicator[9475]: dasom-WARNING : dasom-agent.c:48: on_incoming_message: G_IO_HUP | G_IO_ERR Apr 7 12:00:08 ma* kernel: [75479.845001] traps: java[7927] trap int3 ip:7f1d991fcc13 sp:7f1dfceb6f30 error:0