O aplicativo de console baseado em C trava quando executado no cmd.exe, funciona bem no depurador do VS2008?
-
16-09-2019 - |
Pergunta
Não tenho certeza do que está acontecendo aqui.
Eu tenho um aplicativo de console do Windows escrito em C. Quando o executo no vs2008, ele funciona bem. Se eu o executar no prompt cmd.exe, ele trava, geralmente em Malloc (). Acho que é uma condição de corrida devido a uma biblioteca CRT incompatível.
O aplicativo é simples.
Ele chama a camada WINHTTP para enviar uma solicitação GET para um site e depois suporta a resposta. Essa parte parece funcionar bem, mas após o WINHTTPREADDATA, o programa chama printf () para imprimir os dados recebidos, e é aí que o acidente do Malloc ocorre frequentemente.
Se apenas fora o depurador. ????
Estou compilando a partir da linha de comando.
c:\vc9\bin\cl.exe /Zi /DEBUG -Ic:\vc9\Include
-IC:\WindowsSDK\v6.1\Include HttpGet.c
-link /debug /out:HttpGet.exe /SUBSYSTEM:CONSOLE /LIBPATH:c:\vc9\Lib
/LIBPATH:C:\WindowsSDK\v6.1\Lib WinHttp.lib
Eu vejo os resultados acima se eu compilar com /mt, ou nada. Se eu compilar com /md, ele pendura quando executado no depurador, em uma chamada para free () e trava no cmd.exe (o mesmo que com /mt).
run in result: /MT result: /MD
--------- ------------ -----------
VS2008 debugger runs fine hang in free() (at the end)
cmd.exe crash in malloc crash in malloc
"VC cmd prompt" crash or hang(spin) ??
Algumas perguntas -
O comportamento diferente é por causa do caminho disponível no VS2008?
A causa poderia ser que eu não tenha o tempo de execução do VC90 instalado na minha máquina?
Eu pensei que, ao vincular estaticamente (/mt), não teria o requisito de precisar do tempo de execução do VC90 para ser instalado?
Eu ainda não entendo /nodefaultLib. Isso é relevante?
Estou acostumado a makefiles e compiladores, e sei C. Não conheço C ++, e é por isso que escrevo em C. Mas não entendo todos os caprichos do CRT nas janelas. Alguém pode esclarecer esse mistério?
Solução
Normalmente, quando vi algo funcionar no depurador, mas em nenhum outro lugar, é devido à memória não inicializada. O depurador é "bom o suficiente" para limpar a memória para você, como se isso estivesse fazendo um favor a você.
A segunda possibilidade é uma excesso de buffer, e o depurador está fazendo com que a localização da memória dos seus mallocs se mova o suficiente para evitá -lo. Eu suspeitaria que este, dado que seu fracasso está aparecendo durante um malloc; Você pode estar corrompendo a cadeia malloc.
Outra possibilidade que se destaca é algum tipo de condição de corrida, e o depurador está mudando o tempo o suficiente para permitir que você se saqueie.