Error de aserción en CRT llamando _osfile() en VS 2008?

Question

Tengo una base de código C++ que ha estado funcionando durante mucho tiempo. La base de código era un conjunto de proyectos heredados VS 2003 que migré recientemente a VS 2008. La migración parecía tener éxito porque el programa resultante se creó y ejecutó.

Reinstalé mi sistema operativo y todas las aplicaciones en una unidad fresca, y ahora cuando intento para depurar el programa en el depurador, recibo un error de aserción en el interior del CRT chsize (en realidad, _chsize_s). Específicamente (cosechado a lo esencial, haciendo caso omiso de los controles de seguridad):

FILE * testfile = fopen("P:\\_Dan\\local\\foogoo.txt", "w"); 
int filehandle = fileno(testfile); 
chsize(filehandle, 0); 
fwrite("goohoo", 1, 6, testfile); 
fclose(testfile); 

La aserción de depuración se produce dentro de chsize - en concreto, en el código fuente de archivo chsize.c del CRT, en la línea siguiente:

_VALIDATE_CLEAR_OSSERR_RETURN_ERRCODE((_osfile(filedes) & FOPEN), EBADF); 

. .. donde filedes coincide con filehandle.

Pensé que posiblemente el problema podría ser el resultado de no tener una versión anterior de VS instalada en el nuevo sistema (solo VS 2008), porque algunas bibliotecas de terceros requieren VS 8.0 redistribuible, aunque en el sistema antiguo las cosas parecían estar construyendo y funcionando perfectamente con VS 2008. Por lo tanto, instalé VS 2005 (no 2003). Sin embargo, el problema continúa ocurriendo.

Cualquier sugerencia sería muy bienvenida.

* Actualización - El problema no está relacionado con chsize. Ver mi respuesta a continuación.

Answer 1

El problema está resuelto y no está relacionado con chsize. El modelo de vinculación a las bibliotecas de c-runtime elegidas para la generación de código se configuró en depuración multiproceso (/ MTd) para el proyecto principal, pero DLL de depuración multiproceso (/ MDd) para todos los proyectos en la solución que vincula a. Cambiar a/MDd resolvió el problema.

Estoy familiarizado con estos problemas de vinculación y generalmente tengo cuidado de configurarlos correctamente, pero como esto era una actualización de un proyecto en funcionamiento de una versión anterior de Visual Studio sin cambios, no pensé en mirar hacia abajo . No investigué cómo o por qué se modificó la configuración (o incluso si se configuró de esta manera en la versión anterior, pero no causó problemas).

Answer 2

Encontré este problema en mi código también. El programa principal debe vincularse con la biblioteca compartida que se compila con MT. Cuando el manejador de archivos se abrió en el programa principal pasó a la función de la biblioteca compartida, _VALIDATE_RETURN ((_ osfile (fh) & FOPEN), EBADF, -1) en setmode.c de CRT bloqueó el programa.

Depure el _osfile en modo de ensamblaje, manejador de archivo de búsqueda de osfile en la tabla __pioinfo (01802EEDB0h). Bueno, es área fija en CRT estáticamente vinculado. Y otro __pioinfo en el programa principal es otra dirección 01E619540h. En una palabra, si dos módulos necesitan datos globales compartidos, no pueden compilarse con el modelo MT.

Solo quiero optimizar la biblioteca compartida con la compilación estática, algunos errores difíciles de notar podrían ocurrir. Parece que la fuerza de GCC compartida o estática tiene sentido en la mayoría de las situaciones.