Unreleased Resource

O programa talvez não consiga liberar um recurso do sistema.

O programa talvez não consiga liberar um recurso do sistema.

Vazamento de recursos têm pelo menos duas causas comuns:

- Condições de erro e outras circunstâncias excepcionais.

- Confusão acerca de qual parte do programa é responsável pela liberação do recurso.

A maioria dos problemas de recursos não liberados resulta em problemas gerais de confiabilidade de software. No entanto, se um invasor puder provocar intencionalmente um vazamento de recursos, talvez ele consiga lançar um ataque de negação de serviço esgotando o pool de recursos.

Exemplo 1: O método a seguir nunca fecha o identificador de arquivo que ele abre. O método Finalize() para StreamReader chama Close() eventualmente, mas não há nenhuma garantia de quanto tempo será necessário antes que o método Finalize() seja invocado. Na verdade, não há nenhuma garantia de que Finalize() nunca será invocado. Em um ambiente muito ativo, isso pode fazer com que a VM use todos os seus identificadores de arquivo disponíveis.

private void processFile(string fName) {
	StreamWriter sw = new StreamWriter(fName);
	string line;
	while ((line = sr.ReadLine()) != null)
		processLine(line);
}

Exemplo 2: Em condições normais, o código a seguir executa uma consulta de banco de dados, processa os resultados retornados pelo banco de dados e fecha o objeto SqlConnection alocado. Porém, se ocorrer uma exceção durante a execução do SQL ou o processamento dos resultados, o objeto SqlConnection não será fechado. Se isso acontecer com frequência suficiente, o banco de dados ficará sem cursores disponíveis e não poderá executar mais consultas SQL.

        ...
	SqlConnection conn = new SqlConnection(connString);
	SqlCommand cmd = new SqlCommand(queryString);
	cmd.Connection = conn;
	conn.Open();
	SqlDataReader rdr = cmd.ExecuteReader();
	HarvestResults(rdr);
	conn.Connection.Close();
	...

O programa talvez não consiga liberar um recurso do sistema.

O programa talvez não consiga liberar um recurso do sistema.

Vazamento de recursos têm pelo menos duas causas comuns:

- Condições de erro e outras circunstâncias excepcionais.

- Confusão acerca de qual parte do programa é responsável pela liberação do recurso.

A maioria dos problemas de recursos não liberados resulta em problemas gerais de confiabilidade de software. No entanto, se um invasor puder provocar intencionalmente um vazamento de recursos, talvez ele consiga lançar uma negação de serviço esgotando o pool de recursos.

Exemplo 1: A função a seguir não fecha o identificador de arquivo que ela abre quando um erro ocorre. Se o processo durar muito, ele poderá ficar sem identificadores de arquivo.

int decodeFile(char* fName)
{
    char buf[BUF_SZ];
    FILE* f = fopen(fName, "r");

    if (!f) {
        printf("cannot open %s\n", fName);
        return DECODE_FAIL;
    } else {
        while (fgets(buf, BUF_SZ, f)) {
            if (!checkChecksum(buf)) {
              return DECODE_FAIL;
            } else {
              decodeBlock(buf);
            }
        }
    }
    fclose(f);
    return DECODE_SUCCESS;
}

O programa talvez não consiga liberar um recurso do sistema.

O programa talvez não consiga liberar um recurso do sistema.

Os vazamentos de recursos têm pelo menos duas causas comuns:

- Condições de erro e outras circunstâncias excepcionais.

- Confusão sobre qual parte do programa é responsável pela liberação do recurso.

A maioria dos problemas de recursos não liberados resulta em problemas gerais de confiabilidade de software. No entanto, se um invasor puder provocar intencionalmente um vazamento de recursos, talvez ele inicie um denial of service esgotando o pool de recursos.

Exemplo 1: O programa a seguir não fecha o identificador de arquivo que ele abre se ocorrer um erro. Se o processo durar muito, ele poderá ficar sem identificadores de arquivo.

  CALL "CBL_CREATE_FILE"
      USING filename
            access-mode
            deny-mode
            device
            file-handle
  END-CALL

  IF return-code NOT = 0
      DISPLAY "Error!"
      GOBACK
  ELSE
      PERFORM write-data
      IF ws-status-code NOT = 0
          DISPLAY "Error!"
          GOBACK
      ELSE
           DISPLAY "Success!"
      END-IF
  END-IF

  CALL "CBL_CLOSE_FILE"
      USING file-handle
  END-CALL

  GOBACK
  .

O programa talvez não consiga liberar um recurso do sistema.

Os vazamentos de recursos têm pelo menos duas causas comuns:

- Condições de erro e outras circunstâncias excepcionais.

- Confusão acerca de qual parte do programa é responsável pela liberação do recurso.

A maioria dos problemas de recursos não liberados resulta em problemas gerais de confiabilidade de software. No entanto, se um invasor puder provocar intencionalmente um vazamento de recursos, talvez ele consiga lançar um ataque de negação de serviço esgotando o pool de recursos.

Exemplo 1: O método a seguir nunca fecha o soquete que ele abre. A função New() estabelece uma nova conexão com o daemon de log do sistema. Faz parte do pacote log.syslog. Cada gravação para o gravador retornado envia uma mensagem de log com a prioridade fornecida (uma combinação do recurso e gravidade do syslog) e a tag de prefixo. Em um ambiente ocupado, isso pode fazer com que o sistema use todos os seus soquetes.

func TestNew() {

	s, err := New(syslog.LOG_INFO|syslog.LOG_USER, "the_tag")
	if err != nil {
		if err.Error() == "Unix syslog delivery error" {
			fmt.Println("skipping: syslogd not running")
		}
		fmt.Println("New() failed: %s", err)
	}
}

Exemplo 2: Nesse exemplo, o método Dial() do pacote net/smtp retorna um novo cliente conectado a um servidor SMTP no localhost. Os recursos de conexão são alocados, mas nunca são liberados chamando a função Close().

	func testDial() {
	   client, _ := smtp.Dial("127.0.0.1")
	   client.Hello("")
	}

O programa talvez não consiga liberar um recurso do sistema.

O programa talvez não consiga liberar um recurso do sistema.

Vazamento de recursos têm pelo menos duas causas comuns:

- Condições de erro e outras circunstâncias excepcionais.

- Confusão acerca de qual parte do programa é responsável pela liberação do recurso.

A maioria dos problemas de recursos não liberados resulta em problemas gerais de confiabilidade de software. No entanto, se um invasor puder provocar intencionalmente um vazamento de recursos, talvez ele consiga lançar uma negação de serviço esgotando o pool de recursos.

Exemplo 1: A função a seguir não fecha o identificador de arquivo, mas o abre. Se o processo for de longa duração, poderão faltar identificadores de arquivo.

BEGIN
...
  F1 := UTL_FILE.FOPEN('user_dir','u12345.tmp','R',256);
  UTL_FILE.GET_LINE(F1,V1,32767);
...
END;