PC를 한대 업그레이드 하고, 기존에 잘 쓰던 PC에 우분투 리눅스를 설치해서 개발용 빌드머신으로 활용하게 되었습니다. AOSP 마쉬멜로우를 테스트삼아 빌드하는데 시스템이 중간에 알 수 없는 이유로 죽는겁니다.

  1. 한참 컴파일 잘 하다가 시스템의 로드가 높아지면 갑자기 죽음.
  2. make -j2 등으로 시스템의 로드를 낮춰보면 시스템은 거의 죽지 않음.

지금은 문제 없이 잘 사용하고 있어서 위 두가지 항목으로 간단히 정리했지만, 당시에는 당황해서 상당한 삽질했던 것을 생각하면.... 아무튼 기억나는대로 다시 적어보면 다음과 같습니다.

  1. 메모리 문제는 아닌가? - 메모리 테스트 하고, 메모리를 하나씩 빼고 다시 컴파일을 해봄 - 여전히 시스템의 로드가 올라가면 죽음.
  2. 시스템 파워의 문제는 아닌가? - 시스템 파워를 좀 더 새것으로 잠시 교체해봄 - 여전히 죽음
  3. 커널이 맞지 않는가? - 커널을 좀 더 최신으로 바꿔봐도 시스템의 로드가 상당히 올라가면 여전히 죽음.

여기까지 테스트를 하니 벌써 반나절 이상을 소요... 일단 컴파일은 make -j2 등으로 로드를 낮춰서 컴파일을 하였고, 마지막으로 의심이 부분은 CPU 쿨링이었습니다. 쿨러는 사제 쿨러가 아닌 기본 쿨러를 쓰고 있었고, 먼지 청소를 하기 위해서 쿨러를 떼어내다가 서멀 구리스가 일부 제거되어 쿨러와 CPU의 밀착이 잘 되지 않고 있던 상태였던 것을 기억해 내었습니다. 메인보드가 구형이기는 하였지만 자동으로 오버클럭 기능을 제공하는 그러한 기종이었는데 펌웨어도 좀 더 안정성 있다고 써있는 최신으로 업그레이드 하고, 메인보드 모델명으로 검색을 해보니 바이오스에서 자동 오버클럭 기능(?)을 모두 꺼버리라는 내용이 보이더군요. 시스템의 로드가 올라가다가 죽는 현상과도 연관이 있는 것 같아서 이 기능을 끄고, 비교적 저렴한 서멀 구리스를 하나 구입하였습니다. 거의 하루를 이 삽질로 낭비...

몇일 뒤에도 시스템의 로드가 올라가면 여전히 죽는 현상이 있었으나, 배송되어 날아온 서멀구리스를 꼼꼼히 바르고 CPU 재 장착... make -j4 등등의 작업을 하니 그 뒤로는 시스템이 단 한번도 알 수 없는 이유로 죽지 않고 있습니다.

시스템이 알 수 없는 원인으로 죽거나 알 수 없는 오류가 자주 날 때에 살펴보아야 할 것을 나름 정리해보면

  1. 랜덤하게 시스템이 죽는 경우 - 경험상 거의 100% 메모리 문제. 메모리 문제의 경우에는 파일이 알 수 없는 원인으로 랜덤하게 망가지기도 한다.
  2. 랜덤하게 파일이 망가지는 경우 - 시스템이 죽지 않는 경우에도 컴파일 할 때마다 다른 곳에서 랜덤하게 컴파일이 멈추고 오류가 나는 현상도 보이며, 파일이 이상하게 깨지는 경우가 목격된다. - 이 경우도 메모리 문제일 확률이 높은데, 메모리 문제로 추측되면 memory 테스트를 해보라.
  3. 하드디스크가 이상이 있는 경우 - 컴파일시 이상한 지연 현상이 있으며 시스템이 이상하게 한참을 기다린다면 dmesg로 커널 로그를 살펴보자. I/O 오류가 간간히 보이고 하드디스크에서 이상한 끼릭끼릭 소리가 난다면 100% 하드디스크 교체 타이밍. 새 하드 디스크를 사서 신속하게 교체해야 하고, 데이터를 옮겨야 한다. 잘 하면 데이터를 그대로 살릴 수 있다.
  4. 컴퓨터가 어느날 갑자기 부팅이 안될 때 - 이 경우에는 여러가지 원인 일 수 있으나, 일단 HDD등의 기기는 무조건 분리하고 컴퓨터 청소등을 실시해보자. 파워에서 이상한 냄새가 난다거나 하면 파워의 문제일 수 있다. 메인보드의 콘덴서가 모두 정상적인지도 살펴보자. 콘덴서가 부풀어 오르거나 했을 경우는 메인보드 문제. (몇년간 잘 쓰던 컴퓨터가 갑자기 부팅이 안되어 컴퓨터 청소하고 재 연결하고 다시 켜는 과정에서 파워가 갑자기 번쩍 하면서..  메인보드가 타고, HDD도 칩이 타서 모두 날려버린 경험을 했던...ㅠ)


by dumpcookie 2017. 2. 25. 00:21

2009년 구입한 스탠드형 김치냉장고가 갑자기 제대로 작동을 하지 않았다.

김치가 시어져서 이상하다 했더니만 김치냉장고의 문제였던 것.

인터넷에 검색을 해보니 A/S를 인터넷을 통해서 신청할 수 있었고, 곧바로 A/S를 다음날 예약해두었다.

http://www.winiasvc.co.kr (방문 서비스 신청하기)


다음날 김치냉장고를 확인해보니 고장의 원인은 냉매가 순환이 안되고 있었다.

(참고로, 딤채 김치냉장고의 전원을 뺐다가 켜면 6분 정도 뒤에 모터가 가동되기 시작한다)

1. 모터 이상 무 -> 온도가 내려가지 않고 있음

2. 냉매가 없는가?

3. 냉매는 있으나 제대로 순환이 안됨


12만원 정도 든다고 알려주었고, 다음과 같은 조치를 취하고 수리를 마쳤다.

1. 냉매를 모두 뺀다.

2. 배관 진공작업(?? 배관 뚫기)

3. 냉매를 다시 채움

4. 온도가 정상적으로 내려가는지 확인


이와 관련된 내용을 검색해보니 별다른 내용이 검색되지 않길래 간략하게나마 정리하였고, 혹시 김치냉장고가 고장나신 분은 참고하시기 바란다.


※추가: 1개월도 안되어 이사를 한 후에 다시 이상에 생겨서 서비스를 받았고, 냉매를 채워넣고서야 다시 정상 작동하게 되었다. 서비스 받은지 얼마 되지 않아 A/S를 다시 받은 것이라서 비용은 들지 않았다.

by dumpcookie 2016. 11. 8. 10:45

웹버그라고도 불리는 1x1 GIF 이미지파일은 그 크기가 35 바이트 혹은 투명인 경우 43 바이트라고 알고있었습니다. http://www.perlmonks.org/?node_id=7974 (by turnstep이 링크가 원래의 출처이며 http://stackoverflow.com/questions/2933251/code-golf-1x1-black-pixel 링크를 통해 알게된 내용입니다.

그런데 최근 이보다 더 작은 크기의 GIF도 있다는 것을 알게 되었습니다. (다음은 텀블러에서 사용하는 1x1 GIF)


http://www.bignosebird.com/docs/h3.shtml ftp://ftp.bignosebird.com/spacer.gif 이 이미지는 텀블러에서 사용하는 이미지와 약간의 차이가 있으며 42바이트의 최소 크기로 텀블러 GIF 이미지 크기와 동일합니다.


그러면 43바이트 GIF 파일과의 차이점은 무엇일까 궁금해서 살펴보았는데, 두 파일은 다음과 같이 별로 다를 것이 없었고 이미지 마지막 부분의 바이트에 약간의 실수가 있었던 모양이었습니다.


이것이 42바이트의 GIF이미지이고,

0000000: 4749 4638 3961 0100 0100 8000 0000 0000  GIF89a..........
0000010: ffff ff21 f904 0100 0000 002c 0000 0000  ...!.......,....
0000020: 0100 0100 0002 0144 003b                 .......D.;

이것이 43바이트의 GIF이미지입니다.

0000000: 4749 4638 3961 0100 0100 9000 0000 0000  GIF89a..........
0000010: 0000 0021 f904 0510 0000 002c 0000 0000  ...!.......,....
0000020: 0100 0100 0002 0104 0100 3b              ..........;

얼핏 봐서는 거의 차이가 없어보이는데, 마지막쪽의 바이트가 차이가 있음을 볼 수 있습니다.


두 이미지가 정상적인 이미지인지 테스트를 하기위해 테스트를 해보면 두번째 이미지는 giftopnm 프로그램을 사용하였을때에 다음과 같은 경고 메시지가 나오는 것을 알 수 있습니다.

$ giftopnm --verbose 43b.gif giftopnm: GIF format version is '89a' giftopnm: GIF Width = 1 GIF Height = 1 Pixel aspect ratio = 0 (1.000000:1) giftopnm: Colors = 2 Color Resolution = 3 giftopnm: Color map doesn't contain grays, doesn't contain colors giftopnm: got a 'Graphic Control' extension giftopnm: transparent background color: rgb:00/00/00 Index 0 giftopnm: reading 1 by 1 GIF image giftopnm: too much input data, ignoring extra... giftopnm: writing a PBM file P4 1 1

간단히 0x10을 제거하니 위의 경고 오류는 사라지더군요.


호기심이 생겨서 검색을 더 해보니 스택오버플로우에 다음과 같은 링크를 찾을 수 있었다. http://stackoverflow.com/questions/2570633/smallest-filesize-for-transparent-single-pixel-image 질문에 대한 http://stackoverflow.com/a/15960901/1696120 답변 내용에 의하면 가장 작은 크기의 투명 GIF 이미지는 32바이트라고 되어있습니다. 답변을 살펴보면, The Global Color Table can be removed safely by disabling it in the Logical Screen Descriptor라고 되어있는데 즉 Logical Screen Descriptor를 조정해서 Global Color Table을 제거할 수 있다는 내용이 있습니다.


xxd를 이용해서 바이트열로 변환해 살펴보면 다음과 같습니다.


0000000: 4749 4638 3961 0100 0100 0000 0021 f904  GIF89a.......!..
0000010: 0100 0000 002c 0000 0000 0100 0100 0002  .....,..........

이것을 43바이트 GIF 이미지와 쉽게 비교하기 위해 다시 써보면

0000000: 4749 4638 3961 0100 0100 8000 0000 0000  GIF89a..........
0000010: ffff ff21 f904 0100 0000 002c 0000 0000  ...!.......,....
0000020: 0100 0100 0002 0144 003b                 .......D.;

즉 Logical Screen Descriptor 값이 0x00으로 되어있고, Global 컬러 테이블을 없애서 6바이트가 줄어들었습니다. 또한 마지막의 바이트도 삭제되어있는데, 위의 답변 내용에 보면 Only 3 bytes of the LZW data are required and the bytes can be almost anything. Though only the first byte of 0x02 is strictly required. 라고 되어있으며 LZW 데이터인 0x02 이후의 0x10, x44,0x00 3 바이트가 제거되어 있으며, 마지막으로 파일의 끝을 알려주는 0x3b 1바이트 총 4바이트가 제거되어있습니다.


단, 32바이트의 경우에 원문에는 대부분의 브라우저에서 작동한다고 되어있으나, giftopnm 혹은 gifinfo(libgif) 등등의 프로그램으로 테스트할 경우에 오류를 뿜었습니다.

32바이트의 GIF는 http://stackoverflow.com/a/15960901/1696120 에 다음과 같이 나오며, 이는 대부분의 브라우저에서 잘 작동합니다.

GIF 스펙(http://www.w3.org/Graphics/GIF/spec-gif89a.txt)을 보니 GIF89a버전의 경우 옵션으로 처리 가능하므로, GIF스펙상 문제 없는 웹버그는 34바이트까지가 가능합니다.)


http://u229.no/stuff/GIFFormat/ 이 문서에 의하면 몇가지 조정이 가능한 값들이 있는데 예를 들어 delay time 값이 2바이트인데, 이 값을 조정하면 65,536가지의 조합을 만들 수 있습니다. 또한 Background color index가 안쓰이는데, 이 값을 조정하게되면 2^24(16,777,216)개의 조합도 가능합니다. (더 많은 개수의 웹버그 조합이 필요하다면 컬러테이블 6바이트를 추가한 42바이트짜리 GIF를 만들어서 이미지 색상 팔레트값을 임의로 조정하면 될 것입니다.)

웹버그를 만들어주는 간단한 PHP 스크립트를 같이 참고하시기 바랍니다.

<?php
$transparency = 1;
printf("GIF89a\1\0\1\0%c%c\0%s,\0\0\0\0\1\0\1\0\0%s",
0x00 /* packed field */,
0xff /* background color index */,
($transparency ? pack("c8",0x21,0xf9,4,1,0,0,0,0) : ''),
"\2\1\x44\0\x3b"); # LZW data 4 bytes + ";"


by dumpcookie 2015. 10. 16. 10:10
| 1 2 3 4 5 6 7 8 ··· 22 |