[FUG-BR] gcc gerando código errado

[Otacílio]

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<alansilva em acm.org>  escreveu:
>
>> Testa com o clang, o resultado normalmente acaba sendo mais fácil de ser
>> interpretado... :)
>>
>>
>> 2012/4/29 Otacílio<otacilio.neto em bsd.com.br>
>>
>>> On 29/04/2012 03:03, Paulo Pires wrote:
>>>> Já tentou rodar o programa com ktrace/truss/strace?
>>>>
>>>> 2012/4/28 Otacílio<otacilio.neto em bsd.com.br>
>>>>
>>>>> 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<otacilio.neto em bsd.com.br>
>>>>>    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 em 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 em 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