• Revista PROGRAMAR: Já está disponível a edição #53 da revista programar. Faz já o download aqui!

LaNgSuYaR

Compilar em Leopard e Ubuntu

8 mensagens neste tópico

Boas! É o seguinte: eu estou a fazer um trabalho de programação em C para a univ e, como é de grupo, trabalhamos em dois sistemas. No mac OS, onde o programa foi quase todo criado, e no Ubuntu. O que acontece é que, apesar de compilar e correr perfeitamente no mac OS, no Ubuntu compila mas na execução resulta em 'segmentation fault'...

Já dei voltas ao código a pensar que poderia ser uma má alocação mas não vi nada que pudesse causar o segmentation fault. Alguém conhece alguma 'incompatibilidade' em transportar código (não executaveis) entre Linux e Mac OS? (encoding, nos end of line, por aí....)

As opções que já foram testadas para compilar:

  • gcc -O2 -ansi -pedantic
  • gcc -Wall
  • gcc -O2 -Wall

Todas estas opções resultam em segmentation....

Agradeço a ajuda!

Cumprimentos,

Tiago Melo

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Assim à primeira vista, diria que tens um erro que, por acaso, não se manifesta no MacOSX.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Provavelmente um array out of bounds, são os mais comuns. Basta um dos sistemas ser mais picuinhas..

Porque não fazem debug?

Em ubuntu:

Compilem o programa com -g, abram com o gdb, corram, e perguntem "where"? Ele diz-vos em que linha deu o seg fault.

Ou então, o que eu faria, corram com o valgrind (se tiverem instalado). Ele analisa o código do programa à procura de possibilidades de aceder a posições ilegais. (já me ajudou a detectar um '\0' a menos, que no meu PC ao iniciar a string ele estava a iniciar tudo a 0 e noutro não..

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Porque não fazem debug?

Em ubuntu:

Compilem o programa com -g, abram com o gdb, corram, e perguntem "where"? Ele diz-vos em que linha deu o seg fault.

Recomendado! :)

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Neste momento não tenho oportunidade de correr o programa em Linux para fazer o debug, mas logo que possa vou verificar...

O erro ocorre numa inserção numa árvore B de uma data formatada em uma string.

Quando fiz o código tive cuidado com os '\0' e o mais estranho de tudo é que ele dá erro a meio do processo de inserção de vários elementos.

A único pormenor que me ocorre é que a data onde se dá o seg.fault contenha algum caracter de código porque à partida todas as datas são formatadas por igual.

Mais precisamente:

a função de formatação recebe uma data no formato: Thu Jul  5 00:15:50 2006

e retorna uma string no formato: 20060705001550 (ano ++ mes ++ dia ++ hora ++ minuto ++ segundo)

edit: Além do mais, os testes que fizemos a testar algum possível erro passam por testar cada string formatada e verificar se esta contém o '\0' e se a string onde se dá o crash é de alguma forma, diferente das outras que foram inseridas....Em vão!

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Usem o valgrind, e se mesmo assim ele não detectar nada de estranho, corram no gdb.

No gdb podes fazer print à data, e portanto ver se ela contem algum caracter estranho ou não.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Boas! já consegui encontrar o erro.... Era um array out of bounds!!! Acontece que calculei mal a definição de cada nodo e quando a inserção era feita no final do nodo, o seu 'filho' direito era colocado numa posição que não existia.

No mac OS não dava erro talvez devido à estratégia de alocação de memória, no entanto no Linux o erro manifestava-se. Mesmo com o debugging do gdb, ainda demorei algum tempo a perceber o que se passava.

Anyway, obrigado pelas ajudas!

Quando finalizar as operações em árvores B coloco aqui o código para referência!

Cumprimentos,

Tiago Melo

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Quando um programa crasha geralmente deixa um ficheiro core na pasta onde está o binário executado. Isto em sistemas Unix/Linux. Se abrires o gdb sendo o primeiro parâmetro o nome do teu executável e o segundo parâmetro esse ficheiro core (ou as paths completas para estes ficheiros se não correres o gdb na pasta onde estão estes ficheiros), tens logo à partida informações sobre a linha que gerou o crash, e informação mais detalhada sobre o crash em si. Lendo alguma documentação do gdb rapidamente consegues aprender quais os comandos para aceder aos dados, memória, threads, bibliotecas carregadas, etc., exactamente como tudo estava antes do teu programa crashar. Na minha opinião vale a pena perderes algum tempo a estudar os comandos do gdb porque rapidamente consegues perceber o que o teu programa está a fazer exactamente e o porquê de teres erros e quais são esses erros. É sem dúvida uma ferramenta indispensável na programação de qualquer linguagem suportada por este debugger (C/C++, Java, ..., whatever fits).

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Crie uma conta ou ligue-se para comentar

Só membros podem comentar

Criar nova conta

Registe para ter uma conta na nossa comunidade. É fácil!


Registar nova conta

Entra

Já tem conta? Inicie sessão aqui.


Entrar Agora