티스토리 툴바


GIT Manual

OS/리눅스 2012/01/26 23:59
익숙하면 이것만큼 편하고 빠른게 없다.

출처 -  http://dogfeet.github.com/articles/2012/progit.html

'OS > 리눅스' 카테고리의 다른 글

GIT Manual  (0) 2012/01/26
Debianization - 0  (0) 2011/11/06
The art of unix programming  (5) 2011/01/05
CMake 를 이용해보자.  (4) 2010/12/11
coming soon?  (1) 2010/11/26
유용한 vi plugin 을 써봅시다..  (27) 2009/11/20
Posted by 스파게티 코더

트랙백 주소 : http://semtle.tistory.com/trackback/214 관련글 쓰기

댓글을 달아 주세요

Debianization - 0

OS/리눅스 2011/11/06 23:31
우분투 및 데비안, 데비안 계열의 리눅스는 deb 패키지 형식을 따른다.

우분투는 dpkg 를 back-end 로, apt 를 front-end로 사용하여 deb 패키지를 관리하는데
우리는 우리의 hello world 소스를 debianize 하여 deb 형식으로 패키징 할 수 있다. 

deb형식 패키징의 가장 큰 장점은 dependency 관리가 아주 용이하여 소스 빌드시에 아무 걱정없이 
dependency가 있는 패키지들을 자동으로 가져와서 해당 소스를 빌드할 수 있다. 또한 패키지 설치시에도 마찬가지.
단점은 이 dependency tree의 일부가 깨지면 답이 안나온다는 것이긴 하지만.. 그런일은 여간해선 생기지 않는다.

게으름으로 언제 끝날런지는 모르겠지만 시간 날때마다 틈틈히 적어볼 생각이다.
미루다 미루다 이제 결심을 했는데 귀차니즘으로 포기할지도 몰라서 일단 다짐을 적어본다 ㅋㅋ 

참고사이트 - http://www.debian.org/doc/  

'OS > 리눅스' 카테고리의 다른 글

GIT Manual  (0) 2012/01/26
Debianization - 0  (0) 2011/11/06
The art of unix programming  (5) 2011/01/05
CMake 를 이용해보자.  (4) 2010/12/11
coming soon?  (1) 2010/11/26
유용한 vi plugin 을 써봅시다..  (27) 2009/11/20
Posted by 스파게티 코더

트랙백 주소 : http://semtle.tistory.com/trackback/213 관련글 쓰기

댓글을 달아 주세요

오래전부터 해오던 생각인데..

1. 테스터들이 테스트하는 것을은 어플리케이션.

2-1. bug들을 발견하여 리포트하면 어플리케이션 개발자들은 그것을 분석. 
"이것이 과연 어플리케이션 자체의 문제인가, 아니면 플랫폼의 문제인가"
어플리케이션의 문제라면 수정 돌입.

2-2. 플랫폼의 문제라면 해당 모듈의 플랫폼 개발자에게 리포트.
플랫폼 개발자와 어플리케이션 개발자의 
당신잘못 내잘못 밀고 당기기 싸움.
결국 플랫폼의 문제로 밝혀져 수정 돌입.

3. 다시 1로 돌아가 테스트.

이 루틴에서 만약 플랫폼의 문제라면 상당한 시간이 걸린다.
특히 2-1과 2-2단계에서 문제 분석 및 밀고 당기기싸움에서 굉장한 bottle neck. 

이 비효율성을 개선할 수 있는 방안이 무엇일까?
지금의 프로세스에서는 답이 나오질 않아.. 

'삶, 생각, 느낌.' 카테고리의 다른 글

개발의 비효율성  (3) 2011/09/20
지름신 강림..#2  (6) 2010/12/31
지름신 강림..#1  (0) 2010/12/31
소개팅에 대한 고찰.  (3) 2010/11/18
내가 짠 코드가 과연..  (2) 2010/11/17
shape of my heart  (0) 2010/10/10
Posted by 스파게티 코더

트랙백 주소 : http://semtle.tistory.com/trackback/212 관련글 쓰기

댓글을 달아 주세요

  1. 빠바 2011/09/23 09:37  댓글주소  수정/삭제  댓글쓰기

    멀 고민하시나요 ㅋ 테스터, 어플개발자, 플렛폼 개발자가 모두 한명이면 해결~

    삼위일체의 아름다움이란..... ㅋㅋㅋㅋㅋㅋ

  2. 재철꾸러기 2011/09/29 15:20  댓글주소  수정/삭제  댓글쓰기

    니가 상무되서 바꿔 쓰잘대 없는 고민은-_- 걍 시키는거만해 우리는 로봇

오늘 같이 일하는 인도의 coworker의 코드를 리뷰를 했다.

coworker가 도저히 이해가 안되는 현상이 발생한다며..
지역변수로 선언된 한 구조체를 잘 사용하다가 어느순간 NULL 이 된다는 것이었다.
코드를 보내보라고 해서 리뷰를 시작하다가 이상한 부분을 발견..

대략 아래와 같은 flow를 가지는 코드였다.

 
#include <stdio.h>
#include <malloc.h>
#include <string.h>

void getstr(char* str)
{
    str = (char *)malloc(6);
    strncpy(str, "aaaaa", 6); 
    return;
}

int main(int argc, char** argv)
{
    int a = 1;
    int b = 2;
    int c = 3;
    char* str = NULL;

    getstr(str);
    memset(&str, 0x00, 6); 

    return 0;

}

위 코드를 보면 알겠지만,
함부로 포인터를 가지고 놀다가 stack 영역이 깨져버린 것이었다.(stack smashing detected!! ㅋㅋ)

아 ㅅㅂ.. (이걸 어떻게 영어로 설명하지? 라는 두려움 때문에 ㅋㅋ)
coworker 에게 설명을 했다.


me : If you want to work this code correctly, you should use double-pointer argument in getstr() function.
str in getstr and str in main have different values.

coworker: no. it is same. it is pointer.

me: No.. (아.. 이녀석을 어찌하나요....)
And, why input the address of str to memset as its argument? it is strange..
(아마도 이녀석이 뭔가 안되니까 &를 붙여보기도 한것 같다 ㅋㅋ)




이상황은 뭔가 복합적인 무지로 인하여 발생한 문제지만..

pointer를 가지고 call-by-reference를 이용하고자 한다면 조심스럽게 생각해야한다.
우리의 coworker는 경솔히 생각하고 사용한 좋은 예이다.

pointer를 막연하게 어떠한것을 가리키는 것이라고 생각하지 말고 확실하게 생각하자.
"주소값을 가져야하는, int 나 char와 똑같이 다루어야 하는 데이터형"

과연 우리의 coworker는 내 말뜻을 이해하고 수정된 코드를 보여줄 것인가..

'프로그래밍 > C/C++' 카테고리의 다른 글

pointer와 call-by-reference  (1) 2011/08/03
난제에 빠지다..  (10) 2011/07/26
extern 과 global variable  (0) 2010/11/25
함수 포인터에 대한 대략적 고찰.  (6) 2010/09/28
C에서 Regular expression 사용하기  (4) 2010/09/19
보기편한 코딩 글꼴  (11) 2009/12/01
Posted by 스파게티 코더

트랙백 주소 : http://semtle.tistory.com/trackback/211 관련글 쓰기

댓글을 달아 주세요

  1. chpie 2011/08/12 09:27  댓글주소  수정/삭제  댓글쓰기

    이런놈은 때려야죠 퍽퍽 ㅋㅋㅋ

6개월만의 포스팅..

그간 GIT라든지 Cmake 관련 글을 썼었는데 임시저장된게 날아가 버리면서..
포스팅에 회의를 느꼈었는데.. ㅋㅋ

일단 다음의 코드를 보자.
 
#include <stdio.h>
#include <malloc.h>

int main()
{

    void* a = NULL;
    a = (void*)malloc(17);
    return 0;
}


위 코드에서 a의 실제 크기인 17을 구할 수 있는 방법은??

general 한 list 라이브러리를 나름대로 구현하고 있는데, 간단한 문제에서 막혀버렸다.
사용자가 구조체를 넣든 문자열을 넣든 "aaaa" 와 같은 const 한 문자열을 넣든지간에
void 포인터로 받아서 내부에서 유지하는 구조체에 memcpy를 해야하는데..

문제는 사용자가 argument 로 넣는 포인터가 가리키고 있는 실제 데이터의 크기를 모른다는 것이다!
libc 쪽 메모리 할당 매커니즘을 파고들면 뭔가 꽁수가 나오겠지만.. 귀찮다.

코딩 덕후들이여 나에게 힘을 주세요!

'프로그래밍 > C/C++' 카테고리의 다른 글

pointer와 call-by-reference  (1) 2011/08/03
난제에 빠지다..  (10) 2011/07/26
extern 과 global variable  (0) 2010/11/25
함수 포인터에 대한 대략적 고찰.  (6) 2010/09/28
C에서 Regular expression 사용하기  (4) 2010/09/19
보기편한 코딩 글꼴  (11) 2009/12/01
Posted by 스파게티 코더

트랙백 주소 : http://semtle.tistory.com/trackback/210 관련글 쓰기

댓글을 달아 주세요

  1. 빠바 2011/07/27 08:42  댓글주소  수정/삭제  댓글쓰기

    strlen으로 체크하면 될줄 알았는데, 그렇게 하면 전체 크기가 아니라 str이 들어 있는 사이즈만 나오네요 -_-;;;

    그냥 길이도 같이 가지고 다니는게 속 편할거 같은데요 ㅋㅋㅋ

  2. chpie 2011/07/27 09:43  댓글주소  수정/삭제  댓글쓰기

    malloc_usable_size()
    정확한 실제 크기와 다를 수 있습니다, 할당 자체는 멜렄함수 마음이므로? ㅋㅋ

    • 스파게티 코더 2011/07/27 13:02  댓글주소  수정/삭제

      그것도 사용해봤었는데 몇바이트씩 더 붙더라고.. 정확한 값이 아니야ㅠ

    • chpie 2011/07/29 14:45  댓글주소  수정/삭제

      해당 함수는 libc malloc 의 청크 헤더값에 있는 정보를 뿌려주는 함수일텐데, 몇바이트씩 더 붙는건 어쩔수가 없네요, 할당된 메모리 자체를 리턴하는 것이니 음..

      그렇다면 LD_PRELOAD 를 이용해서 malloc 을 래핑하는 함수를 만든다면??

      --- 추가 고민하여 붙임 ㅋㅋ --

      malloc_usable_size() 의 반환값은 malloc(x) 를 요청한 x 보다 무조건 크거나 같은 값을 가지는 것이 보장되어 있으므로, 사용하는데 문제가 없어보여요.

      리스트데이터에 memcpy() 를 할 시에도 malloc_usable_size() - x 에 대한 남는 공간은 그저 비어있는 데이터일 뿐이니 괜찮지 않을까요?

      이런 경우에도 안전한 것이
      ptr = malloc(x) -> pushlist(ptr) -> secondptr = malloc(malloc_usable_size(ptr))
      을 했을 경우에도
      malloc_usable_size(secondptr) == malloc_usable_size(ptr) 이니까 더이상 메모리 릭이 발생하지 않을 것 같음.. (libc malloc alignment 에 의해)


      libc malloc 에서 뽑아낼 수 있는 정보가 저것이 최선이니 어쩔수 없어 보여요.

      그냥 제시임.. ㅎㅎ


      ---- 또 고민해서 변태같은 상황 발견 ----

      1. char * ptr = malloc(10) 인데 만약 16 이 되었따
      2. malloc_usable_size(ptr) 에 의해 내부에서 16으로 할당하여 저장하였다.
      3. 사용자가 ptr 에 저장했떤 내용을 담아달라고 요청한다.
      4. 리스트 pop 함수가 ptr 에 malloc_usable_size() 만큼을 복사해준다 (16바이트)
      5. 힙 오버플로우 발생 (이라고 프로그래머는 예측한다)
      6. 하지만 실제로 malloc(10) 은 malloc(16) 이되어 있으므로, 내부적으로 안전하며 힙 오버플로우는 존재하지 않는다. (다만 런타임 디버깅 시에 potential 힙 오버플로로 탐지할 수 있을것 같음)

      ---- 가정에 대한 실험 ----

      위에 있는 의견은 근본적으로 malloc_usable_size(malloc(x)) 와 malloc_usable_size(malloc(malloc_usable_size(malloc(x)))) 의 값이 같다는 가정에 의한 것이므로 시험을 진행.

      #include <stdio.h>
      #include <malloc.h>

      int main()
      {
      int i;

      for (i = 0; i < 0x70000000; i++)
      {
      void * a = malloc(i);
      void * b = NULL;
      size_t memsize = malloc_usable_size(a);
      b = malloc(memsize);

      if (malloc_usable_size(b) == memsize)
      printf("%d pass\n", i);
      else
      {
      printf("%d fail\n", i);
      return 0;
      }

      free(a);
      free(b);
      }

      return 0;
      }

      으로 검사.

      결과 : 0x1FFF4(301060) 에서 fail 발생
      이므로 사용할 수 없음 ㅠ.ㅠ

      결론 :
      첫번째 방법으로는 malloc_usable_size() 를 이용하려면 리스트 내내부에서 보관을 위한 장소를 memcpy() 하기 전에 미리 malloc_usable_size() 를 이용하여 malloc(malloc_usable_size()) 와 값이 다른지 판단하여 malloc_usable_size - i 로 원하는 원본 값을 찾아 할당하기. (런타임 시간 소모)

      두번째 방법으로는 malloc_usable_size() 값을 리스트 내부에 저장하여 memcpy() 시에 리스트 내부에 저장된 사이즈를 사용하는 방법. (메모리 공간 추가 소모)

      최종 결론 : 나중에 리스트 만들때 써먹어야징 ㅋㅋㅋ

  3. 스파게티 코더 2011/07/29 23:49  댓글주소  수정/삭제  댓글쓰기

    ㅇㅇ두번째 방법인, size를 내부 구조체 필드에 추가해서 해결은 했다.
    다음과 같은 테스트 프로그램을 돌린결과, 정상적으로 처리됨을 확인.

    =================================================================
    #include <mylist_common.h>

    typedef struct _Temp1
    {
    int a;
    int b;
    } Temp1;

    typedef struct _Temp2
    {
    char a;
    char b;
    } Temp2;

    typedef struct _Temp3
    {
    char* str;
    } Temp3;

    int main()
    {
    slist_handle h1;

    Temp1* t1 = NULL;
    Temp1* t2 = NULL;

    Temp2* t3 = NULL;
    Temp2* t4 = NULL;

    Temp3* t5 = NULL;

    Temp1* get1 = NULL;
    Temp2* get2 = NULL;
    Temp3* get3 = NULL;


    t1 = (Temp1 *)malloc(sizeof(Temp1));
    t1->a = 1111;
    t1->b = 2222;

    t2 = (Temp1 *)malloc(sizeof(Temp1));
    t2->a = 3333;
    t2->b = 4444;

    t3 = (Temp2 *)malloc(sizeof(Temp2));
    t3->a = 'a';
    t3->b = 'b';

    t4 = (Temp2 *)malloc(sizeof(Temp2));
    t4->a = 'c';
    t4->b = 'd';

    t5 = (Temp3 *)malloc(sizeof(Temp3));
    t5->str = (char*)malloc(10);
    strncpy(t5->str, "abcdefg", 9);

    h1 = slist_init();

    slist_insert(h1, t1);
    slist_insert(h1, t2);
    slist_insert(h1, t3);
    slist_insert(h1, t4);
    slist_insert(h1, t5);

    get1 = slist_nth(h1, 0);
    printf("%d, %d\n", get1->a, get1->b);

    get1 = slist_nth(h1, 1);
    printf("%d, %d\n", get1->a, get1->b);

    get2 = slist_nth(h1, 2);
    printf("%c, %c\n", get2->a, get2->b);

    get2 = slist_nth(h1, 3);
    printf("%c, %c\n", get2->a, get2->b);

    get3 = slist_nth(h1, 4);
    printf("%s\n", get3->str);

    slist_free(h1);

    return 0;
    }
    =================================================================


    음 근데 또다른 문제에 직면했다.

    slist_insert(h1, "aaaaaaaaaaaa");

    와 같이 리터럴 문자열을 집어넣을 경우엔..
    저건 heap이 아니라 text segment에 잡혀서,
    세그폴트가 발생해.. ㅅㅂ

    text segment는 code 영역이니까, heap 영역과 메모리 어드레스 다를거고,
    메모리 주소 차이로 구분을 할까..?

    고민을 더 해야할듯..

    • chpie 2011/07/30 11:29  댓글주소  수정/삭제

      컥.. 생각치 못한 반전이다 /
      유니버셜 리스트는 구현하기 힘들군요 저걸 어떻게 beautiful 하게 처리하지.. 음..

      좀 생각해보니까 저게 적당히 처리하는건 안되는 것 같아요

      막말로 slist_insert(h1, L"abcdd");
      같은 형식의 바이너리 데이터도 삽입이 가능한데 그럼
      strlen() 으로는 사이즈를 알아낼 수 없는 형태잖아요
      malloc() 이야 청크헤더가 있어서 사이즈에 대한 정보가 유지되지만, 저것에 대한 크기 정보는 어디에서 얻어야 할지 모르겠어요

      리스트 내부에서는 wcslen 인지 strlen 인지 알 수 있는 길도 없고 음..

      C++을 써서 (LIST_ENTRY, LPVOID) 와 (LIST_ENTRY, LPVOID, SIZE_T) 를 구분해 주어야 하지 않을까요?

    • 스파게티 코더 2011/07/30 12:34  댓글주소  수정/삭제

      general 하게 짜려다 보니까 beautiful 한 코드가 나오기 힘들어..
      switch-case 로 누더기처럼 바르다간 very ugly 한 코드가 나올꺼야.

      제일 아름다운 방법은 걍 내가 policy를 세우는거지 ㅋㅋ

      memcpy 하지말고 그냥 대충 포인터만 set/get 하고,
      "이 리스트에 집어넣은 데이터가 다른 scope에서
      free되면 리스트에 있는 데이터도 free됩니다." 라고 명시하는거야.

      다른 오픈소스들은 어떤 정책을 가지고 처리하는지 한번 살펴볼 필요가 있다.
      Just for fun 으로 시작했는데 아놔 ㅋㅋ

  4. 박상구 2011/07/31 09:04  댓글주소  수정/삭제  댓글쓰기

    이런 덕후들. 쩌는구나.ㅋㅋ