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?

bug pointers

— MM01
fonte

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

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.

— Naveen
fonte

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

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.
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 ...
O problema pode ser reproduzido na máquina do cliente? Você pode obter acesso a essa máquina? Isso pode ser realmente valioso
Revise seus relatórios de falhas e verifique se as informações fornecidas são úteis e podem ajudá-lo a diagnosticar o problema

— Victor Hurdugaci
fonte

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]

— Tamara Wijsman
fonte

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).

— Mitch Haile
fonte