language-agnostic compiler-construction crash

language agnostic - ¿Alguna vez has bloqueado el compilador?



language-agnostic compiler-construction (30)

Todos (al menos todos los que usan un lenguaje compilado) se han enfrentado a errores de compilación, pero ¿cuántas veces se bloquea el compilador?

He tenido una buena cantidad de "errores internos del compilador", pero la mayoría desaparecieron con solo volver a compilar. ¿Tiene una pieza (mínima) de código que bloquea el compilador?

Actionscript 3.0:

switch(on_some_variable) { }

Interruptor vacío = Kaboom!

Aquí hay una forma de bloquear el compilador de VS ++ de C ++.

typedef map<int,int> Tmap; private: Tmap; * m_map;

Esto dará como resultado un bloqueo y aparecerá el siguiente mensaje de error

error fatal C1001: ERROR INTERNO DEL COMPILADOR (archivo compilador ''msc1.cpp'', línea 2708) Seleccione el comando Soporte técnico en el menú Ayuda de Visual C ++, o abra el archivo de ayuda Soporte técnico para obtener más información.

Elimine el punto y coma inmediatamente después de Tmap (segunda línea que define m_map ) para eliminar el error.

Bueno, esto en realidad no colisionó con el compilador. Era simplemente un error en el que VC ++ no aceptaría un código perfectamente bueno. ( detalles proporcionados aquí ).

Lo extraño de esto fue que solo se activó cuando se cumplieron tres condiciones bastante oscuras. Mover una línea de código era todo lo que se necesitaba para una solución efectiva. Y una de las condiciones previas necesarias fue "usar namespace std"; que es ampliamente desaconsejado en el código de producción.

Sin embargo, los mensajes que preguntaban cómo solucionar el problema eran un elemento básico en los grupos de noticias de Microsoft VC ++. No pude entender cómo tanta gente tropezó con un error oscuro. Entonces, eventualmente, le pregunté a alguien .....

El código exacto necesario para activar el error fue un ejemplo en " The C ++ Programming Langauge " de Stroustrup. (*)

(*) Nota, no estoy diciendo que lo hizo a propósito. Estoy seguro de que lo probó en una variante UNIX de C ++, y no me constaba por completo de su efecto en VC ++.

Cuando recibes el mensaje "Fallo catastrófico", sabes que lo estás intentando ...

Miguel

El compilador de Microsoft Xbox 360 puede bloquearse fácilmente. Me dieron el código fuente con comentarios japoneses y, cuando lo convertí en texto regular, uno de los últimos caracteres en la línea era un ''/' por lo que continuó el comentario en la siguiente línea. Si la siguiente línea era un comando de cambio, el compilador falla.

//wierd japanese characters here %^$$/ switch(n) { case 0: ..... break; case 1: ..... break; }

En la versión 1.2.x del compilador Mono C # se bloqueaba bastante con código complicado (si mal no recuerdo, los delegados anónimos anidados). Afortunadamente con la versión 2.x, no he visto ningún bloqueo.

En mi trabajo anterior teníamos un simulador que era conocido por ser capaz de bloquear compiladores (ICE) o hacer que generaran código incorrecto. Y cuando el código realmente se generó correctamente, después del compilador tomó 15 minutos para un solo archivo fuente. Visual Studio nunca fue (siempre y cuando yo trabajara allí) capaz de compilar el núcleo del simulador.

El núcleo se generó automáticamente desde una DSL, y el código generado a menudo empujó al compilador a sus límites.

La actualización a una nueva versión de GCC a menudo causó una gran nervosidad: ¿funcionará la nueva versión?

En un proyecto en el que estaba trabajando, algunos usos específicos de las expresiones de Boost Lambda podrían hacer que el compilador de Visual C ++ fallara. (Estábamos usando Visual Studio 2003)
El compilador solo se bloqueaba durante la compilación de lanzamiento, una compilación de depuración funcionaría bien.

Se había producido una guerra religiosa en el equipo por el uso apropiado de las bibliotecas lambda, estaba casi agradecida de que el compilador lo resolviera por nosotros. :-)

Escribo el compilador que usamos, por lo que se cuelga a veces.

Esto bloqueó el C64 BASIC:

PRINT 0 + "" +- 0

Gracias a @Nick , esto bloquea VS2005.

template<typename Res, typename T> Res operator_cast(const T& t) { return t.operator Res(); } int main() { return operator_cast<int>(0); }

He bloqueado VC ++ varias veces, generalmente con código de plantilla. Pero ese no es el choque más interesante ...

Bloqueé el compilador del Sistema de equipo VS2005 con la opción / analizar compilando la biblioteca de código compartido que compilé sin error sin el conmutador y en el VS2008 con y sin el conmutador. Por supuesto, MS no estaba muy interesado porque era un error en la versión anterior del compilador, pero pensé que era bastante interesante.

He bloqueado muchas veces Delphi 7 para pedirle que compile el código dos heredado.

El principal culpable parece ser cualquier calificación de algo como estar en la unidad del sistema. Esto no siempre lo explotará, pero cuando explota, reviso y reescribo cualquier cosa que requiera tal anulación y el problema desaparece.

Las explosiones son 100% reproducibles, pero nunca he logrado hacer un caso de prueba simple. En realidad, no bloquea el compilador la mayor parte del tiempo, generalmente se obtiene un error que no tiene nada que ver con el problema y puede haber cientos de líneas a partir de él. El entorno está desestabilizado, guardar y salir está bien, pero no pienses en hacer nada más.

De vuelta en la edad de piedra con Borland Pascal 7 (la última versión dos) la rompí muchas veces. Sin fallas, solo emisión de código incorrecta e inconsistente. Finalmente aprendí a mantener .EXE (sin contar la información de depuración) por debajo de 3mb. Cuanto más allá de eso me fui, más inestable se volvió.

He colgado un compilador antes al ejecutarlo sin memoria.

Proporcione a un compilador de DOS aproximadamente 0.5mb de código fuente. Crujido.

He visto algunos errores de compilación en el compilador de C # (todos los casos extremos, todos informados adecuadamente) y confirmó algunos bloqueos provocados por otras personas.

El error más temible del compilador (de una clase) que he encontrado fue un error JIT en una versión de Java. Fue bastante reproducible, pero causó que el VM cayera. Agregando una declaración bastante no-op (no puedo recordar exactamente lo que de improviso - posiblemente solo declarando una variable local adicional con un valor inicial) lo alejó del caso de esquina que resultó ser - y se corrigió en una versión posterior.

Hoy VS2003SP1 me dio un C1001 (Error interno del compilador) quejándose del archivo compilador ''msc1.cpp'', línea 2708) debido a esto:

struct PATTERN { … };

Resultó que el problema era que el nombre de la estructura que estaba tratando de definir (PATTERN) ya era un typedef en el GDI para un tipo de pincel. Sin embargo, en lugar de decirme que el símbolo ya está definido (como para la mayoría de las otras cosas), no solo no apuntó a la estructura como el problema: reduje el problema al comentar selectivamente los bloques hasta que desapareció el error. Pero también me dio el error críptico antes mencionado que no tiene nada que ver con el archivo especificado, que ni siquiera puedo encontrar para examinar la línea en cuestión. : |


Pude reproducirlo con el siguiente código:

typedef int SOMETHINGOROTHER; struct SOMETHINGOROTHER {};

> fatal error C1001: INTERNAL COMPILER ERROR
> (compiler file ''msc1.cpp'', line 2708) …


Mientras que el siguiente código proporciona el mensaje de error esperado:

struct SOMETHINGOROTHER {}; typedef int SOMETHINGOROTHER;

> ''SOMETHINGOROTHER'' : redefinition; different basic types


Claramente, el problema está en la rutina de manejo de la estructura del compilador.

Me pregunto si VS2005 + lo hará mejor ...

Logré segfault el intérprete de Python. Por supuesto, estaba trabajando en una extensión C en ese momento y no lo estaba del todo bien.

No ocurre tanto como solía hacerlo, pero ocasionalmente el precompilador de ASP.net tiene problemas. No lo he visto personalmente, pero he solucionado un problema en otro proyecto en el que tenían conflictos de nombres porque no lo estaban. utilizando espacios de nombres correctamente (provoca colisiones del compilador) durante la precompilación.

En los viejos tiempos (MSVC ++ no administrado) tuvimos la extraña falla del compilador usualmente debido a la vinculación de clases de Win32 estáticas externas (.lib) y un par de bits de códigos ocasionales ocasionaban problemas, pero todos fueron recogidos muy rápidamente.

No sé si lo llamaría fallar, pero sdcc ( Small Device C Compiler ) falla al compilar el código formado de una manera particular:

  • Objetivo: 8051
  • El código tenía que ejecutarse en un caché de 512 bytes cargado desde un probador externo
  • Tester tiene el control y almacena el código; el caché no puede ir a la siguiente página
  • No se permiten llamadas a funciones: la PC (contador de programa) se saltaría a un lugar que no esté residente en la caché; se usaron macros de preprocesador para llevar a cabo la práctica de codificación modular
  • Saltos (ramificación) permitidos si no se salta del caché
  • Sin valores de const: en la sección de datos del código del programa que causa que el código en la memoria caché recupere algo que no está en la memoria caché - preprocessor constant (#define) OK aquí

Las macros del preprocesador se desenrollan dando como resultado un código plano, pero grande: todo en main (); la ejecución omite el código de inicio (configuración de la pila, etc.) y comienza al principio de main ()

Parte relevante de esta respuesta:

Ocasionalmente, sdcc se rehusaría a compilar el código sintácticamente correcto, con un mensaje sobre quedarse sin memoria. Esto incluso sucedió compilando en cajas de 64 bits con 8 GB de RAM.

La solución en estos casos fue dividir el firmware en piezas separadas y compilarlas por separado y ejecutarlas por separado. Es posible que las piezas se hayan podido volver a vincular, pero en ese momento no importó.

No lo intenté, pero el compilador Keil 8051 probablemente podría haber manejado el código problemático.

Sí, especialmente cuando es un compilador antiguo o poco mantenido (GCC 2.95, Tendra en modo C ++). Aunque no guardo las piezas de código.

Todavía no he bloqueado GHC (compilador de Haskell), pero lo he solucionado con un error

My brain just exploded. I can''t handle pattern bindings for existentially-quantified constructors.

Es bastante fácil evitarlo, y no lo logras a menos que tengas un diseño complicado (y generalmente incorrecto), pero probablemente gane como el mejor mensaje de error del compilador.

Una vez, cuando utilicé el ejemplo de generadores de los documentos Python, rompió la versión de Python que estábamos usando. La misma semana, uno de mis colegas se las arregló para hacer un uso incorrecto de la FFI de manera que cualquier cálculo que implique el número 3 interrumpiría Python.

Uso tanto pcc como gcc para compilar mi viejo proyecto de SO.

Encontré un error con la forma en que pcc y gcc manejaban una pieza de código no trivial y se bloqueaba pcc. (los caracteres están firmados en mi plataforma)

struct{ char myvalue:1; }mystruct;

pcc se colgó porque todos los valores del campo de bits deben ser enteros, por lo que en realidad tiene más errores, pero gcc lo maneja incorrectamente. Mira, si lo piensas bien, está firmado, pero solo tiene espacio para un bit. Por lo tanto, solo puede almacenar 0 y -1. Bueno, gcc maneja mal al almacenar 0 o 1.

VC ++ se estrelló cuando compilé C ++ si el uso de la plantilla está mal (por ejemplo, perder un cierre ">").

VC lo capta con gracia ahora, pero a mediados de los 90, esto colapsaría los compiladores de C ++ y Borland C ++ de Microsoft:

struct MyClass { MyClass operator->() { return *this; } }; int main(int argc, char* argv[]) { MyClass A; A->x; }

Un operador sobrecargado-> es intrínsecamente recursivo. Se espera que la función devuelva un puntero, al cual se aplica de nuevo oper->. Este fragmento hizo la generación de código infinitamente recursiva.

Vaya, olvidé una ''e'' en typedef y bloqueé el compilador.

typdef struct kGUIColor GameColor; c:/source/kgui/samples/space/space.cpp(35) : fatal error C1001: INTERNAL COMPILER ERROR (compiler file ''msc1.cpp'', line 2708) Please choose the Technical Support command on the Visual C++ Help menu, or open the Technical Support help file for more information

Visual C ++ 5. ''dijo Nuff.

Visual C ++ 9.0 SP1

esto me pasó a mí

------ Build started: Project: pdfp, Configuration: Debug Win32 ------ Compiling... reader.cpp xref.cpp c:/projects/pdfp/xref.cpp(52) : fatal error C1001: An internal error has occurred in the compiler. (compiler file ''f:/dd/vctools/compiler/cxxfe/sl/p1/c/toil.c'', line 8569) To work around this problem, try simplifying or changing the program near the locations listed above. Please choose the Technical Support command on the Visual C++ Help menu, or open the Technical Support help file for more information Generating Code... Build log was saved at "file://c:/Projects/pdfp/Debug/BuildLog.htm" pdfp - 1 error(s), 0 warning(s) ========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

Yo si. Algunas versiones de Delphi (digamos # 4) se bloquearon muy a menudo con mensajes de error crípticos.

Las versiones más nuevas (2006 y más) son estables pero no sólidas. (7 fue excelente en ese caso).

Los bloqueos del compilador a menudo se producen con ediciones grandes y sesiones de depuración de proyectos complejos (muchos dll). La mayoría de las veces un reinicio de la ide es suficiente. Pero a veces es necesario reiniciar la PC.

O y yo una vez se estrelló OS2 junto con el compilador porque el archivo de intercambio creció demasiado.

fácil.

// -*- C++ -*- template <int n> class Foo : public Foo<n+1> { }; int main(int, char*[]) { Foo<0> x; return 0; }; ejgottl@luna:~/tmp$ g++ -ftemplate-depth-1000000 -Wall foo.cpp -o foo g++: Internal error: Segmentation fault (program cc1plus) Please submit a full bug report. See `<URL:http://gcc.gnu.org/bugs.html>` for instructions. For Debian GNU/Linux specific bug reporting instructions, see `<URL:file:///usr/share/doc/gcc-4.2/README.Bugs>`.