L'application de console C se bloque lorsqu'elle est exécutée à partir de cmd.exe, s'exécute correctement dans le débogueur VS2008?

Question

Vous ne savez pas ce qui se passe ici.
J'ai une application de console Windows écrite en C. Lorsque je l'exécute à partir de VS2008, il fonctionne bien. Si je l'exécute à partir de l'invite cmd.exe, il se bloque, généralement dans malloc(). Je devine que c'est une condition de concurrence due à une bibliothèque de CRT dépareillée.

L'application est simple.
Il appelle dans la couche WinHttp pour envoyer une requête GET à un site Web, puis slurps la réponse. Cette partie semble fonctionner correctement, mais après WinHttpReadData, le programme appelle printf() pour imprimer les données reçues, et c'est là que l'accident de malloc se produit souvent.

Mais seulement en dehors de le débogueur. ????

Je compile à partir de la ligne de commande.

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 

Je vois les résultats ci-dessus si je compile avec/MT, ou rien. Si je compile avec/MD, alors il se bloque lorsqu'il est exécuté dans le débogueur, lors d'un appel à free(), et il se bloque dans cmd.exe (comme avec/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) ?? 

Quelques questions -

1. Est ce que le comportement différent en raison de la voie disponible au sein VS2008?

2. La cause peut-être que le moteur d'exécution VC90 n'est pas installé sur mon ordinateur? Je pensais qu'en reliant statiquement (/ MT) je n'aurais pas besoin d'avoir besoin de l'installation de VC90 pour être installé?

3. Je ne comprends toujours pas/NODEFAULTLIB. Est-ce pertinent?

Je suis habitué à makefiles et compilateurs, et je sais que C. Je ne sais pas C++ qui est la raison pour laquelle je vous écris en C. Mais je ne comprends pas tous les caprices du CRT sur Windows. Quelqu'un peut-il éclaircir ce mystère?

Answer 1

Généralement lorsque j'ai vu quelque chose fonctionner dans le débogueur mais nulle part ailleurs, c'est en raison de la mémoire non initialisée. Le débogueur est "assez sympa" pour effacer la mémoire pour vous, comme si cela vous rendait service.

La deuxième possibilité est un débordement de tampon, et le débogueur fait bouger suffisamment l'emplacement de mémoire de vos mallocs pour l'éviter. Je soupçonnerais celui-ci étant donné que votre échec se manifeste pendant un malloc; vous pourriez corrompre la chaîne malloc.

Une autre possibilité qui se démarque est une sorte de condition de concurrence, et le débogueur modifie suffisamment le timing pour vous permettre de vous en sortir.