On 29/04/2012 20:26, Eduardo Antonio Bortolini wrote: > Talvez, o valgrind possa te ajudar mais que o GDB, ou não..., mas vale > tentar ( http://valgrind.org/ ) . Você comentou que a linha de compilação é > bem grande, talvez tenha alguma dependência que não está sendo compilada no > momento certo ou está desatualizada.... e podem ocorrer comportamentos > muito estranhos como esses ... Talvez fosse interessante você organizar > isso em uma makefile.... Ou pelo menos teer certeza que quando você está > compilando não tenha nenhum .o antigo ou coisa assim .... > Mas vale o teste com o valgrind > > Em 29 de abril de 2012 16:52, Alan Silva<[email protected]> escreveu: > >> Testa com o clang, o resultado normalmente acaba sendo mais fácil de ser >> interpretado... :) >> >> >> 2012/4/29 Otacílio<[email protected]> >> >>> On 29/04/2012 03:03, Paulo Pires wrote: >>>> Já tentou rodar o programa com ktrace/truss/strace? >>>> >>>> 2012/4/28 Otacílio<[email protected]> >>>> >>>>> On 28/04/2012 23:44, Eduardo Antonio Bortolini wrote: >>>>>> Qual é a linha de comando que você estaria usando para compilar? Não >>> sei >>>>> se >>>>>> já não está fazendo, mas se não estiver tente colocar algumas flags >> de >>>>>> debug na compilação, por exemplo -g, -W >>>>>> >>>>>> Em 28 de abril de 2012 22:37, Otacílio<[email protected]> >>>>> escreveu: >>>>>> >>>>>>> Caros >>>>>>> >>>>>>> Estou com um problema aqui simplesmente fora de série! >>>>>>> >>>>>>> Estou compilando um programa que não está no ports, o nome dele é >>>>>>> covered. O programa compila depois de eu usar >>>>>>> >>>>>>> export LIBS=-lpthread >>>>>>> >>>>>>> no prompt. Só que quando ele roda ele dá core dump. Eu fui debugar o >>>>>>> programa e vi que ele estava gerando o coredump quando dava um >>>>>>> fflush(stderr). Até onde sei todo programa abre essa stream. O mesmo >>>>>>> programa no ubuntu funciona direito, sem problemas. Rodei um >>>>>>> >>>>>>> [ota@squitch covered-0.7.10]$ gcc -v >>>>>>> Using built-in specs. >>>>>>> Target: i386-undermydesk-freebsd >>>>>>> Configured with: FreeBSD/i386 system compiler >>>>>>> Thread model: posix >>>>>>> gcc version 4.2.1 20070719 [FreeBSD] >>>>>>> >>>>>>> >>>>>>> Vi também que estão instalados os compiladores >>>>>>> >>>>>>> >>>>>>> [ota@squitch covered-0.7.10]$ pkg_info | grep gcc >>>>>>> avr-gcc-4.5.1_1 FSF GCC 4.x for Atmel AVR 8-bit RISC >>>>> cross-development >>>>>>> gcc-4.4.7,1 GNU Compiler Collection 4.4 >>>>>>> gcc-4.6.4.20120406 GNU Compiler Collection 4.6 >>>>>>> gccmakedep-1.0.2 Create dependencies in makefiles using 'gcc -M' >>>>>>> mips-rtems-gcc-4.4.2_2 GNU gcc for cross-target development >>>>>>> >>>>>>> >>>>>>> Tentei compilar com o gcc44 e o gcc46 e recebi os mesmos erros. >> Alguém >>>>>>> tem alguma dica do que pode ser? >>>>>>> >>>>>>> []'s >>>>>>> -Otacílio >>>>>>> ------------------------- >>>>> >>>>> >>>>> >>>>> Eh bem grande, mas esta compilando com -g já. foi assim que encontrei >> o >>>>> problema analizando o core-dump >>>>> ------------------------- >>>>> Histórico: http://www.fug.com.br/historico/html/freebsd/ >>>>> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd >>>>> >>>> >>>> >>>> >>> >>> >>> Já rodei com gdb e descobri o seguinte. >>> >>> A versão que funcionou no Ubuntu era porque não compilou com suporte a >>> tcl/tk, Se compilar com suporte a tcl/tk o problema aparece. Agora o >>> mais escroto é que não é um problema no código do tcl/tk, apenas em >>> linkar com o tcl/tk o negócio acontece. O problema tem se manifestado >>> assim: >>> >>> Qualquer chamada a uma rotina que utilize stdout ou stderr dentro de uma >>> rotina que não seja main() dispara o segmentation fault. Agora se eu >>> chamar printf e tal dentro de main não dispara. É como se a pilha >>> tivesse ficado corrompida quando a linkagem com o tcl/tk é feita. >>> Acontece com o compilador gcc 4.2 4.4 e 4.6 tanto no freebsd como no >>> ubuntu. >>> -------------------------
Consegui achar o erro. Era uma variável do tipo array de caracteres que estava sendo alocada localmente na rotina. A variável era enorme, estava com tamanho de 128MB. Por isso não estava cabendo na pilha e o valgrind acusava mudança de pilha. o curioso era que o erro em geral se manifestava apenas quando eu linkava o aplicativo com suporte para o tcl/tk. []'s -Otacílio ------------------------- Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
