Você enviou, você recebe uma falha rara de seg. Ponteiro checando ou largando?


9

Você enviou, as declarações estão desativadas, você recebe um relatório de falha raro indicando que ocorreu uma violação de ponteiro nulo no seu código. Em um ambiente de desenvolvimento, o problema teria sido pego por uma afirmação.

Tudo o que você tem é um relatório de falha, portanto, reproduzir o problema é quase impossível. Seguir o backtrace não fornece pistas sobre o motivo do acidente ter ocorrido em primeiro lugar.

Opções: - Adicione a verificação do ponteiro para evitar a falha. Isso evitará o acidente, mas você provavelmente nem descobrirá por que isso aconteceu. - deixe voar, espero que aconteça novamente com um cenário de reprovação

Digamos que o aplicativo não se destine a um míssil guiado ou a um sistema de freio automático ...

Qual você escolheria?


A menos que este é retórica, pode ser útil para publicar o relatório de acidente, juntamente com os arquivos de código correspondentes (talvez no Pastebin.com) para o site Stack Overflow se você quer que isso seja resolvido ...
Tamara Wijsman

2
@TomWij: Não pense so..it provavelmente vai ficar fechado como "muito localizada"
Naveen

@Naveen: Talvez ... eu não sou um visitante regular de SO, então esse foi um comentário SU-mind.
Tamara Wijsman

11
@ Naveen: Muito localizado significa muito regional, trata-se de geografia e não de especialização de questões. Mas essa pergunta provavelmente seria encerrada no SO pela subjetividade.
Maniero

Respostas:


7

Eu escolhi a segunda abordagem. Não há sentido em ocultar a falha se o ponteiro NULL for inesperado no ponto em que ocorreu a falha. Esse ponteiro NULL na maioria dos casos seria apenas um dos sintomas de que algo está errado. Se o ocultarmos com uma verificação de ponteiro NULL, é quase certo que algo mais irá quebrar. Eu sinto que você tem uma chance melhor de entender o cenário, se souber o ponto em que ele falha todas as vezes, em algum lugar aleatório.


11
Estou me inclinando para essa opinião. A percepção do usuário é o que me preocupa. Um acidente parece claramente que algo deu errado. No entanto, se um recurso obtiver um cálculo completamente errado, isso também será percebido.
MM01

2
Na minha opinião, embora o usuário possa ficar irritado com uma falha ocasional, ele ficará muito chateado se fornecer um resultado errado, pois pode passar despercebido.
Nav

falhar o mais cedo possível, ele ajuda você a encontrar o problema, e isso ajuda o usuário solta menos dados
Spudd86

também usaria o valgrind para descobrir o que estou fazendo de errado (ou pelo menos tentaria, em qualquer caso, poderá encontrar alguns problemas que você deve corrigir). Acrescentaria declarações adicionais para tentar capturar o ponteiro NULL mais cedo e peça ao usuário para tentar executar uma compilação que tenha as declarações ativadas por um tempo para ver se elas podem travar antes
Spudd86

3
  1. Quantas vezes a falha ocorre? Isso acontece apenas para um em muitos clientes em algum caso obscuro? Quais são as consequências (perda de dados, falha no sistema)? Se isso acontecer a cada 1 em um milhão de casos e eles apenas tiverem que reiniciar o aplicativo e nenhum dado for perdido, provavelmente você não precisará corrigi-lo - deixe assim.

  2. Qual é o custo (dinheiro e tempo) de adicionar as declarações e enviá-las a todos os clientes (se apenas uma parte dos clientes obtiver a nova versão, o restante poderá entrar no problema nulo não verificado)? Quais são as chances de encontrar o problema? Se você apenas colocar verificações aleatórias no código na esperança de detectar o erro, é uma prática ruim ...

  3. O problema pode ser reproduzido na máquina do cliente? Você pode obter acesso a essa máquina? Isso pode ser realmente valioso

  4. Revise seus relatórios de falhas e verifique se as informações fornecidas são úteis e podem ajudá-lo a diagnosticar o problema


2

Em um ambiente de desenvolvimento, o problema teria sido pego por uma afirmação.

Em uma ordem específica, ele teria sido capturado e corrigido, mas o rastreamento posterior atual nunca foi capturado.
Você deve poder ver o que deu errado com o despejo de memória, verificou parâmetros, etc ...?

Os extras que podem ser feitos com base na quantidade de tempo que você deseja dedicar a isso:

  • Arquive o despejo de memória e faça referência a ele no código com um comentário na linha em que ele falhou,
    isso permite que um que examine um despejo de memória muito semelhante saiba que isso aconteceu antes ...
    [tempo gasto: curto]

  • Verificações adicionais, registro, ... Você deseja evitá-lo e obter mais informações na próxima vez.
    [tempo gasto: médio]

    Violação de ponteiro nulo ocorreu no seu código.

  • Verifique se é impossível chamar o aplicativo dessa maneira para que essa violação ocorra.
    [tempo gasto: longo]


11
Este post não é muito sobre a abordagem para resolver o problema, mas o curso de ação em uma situação hipotética (ou seja, no período alocado, a fonte do problema não pode ser deduzida).
MM01

2

Hoje em dia, eu envio com assert () ativado. Não custa muito e pode tornar a vida muito mais fácil em situações hostis (ou seja, os ambientes de seus clientes costumam ser mais hostis que seus ambientes de desenvolvimento ou controle de qualidade).

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.