log 1

shared memory란 서로 다른 process 간에도 memory를 공유하는 것을 의미한다.

이 때 shared memory의 정보(ID, addr 등)는 kernel에서 관리 해 준다.

linux에서는 shared memory의 생성, 삭제, 접근 및 해제 등의 함수가 구현되어 있다.

Description

shmget()은 key값을 통해 shared memory의 id를 얻어오는 함수이다. 이 때, 동일 key로 생성된 shared memory가 없으면 새로 할당하는 것도 가능하다.

Parameter

- key: shared memory의 id를 얻어오기 위해 사용할 key 이다.

- size: 얻어올 shared memory의 크기이다.

- shmflg: shared memory를 얻어올 때 사용할 flag이다. 자주 사용하는 flag는 다음과 같다.

  * IPC_CREATE: key 값에 해당하는 shared memory가 없다면 새로 생성한다. 생성 시에는 권한을 설정 해 주어여 한다.

  * IPC_EXCL: key 값에 해당하는 shared memory가 있다면 실패를 반환한다.

  * 0666: IPC_CREATE시 사용할 권한이다.

Return Value

- success: shared memory의 id를 return한다.

- fail: -1을 return 하며, errno에 error type을 저장해 준다.

Description

shmat()는 shared memory에 attach(가상메모리에 공유메모리 위치할당) 하는 역할을 하는 함수이다.

Parameter

- shmid: 공유 자원으로 사용할 shared memory ID 이다. ID를 통해 각 process 간 동일한 shared memory에 접근할 수 있도록 한다.

- shmaddr:

  * NULL로 설정할 경우, dynamic attach를 하게 되며 kernel에서 가상 메모리 주소를 자동으로 할당하게 된다.

    이 때 주의할 점은 각 process 별 접근하는 실제 메모리 주소는 같지만, 가상 메모리 주소는 각각 다르게 할당된다.

    그렇기 때문에 해당 shared memory 내에서 pointer 사용은 하지 말아야 한다.

  * shmaddr에 주소값을 지정하면, static attach를 하게 되어 가상 메모리상의 shmaddr 위치에 shared memory가 attach 된다.

    만일 shared memory 내에서 pointer를 사용하고 싶을 경우, static attach를 하면 된다.

    단, 이때도 주의할 점은 dynamic attach 후 static attach를 하게 되면 dynamic attach 했던 주소 범위에 static attach를 할 수 있으며,

    그때는 static attach 실패할 수 있으므로, 항상 static attach를 모두 완료한 후에 dynamic attach를 해야 한다.

- shmflag: attach시 사용할 flag이다.

  * SHM_RND : 공유 메모리 주소를 프로세스에 맞게 따로 할당

  * SHM_RDONLY : 공유 메모리를 읽기 전용으로 설정. shmaddr가 NULL이 아닌 경우에만 사용

Retuen value

- success: attach된 가상 메모리상의 주소값이다.

- fail: -1을 return 하며, errno에 error type을 저장해 준다.

Description

shmdt() 는 shared memory에 attach 되어있는 메모리를 detach(virtual memory에서 공유메모리 위치할당 해제) 하는 역할을 수행하는 함수이다.

Parameter

- shmaddr: detach 할 virtual memory 상의 address

Retuen value

- success: return 0

- fail: return -1, errno에 error type 저장

Example

(이세돌이 이겼던 4국의 기보)

세기의 대결인 알파고 vs 이세돌의 대국이 화제입니다.

바둑에도 잠시 몸담았고, 현재 개발자인 저는 당연히(?) 이 대결에 관심을 가지게 되었습니다.

알파고가 봐줬다는 음모론도 있긴 하지만, 글쎄... 라는 생각이 더 많이 듭니다.

1~3국과 다르게, 저의 바둑 수준이 낮아서인듯 한데, 라이브로 볼때는 중앙 접전상황에서의 모양세 자체가 이해가 잘 안되더군요

해설을 맡은 프로기사들도 복잡하다고 생각한 수순이었고, 답이 있을지 찾기 힘들어했습니다.

(대국에서 가장 중요했던 부분. 아직 돌이 많이 올라가 있지 않은데 4군데 정도의 전장이 얽혀있는 엄청나게 복잡한 모양입니다.)

나중에 다시보기로 보니 모양이 좀 보이는데 꽤나 복잡한 수순으로 중앙의 바둑돌이 놓여 있었습니다.

왼쪽 위, 왼쪽 아래, 오른쪽, 중앙이 모두 연관성이 있는 복잡한 싸움입니다. 그래서 프로기사들도 즉시 답을 내진 못했습니다.

돌도 약 80개 정도밖에 올라와 있지 않았기 때문에, 알파고도 연산할 부분이 많았을 듯 합니다.

이후 수순은 이세돌의 묘수로 중앙에서 엄청난 이득을 보게 되고, 알파고의 실수(실수인지 불리함을 타계하려는 방책인지는 모르겠습니다)로 대국이 기울게 됩니다.

딥마인드 개발진 인터뷰 에서도 복잡한 수순에서 이세돌의 묘수가 통했다... 라는것으로 보아

잘 나오지 않을만 하면서도 복잡한 모양이어서 알파고 연산 한계치를 넘은것 같고,그 틈을 이세돌이 잘 비집고 들어온것 같습니다

그게 아니라면 알파고라고 해도 딥러닝으로만 이루어지지 않았을 것이고, 설계를 통해 구현된 알고리즘 부분이 있을 것인데

알파고 개발자들이 바둑에 대한 이해가 낮았고(물론 프로 기사와 대비해 봤을때 입니다), 그때문에 설계상의 오류로 약간의 버그가 생긴것이 아닐까 추측해 봅니다.

특히 불리하다 생각되는 국면 이후의 악수들은 바둑에 대한 근본적 이해가 조금 부족해 보일수 있지 않나 하는 생각마저 듭니다.

딥마인드 개발진 역시 문제를 인식했을듯 합니다

다음 대국까지는 이틀... 아직 시간이 많이 남지 않았습니다.

확실한 버그가 발견되지 않는 이상 알고리즘의 큰 변경은 없을것이라 보여집니다.

(우라나라였으면 개발자들 쪼아서 바로 패치를 냈겠지만...)

다음 대국이 있을지 모르겠지만, 알파고의 다음 버전이 있다면 훨씬 무시무시한 녀석이 나올 것 같네요

objdump의 파일명은 architecture 별로 상이할 수 있으며, 주로 이용되는 사용법은 다음과 같다.

   objdump [-d] [-S] [-l] [obj 파일명] > [output 파일명]

 -d 옵션은 disassemble, 즉 어셈블리어 코드 목록을 생성한다.

 -S 옵션은 소스코드를 최대한 보여주는 옵션이다. optimization 된 object file의 경우 소스코드가 모두 보이지 않을 수 있다.

 -l 옵션은 소스코드에서의 line을 보여주는 옵션이다.

 '> [output 파일명]' 을 하게 되면 파일명으로 export 하게된다. 이를 생략하면 화면에 즉시 출력된다.

objdump는 GNU 바이너리 유틸리티의 일부로서, 라이브러리, 컴파일된 오브젝트 모듈, 공유 오브젝트 파일, 독립 실행파일등의 바이너리 파일들의 정보를 보여주는 프로그램이다. objdump는 ELF 파일을 어셈블리어로 보여주는 역어셈블러로 사용될 수 있다.

[출처] Wikipedia (https://ko.wikipedia.org/wiki/Objdump)

이외에도 아래와 같이 잡다한 기능이 많다.

objdump [-a|--archive-headers] 

        [-b bfdname|--target=bfdname] 
        [-C|--demangle[=style] ] 
        [-d|--disassemble] 
        [-D|--disassemble-all] 
        [-z|--disassemble-zeroes] 
        [-EB|-EL|--endian={big | little }] 
        [-f|--file-headers] 
        [--file-start-context] 
        [-g|--debugging] 
        [-h|--section-headers|--headers] 
        [-i|--info] 
        [-j section|--section=section] 
        [-l|--line-numbers] 
        [-S|--source] 
        [-m machine|--architecture=machine] 
        [-M options|--disassembler-options=options] 
        [-p|--private-headers] 
        [-r|--reloc] 
        [-R|--dynamic-reloc] 
        [-s|--full-contents] 
        [-G|--stabs] 
        [-t|--syms] 
        [-T|--dynamic-syms] 
        [-x|--all-headers] 
        [-w|--wide] 
        [--start-address=address] 
        [--stop-address=address] 
        [--prefix-addresses] 
        [--[no-]show-raw-insn] 
        [--adjust-vma=offset] 
        [-V|--version] 
        [-H|--help] 
        objfile...  

[출처] about.com - linux tech (http://linux.about.com/library/cmd/blcmdl1_objdump.htm)

strcpy의 경우 buffer overflow 가능성 문제 (null termination이 제대로 되어있지 않은경우 buffer를 엄청나게 복사할 수 있는 취약점)

를 회피하기 위해, null을 강제삽입하고 strncpy를 쓰거나, snprintf등을 사용하도록 가이드되곤 한다.

그런데, strcmp의 경우에도 overflow가 발생할 수 있을까 궁금해졌다.

strcmp의 경우 문자열을 비교하게 되는데, 메모리에 써주는 것이 아닌 단순 비교만 하는 경우에도 overflow가 발생할 수 있는지,

그리고 만일 발생한다면 어떻게 해결할 수 있는지가 궁금해졌다.

먼저 구글링을 통해 다음과 같은 토론이 존재함을 알수있었다.

http://stackoverflow.com/questions/24353504/whats-wrong-with-strcmp

토론 내용을 요약해보면,

strncmp가 좀더 낫고, memcmp가 가장 낫다고 한다.

1. 구글 애드센스 가입 (구글계정 가입 -> 블로그 주소입력, 언어설정(한국어) -> 개인정보 입력)

   www.google.co.kr/adsense

2. 애드센스에서 내광고->광고단위->새광고단위 클릭

3. 광고 크기, 유형, 스타일, 맞춤채널, 대체광고 등을 설정 (이름만 넣고 그냥 기본으로 하셔도 돼요~)

4. 생성된 코드 확인! (나중에 코드 가져오기로 가져올 수도 있어요)

5. 광고코드 복사해서 광고넣기

5-1. 광고코드를 skin.html에 넣어서 글 위아래에 나타나게 하는 방법이에요

     - TISTORY관리에서 HTML/CSS 편집에 들어가서 

     - article_rep_desc 를 찾아서 아래나 위에 광고코드를 붙여넣으면 돼요

   - 그럼 이렇게 광고가 나오게 돼요

5-2. 사이드바에 넣는 방법도 있어요

 TISTORY관리 -> 사이드바 -> HTML 배너출력을 사이드바로 이동 -> 사이드바 편집버튼 눌러서 코드 붙여넣기