GDB에서 인스턴스의 실제 타입 표시하기

Base class로 부터 상속 받은 Derived class의 인스턴스를 Base class 포인터에 넣으면 GDB에서 타입이 제대로 표시되지 않는다. 이 때는 ‘set print object on’을 설정해서 GDB의 ptype <var> 명령 결과에 해당 인스턴스의 실제 타입이 함께 표시 되도록 할 수 있다.

예를 들어 다음과 같은 코드가 있다고 할 때

#include <iostream>
using namespace std;

class Base {
public:
  virtual void identify() {
      cout << "Base class" << endl;
  }
};

class Derived: public Base {
public:
  void identify() override {
      cout << "Derived class" << endl;
  }
};


int main(void) {
  // Derived class instance 이지만
  // GDB에서 Base type으로 표시된다.
  Base *c = new Derived();
  c->identify();

  delete c;
}

main() 함수 내의 “Base *c”를 GDB에서 확인해 보면 실제 인스턴스의 타입과 관련 없이 Base class로 표시된다.

(gdb) ptype c
type = class Base {
  public:
    virtual void identify(void);
} *

실제 인스턴스가 무엇인지 알고 싶다면, set print ojbect on을 설정해서 ptype 결과에 실제 인스턴스가 함께 표시되도록 할 수 있다. ( /* real type = … */)

(gdb) set print object on
(gdb) ptype c
type = /* real type = Derived * */
class Base {
  public:
    virtual void identify(void);
} *

이 설정을 다른 유용한 것들과 함께 ~/.gdbinit에 넣어두면 gdb가 실행될 때 자동으로 설정된다.

$ cat ~/.gdbinit
set print object on
set print pretty on
set print static-members on
set print vtbl on

이시국에 장기 한국행과 비자발적 치팅 데이

준비와 공항도착

복잡한 사내결재 절차와 이민국 허가 끝에 마침내 석달간 한국에서 일해도 된다는 허가를 받고 한국행을 서둘렀다. 페낭에서 한국으로 가는 운행편을 한번에 예약할 수 없어서 페낭에서 쿠알라룸푸르 까지는 말레이시아 항공으로 쿠알라룸푸르에서 인천까지는 대한항공을 예약했는데 밤늦게 11시 20분에 운항하는 단 한대가 그나마도 매일 운행하진 않고 월수금에만 운행하기에 금요일에 하루 휴가를 내야했다.

앞으로 한동안은 차를 안쓸테니 방전을 막기 위해서 자동차 후드를 열고 어딘가에서 읽은대로 배터리의 음극을 빼놓고 수동키로 문을 잠궈 두었다.

페낭에서 KL로 이동하는 것은 CMCO 기간과 달리 공항에서 별다른 경찰 허가서를 요구 하지는 않았는데 페낭 공항에는 생각보다 사람들이 많아서 조금 놀랐다.

내면과의 대화

그렇게 쿠알라룸프르로 향하는 비행기를 타고 이륙을 기다리고 있는데 장이 말을 걸었다. “이봐, 급하게 내보내야 할게 있어” 엄습하는 불안한 마음을 누르며 이 작은 비행기에 화장실이 있는지 승무원에게 물어봤더니 다행히 있다고 한다. 눈을감고 이륙 후 좌석등이 꺼질때 까지 심호흡을 하며 마인드 콘트롤을 시작했다. “인간은 불안할 때 모든 안좋은 감정이 배가 됩니다”라는 아침에 유튜브가 골라준 영상강연에서 들었던 말을 떠올리면서..

좌석등 꺼지는 소리가 나자마자 비행기 꼬리쪽에 있는 화장실로 달려갔는데 아까 내가 화장실을 물어봤던 승무원이 마스크에 가려진 내 급한 표정을 눈치챘는지 화장실 문을 열어준다. 민망했다.

그런데 녀석이 답이 없다. 비행기는 흔들리고 소식은 없고 한 십분올 앉아 있었을까. 누군가 화장실 문을 쾅 쾅 두드리자 모든 의지가 사라졌다. 그냥 나오는데 기다리는 사람은 없고 아까 그 승무원이 괜찮냐고 물어본다. 아 쪽팔려.

짐 분실

어찌어찌 도착해서 짐을 기다리는데 얘도 안나온다. 오늘 뭔 날인가… 만약의 경우를 대비해 가방 안에 넣어뒀던 물품들을 머릿속으로 정리했다. 혹시나 분실되면 얼마만큼의 가치가 있었는지를 말해야 할것 같았기 때문이다. 결국 짐 나오는 벨트가 다 돌아가도록 나오지 않자 그 옆에 있던 공항관계자에게 말했더니 어디론가 한참 무전을 치더니 10여분 만에 어딘가에서 내 케리어를 들고 나타났다.

그리고 나서 공항으로 나오니 5시 30분 가량. 비행기 수속은 8시에나 시작 할테니 시간이 좀 있었다.

공항에서 저녁밥 먹기

KLIA에 도착해서는 시간이 좀 많이 남았다. 저녁 먹을 시간도 다 되고 해서 좀 돌아봤더니 문을 연 가게가 딱 한군데 밖에 없었다. KLIA2에는 문을 연 가게들이 좀 있다는 이야기를 듣고 KL express를 타고 가봤더니 문을 연 가게들이 꽤나 있었다. 버거킹도, 서브웨이 그리고 몇몇 중식당들과 프렌차이즈 식당들이 문을 열었다. 식당들을 돌아본 후에 그 중에 한 곳에 들어갔더니 지금 마감중이라 문을 닫았고 한다. 버거킹에 가봤더니 알바생이 청소를 하고 있길래 문 열었냐고 물어봤더니 그렇다고 해서 주문하러 카운터로 갔더니 아무도 없다. 다른 누군가 나와서 지금 방그 문을 닫았다고 한다. 아마도 오후 6시 전후로해서 다들 문을 닫기 시작하는 모양이었다. 간신히 서브웨이를 찾아서 서브를 하나 포장해서 비상 간식 거리로 챙겨 놓고 다른 문 연곳을 찾아다녀 봤더니 편의점 빼고는 그새 모두들 문을 닫았다.

결국 저녁식사는 의도치 않게 5개월 만에 먹어보는 할랄 신라면과 삼각김밥으로 거하게 치팅을 즐겼다. 그리고 양이 좀 모자랐는지 포장해온 서브 반쪽도 먹어버렸다.

대한항공 수속

KLIA로 다시돌아와서 조금 기다렸더니 8시 무렵이되어 접수카운터가 열렸다. 대한항공과 코드쉐어를 하는 말레이시아 항공의 카운터 직원이 접수를 해줬는데 한국인 지상근무원 한 분이 돌아다니면서 이것저것 봐주는 모양이었다. 내 짐무게 초과가 나오자 $75를 더내야 한다며 계산을 도와주러 내가 접수하는 카운터로 그 직원분이 왔다. 내가 예약한 꼬리좌석을 보더니 일부러 거기에 예약 한거냐고 물어본다. 조용하지 않을까 싶어서 일부러 구석진 자리를 골랐는데 그 말을듣자 뭘 잘못한게 아닐까 하는 생각이 들었다. 다른 자리 비어있냐고 물어봤더니 “많아요” 라며 좌석 하나를 추천해 주셨다. 나쁘지 않은것 같아서 자리를 바꾸고 접수를 마쳤다.

필리핀 근처에 태풍이 있는 모양이다. 항로 변경으로 비행기가 연착 되서 한 30분 정도 탑승수속이 지연 되었다. 이 내용을 설명해 주려고 아까 그 지상근무원이 대기실 앞에 나타나셨는데, 그 말을 듣고 있던 어떤 한국인 아저씨가 “배가 고픈데 김밥 같은거라도 줘야 하는거 아니냐”며 약한 진상을 시전 했다가 앞에 있는 음식점에서 뭐 좀 사드시라는 역공에 간단히 진압 당하셨다.

비행기안에는 타는 사람이 적어서인지 다들 널찍이 자리를 차지하고 나도 비어있는 옆자리를 만끽하면서 편하게 왔다. 코로나 때문에 술과 음료 서비스를 제공하지 않는다는 안내가 나왔는데, 널찍한 자리 덕에 조금도 거리껴지지 않았다.

한국 도착과 득템

인천공항에 도착하자 많은 경찰과 공무원들이 맞이해 주었는데, 잠재적 감염자이므로 정해진 동선대로만 움직이라고 했다. 먼 여행끝에 집에 도착해서 다음날 코로나 검사 받으러 갔더니 국가에서 보급품을 선사해 주었다. 안에는 간식 거리들과 레토르트 식품, 홍삼 등이 들어 있었는데, 잘 챙겨 주셔서 무척 감사했지만 혼자서 자가 격리 하는 사람들은 과연 이걸로 2주 동안 격리가 가능할까 하는 의구심이 들기는 했다.

Lightshail Ubuntu 배포판 업그레이드 후 ssh 접속이 안된다.

망했다! Litghtsail의 Ubuntu 배포판이 너무 오래전 것이라 콘솔에 접근해서 조심스럽게 screen session도 새로 만들어 가면서 업그레이드를 했는데 끝나고 나니 SSH가 안된다. 아마도 중간에 SSH관련 환경설정을 파일을 변경할 것인지 묻는 선택메뉴가 나왔는데, 현재 설정을 그냥 쓰겠다고 했던게 문제인것 같다. 다행히 blogging service는 잘돌아 가고 있지만 SSH가 안되면 서버관리를 할 방법이 없는데…

Workaound

다행히 세상은 생각보다 넓고 인간은 같은 실수를 반복하기에 이전에 같은 실수를 한 사람의 비슷한 경험을 정보의 바다에서 찾을 수 있었다 (SSH stops working after upgrade to Ubuntu 18.04 on AWS Lightsail). 대충 Ubuntu 18.04 LTS로 올라가면서 SSH 환경설정 파일에 변경이 있었는데 메인테이너 버전을 적용하지 않으면 문제가 되는가 보다. 이 포스팅은 위의 링크에 있는 내용을 기준으로 정리한 것이다. (Lightsail 한정이고 EC2를 사용하고 있다면 아래와 같이 번거로운 작업을 할 필요가 없다고 한다)

순서 요약

  1. SSH접속이 안되는 instance로 부터 스냅샷을 하나 만든다.
  2. 스냅샷의 시작 스크립트에 ssh 환경설정을 수정하는 명령어를 넣고 새로운 인스턴스를 만든다.
  3. 잘 되면 새로운 인스턴스를 고정 IP에 연결하고 이전 인스턴스를 지운다.

스냅샷 생성

SSH 접속이 안되는 인스턴스로 부터 스냅샷을 하나 만든다. 관리 -> 스냅샷 수동 스냅샷 아래의 ‘+ 스냅샷 생성’을 클릭.

생성이 완료될 때까지 조금 기다렸다가 이 스냅샷으로 부터 새로운 인스턴스를 하나 만든다.

시작 스크립트를 추가하고 인스턴스를 실행

새 인스턴스 생성 메뉴에 보면 “시작 스크립트”를 넣는 곳이 있는데 이곳을 선택하고 ssh config를 변경해 줄 다음의 sed 명령어를 입력한다.

sudo sed -i 's/^Ciphers .*/Ciphers +aes256-cbc,aes192-cbc,aes128-cbc/' /etc/ssh/sshd_config
sudo service sshd stop
sudo service sshd start

그리고 나서 인스턴스를 실행하면 처음에는 여전히 SSH 접속이 되지 않는데, 꽤 오랜 시간 (10~20분)이 지나고 나서야 가능해 진다.

고정 IP 변경과 정리

네트워킹 -> Static IP에서 고정 IP를 분리하고 새로운 인스턴스에 새로 연결해 준다.

새로운 인스턴스를 고정 IP에 할당 한 후 기존 서버를 끄고 도메인에 접속해서 잘 돌아가는 지 확인한 후 스냅샷과 기존 인스턴스를 지워준다. 스냅샷 생성 기능은 예전에 한 번 백업용으로 좋겠다 싶어서 만들어 봤다가 추가 요금이 나온적이 있다. 🙁

결론

다음 부터는 이미지를 업데이트 하고 싶을 땐 먼저 백업을 만들어서 작업 및 확인하고 최종으로 IP를 변경 하도록 하자.