|
1 | | -# runtime-errors-emulator |
| 1 | +# Runtime Error Emulator |
| 2 | + |
| 3 | +Este projeto é um ambiente controlado para simular e estudar diferentes tipos de erros de programação em C++, como `Segmentation Fault`, `Stack Overflow`, `Deadlock`, entre outros. Ele utiliza Docker para criar um ambiente de execução isolado e consistente. |
| 4 | + |
| 5 | +O emulador pode ser usado de duas formas principais: |
| 6 | + |
| 7 | +1. **Modo Script (Host):** Um script no seu computador que lança um contêiner descartável para cada erro. |
| 8 | +2. **Modo Interativo (Contêiner):** Um contêiner que, ao ser iniciado, apresenta um menu para você escolher qual erro simular internamente. |
| 9 | +3. **Modo Automatizado (All-in-One):** O método mais simples e recomendado. Um único script (run.sh) constrói a imagem e executa o contêiner com todas as configurações necessárias. |
| 10 | + |
| 11 | +----- |
| 12 | + |
| 13 | +## Pré-requisitos |
| 14 | + |
| 15 | + * [Docker](https://www.docker.com/products/docker-desktop/) instalado e em execução. |
| 16 | + * Um ambiente de terminal compatível com `bash`. |
| 17 | + * `git` para clonar o repositório. |
| 18 | + |
| 19 | +----- |
| 20 | + |
| 21 | +## Construção das Imagens |
| 22 | + |
| 23 | +Antes de executar, você precisa construir a imagem Docker. Escolha o modo de operação que deseja usar. |
| 24 | + |
| 25 | +### Modo 1: Script no Host |
| 26 | + |
| 27 | +Esta imagem contém apenas os programas compilados. O script `error_emulator.sh` no seu computador irá gerenciá-la. |
| 28 | + |
| 29 | +```bash |
| 30 | +docker build -t meus-programas-cpp . |
| 31 | +``` |
| 32 | + |
| 33 | +*(Este comando usa o `Dockerfile` padrão)* |
| 34 | + |
| 35 | +### Modo 2: Menu Interativo no Contêiner |
| 36 | + |
| 37 | +Esta imagem contém os programas compilados e também o script de menu, que é definido como o ponto de entrada principal. |
| 38 | + |
| 39 | +```bash |
| 40 | +# este comando usa o Dockerfile.emulator para criar a imagem completa |
| 41 | +docker build -f Dockerfile.emulator -t error_emulator . |
| 42 | +``` |
| 43 | + |
| 44 | +*(Note que usamos `-f Dockerfile.emulator` para especificar o arquivo de build)* |
| 45 | + |
| 46 | +----- |
| 47 | + |
| 48 | +## Execução e Uso |
| 49 | + |
| 50 | +### Modo 1: Usando o Script no Host |
| 51 | + |
| 52 | +Este modo é ideal para executar erros específicos de forma rápida e isolada, sem o menu. |
| 53 | + |
| 54 | +1. **Execute o erro desejado:** |
| 55 | + ```bash |
| 56 | + docker run --rm -it error_emulator ./deadlock |
| 57 | + ``` |
| 58 | + *(Substitua `./deadlock` pelo executável do erro que deseja testar)* |
| 59 | + |
| 60 | +### Modo 2: Usando o Menu Interativo no Contêiner |
| 61 | +Este modo é para quem deseja iniciar o contêiner manualmente. É útil para entender os passos que o script `run.sh` automatiza. |
| 62 | + |
| 63 | +1. **Inicie o contêiner com as configurações necessárias:** |
| 64 | + ```bash |
| 65 | + docker run -it --rm --privileged error_emulator bash -c "echo 'core' > /proc/sys/kernel/core_pattern && ulimit -c unlimited && ./emulator.sh" |
| 66 | + ``` |
| 67 | + Este comando longo é necessário para: |
| 68 | + * `--privileged`: Dar permissão para alterar configurações do sistema. |
| 69 | + * `echo ...`: Configurar onde o `core dump` será salvo. |
| 70 | + * `ulimit ...`: Permitir a criação de `core dumps`. |
| 71 | + * `./emulator.sh`: Iniciar o menu. |
| 72 | + |
| 73 | + O menu aparecerá imediatamente, sendo executado de dentro do próprio contêiner. Para parar a simulação e o contêiner, escolha a opção `q` no menu. |
| 74 | + |
| 75 | +----- |
| 76 | + |
| 77 | +### Modo 3: Fluxo de Trabalho Automatizado (All-in-One) |
| 78 | + |
| 79 | +Este modo é a forma mais simples e profissional de executar a demonstração completa de erros que exigem permissões especiais, como o `core_dumped`. Ele automatiza a construção e a execução do contêiner, além da configuração interna necessária, em um único comando. |
| 80 | + |
| 81 | +#### O Script "run.sh" |
| 82 | + |
| 83 | +O script `run.sh` automatiza todo o processo: |
| 84 | + |
| 85 | +```bash |
| 86 | +# este é o script que automatiza todo o processo. |
| 87 | +
|
| 88 | +# --- etapa 1: Construir a Imagem Docker --- |
| 89 | +# o script primeiro garante que a imagem 'emulator' está construída e atualizada. |
| 90 | +echo "--> Etapa 1/2: Construindo/Verificando a imagem Docker 'emulator'..." |
| 91 | +docker build -f Dockerfile.emulator -t error_emulator . > /dev/null |
| 92 | +
|
| 93 | +# verifica se a construção da imagem falhou |
| 94 | +if [ $? -ne 0 ]; then |
| 95 | + echo "ERRO: A construção da imagem Docker falhou. Abortando." |
| 96 | + exit 1 |
| 97 | +fi |
| 98 | +
|
| 99 | +# --- etapa 2: executar o contêiner com todos os comandos necessários --- |
| 100 | +# agora, ele inicia o contêiner e passa uma única "super-string" de comandos |
| 101 | +# para serem executados lá dentro, em ordem. |
| 102 | +echo "--> Etapa 2/2: Iniciando o contêiner e o emulador..." |
| 103 | +docker run -it --rm --privileged error_emulator bash -c " \ |
| 104 | + echo 'core' > /proc/sys/kernel/core_pattern && \ |
| 105 | + ulimit -c unlimited && \ |
| 106 | + ./emulator.sh \ |
| 107 | +" |
| 108 | +
|
| 109 | +echo "--> Emulador finalizado." |
| 110 | +``` |
| 111 | + |
| 112 | +#### Como Usar este Modo |
| 113 | + |
| 114 | +1. Dê permissão de execução ao script `run.sh` e `emulator.sh`: `chmod +x run.sh && chmod +x emulator.sh` |
| 115 | +2. Execute o script para rodar o contêiner: `./run.sh` |
| 116 | + |
| 117 | +#### Verificação do Core Dump |
| 118 | + |
| 119 | +Para verificar a criação do arquivo `core` após a falha, siga estes passos em um segundo terminal: |
| 120 | + |
| 121 | + * Liste os contêineres em execução: `docker ps` |
| 122 | + * Pegue o ID do seu contêiner. |
| 123 | + * Entre no contêiner usando o ID obtido: `docker exec -it <ID_DO_CONTAINER> bash` |
| 124 | + * Dentro do contêiner, verifique a existência do arquivo `core`: `ls core` |
| 125 | + |
| 126 | +----- |
| 127 | + |
| 128 | +## Contribuições da Equipe |
| 129 | + |
| 130 | +Este projeto foi desenvolvido em equipe, com as seguintes responsabilidades: |
| 131 | + |
| 132 | +* **Rauana Carvalho:** |
| 133 | + * Implementação do `buffer_overflow` |
| 134 | + * Implementação do `core_dumped` |
| 135 | + * Implementação do `deadlock` |
| 136 | + * Criação do script de automação (`run.sh`) |
| 137 | + * Elaboração da documentação (`README.md`) |
| 138 | + |
| 139 | +* **Luís Eduardo Rocha:** |
| 140 | + * Implementação do `memory_leak` |
| 141 | + * Implementação do `race_condition` |
| 142 | + * Implementação do `stack_overflow` |
| 143 | + * Criação do repositório no GitHub |
| 144 | + |
| 145 | +* **Rômulo Duarte:** |
| 146 | + * Implementação do `segmentation_fault` |
| 147 | + * Estruturação de pastas do projeto |
| 148 | + * Configuração do ambiente Docker (`Dockerfile`) |
| 149 | + * Criação do menu |
| 150 | + |
| 151 | +* **Luís & Rômulo:** |
| 152 | + * Configuração do pipeline de CI/CD (GitHub Actions e AWS) |
0 commit comments