Domanda

Come faccio a ottenere un'applicazione C++, compresi carico, ada libreria condivisa per generare un core dump in caso di caduta?

Ho una applicazione C++ che carica un ada libreria condivisa, all'interno del codice ada ottengo un errore di overflow dello stack che provoca la chiusura del programma con l'uscita della console:

raised STORAGE ERROR

No core dump file viene generato anche tu, ho rilasciato un "ulimit -c illimitato" prima di avviare l'applicazione.

Stessa cosa succede se invio un kill SIGSEGV per l'applicazione.

L'invio di uccidere SIGSEGV un'altra applicazione che non utilizza l'ada dll genera un file di core dump solo il modo in cui voglio.

Trovare alcune informazioni qui: http://objectmix.com/ada/301203-gnat-fstack-check-does-work.html

AGGIORNATO!Come detto da Adrien, non c'è contraddizione, -s imposta il limite dello stack, mentre -c imposta il file del core di limite.

Comunque il problema rimane.Ho controllato le bandiere durante la costruzione della biblioteca ada e il fstack-check la bandiera non è stata impostata, quindi dovrebbe generare un core dump.

Anche se non ho ancora provato, mi sembra un po ' strano.Si parla di fstack-check opzione del compilatore + impostazione del GNAT_STACK_LIMIT variabile, ma al tempo stesso si riferisce il comando ulimit che sembra una contraddizione, l'impostazione "ulimit -c" è l'unico modo che conosco per ottenere un core dump essere generato al momento del crash, se questo deduce con il fstack-check opzione, quindi abbiamo una cattura 22.

È stato utile?

Soluzione

Ora, quasi 2 anni dopo (ancora lavorando all'interno della stessa azienda Kristofer ha fatto quando ha fatto la domanda), la questione è stata sollevata ancora una volta - e, infine, penso che mi capisce perché non core dump generato!!

Il problema è causato dall'Ada di run-time, che per impostazione predefinita implementa un gestore di segnale per alcuni POSIX-segnali (per Linux:SIGABRT, SIGFPE, SIGILL, SIGSEGV e SIGBUS).Per MOSCERINO/linux il gestore di segnale è chiamato __zanzara_error_gestore in a-init.c, che sembra qualcosa di simile a questo:

static void
__gnat_error_handler (int sig)
{
  struct Exception_Data *exception;
  char *msg;
  static int recurse = 0;
  ...
  switch (sig)
    {
    case SIGSEGV:

      if (recurse)
      {
        exception = &constraint_error;
        msg = "SIGSEGV";
      }
      else
      {
        ...
        msg = "stack overflow (or erroneous memory access)";
        exception = &storage_error;
      }
      break;
     }
    recurse = 0;
    Raise_From_Signal_Handler (exception, msg);
 }

Questo gestore è il processo di "ampia", e sarà chiamato da qualsiasi innescato segnale, non importa da quale parte del processo che ha origine da (non importa se codificato in Ada/C/C++...).

Quando viene chiamato, il gestore sorge un Ada-eccezione e lascia il Ada runtime per trovare un gestore di eccezioni - se tale gestore si trova (es.quando un SIGSEGV è generato da qualsiasi parte del C++), del codice), l'Ada-runtime ricade solo terminare il processo e lasciare solo un semplice stampa da __zanzara_error_gestore (es."stack overflow (o errati di accesso alla memoria)").

http://www2.adacore.com/gap-static/GNAT_Book/html/node25.htm

Per evitare Ada-runtime dalla gestione di un POSIX-segnale, e convertirlo in un Ada-eccezione, è possibile disattivare l'impostazione predefinita beahviour utilizzando

pragma Interrupt_State (Nome => valore, Stato => SISTEMA | RUNTIME | UTENTE);,

es.per disabilitare la gestione di SIGSEGV, definire

Pragma Interrupt_State(SIGSEGV, SYSTEM);

nel Ada-codice - ora il sistema di default di comportamento viene innescato quando un SIGSEGV è sollevato, e un core dump, verrà generato che consente di risalire lungo l'origine del problema!

Penso che questo è un problema importante di essere a conoscenza di quando la miscelazione di Ada e C/C++ su sistemi *NIX-piattaforme, in quanto può indurre a pensare che i problemi origini Ada-codice(dato che la stampa indica un'eccezione generata da Ada), quando la vera origine del problema risiede in C/C++-codice...

Anche se è probabilmente sicuro per disattivare l'Ada-runtime predefinito della gestione di SIGSEGV (credo che nessun sano di mente programmatore che utilizza questo in qualsiasi "previsto" la gestione dell'errore...Beh, forse utilizzato in aviazione software o simili, quando una sorta di "last resort" le funzionalità che deve essere mantenuta per evitare che qualcosa di veramente brutto accada..) credo che un po ' più di cautela quindi "rilevante", l'Ada-runtime di gestione per i segnali.

Un problema potrebbe essere il SIGFPE-segnale, che solleva anche un Ada Constraint_Error-eccezione per impostazione predefinita.Questo tipo di eccezione può essere utilizzato da Ada-il codice come una "excpected di comportamento".Disattivazione SIGFPE da Pragma Interrupt_State può seriamente compromettere l'esecuzione dell'Ada-codice, e crash dell'applicazione durante la "normali" - d'altra parte, qualsiasi divisione per zero in C/C++-codice trig, l'Ada-meccanismo di gestione delle eccezioni, e ti lasciano senza alcun reale traccia dell'origine del problema...

Altri suggerimenti

Questo mi sembra un davvero buon uso per il AdaCore il supporto.Non sono responsabile di trovare un sacco di popolare al di fuori di tale società, che sono che la familiarità con le implicazioni delle interazioni tra Gnu Ada e di runtime C++.

Vorrei suggerire per il debug di codice Ada che si prova a mettere in un ultimo disperato gestore di eccezioni intorno a tutto ciò, che a sua volta esegue il dump dello stack eccezione.La maggior parte dei fornitori hanno in qualche modo di fare che, di solito in base al largo di Ada.Le eccezioni.Exception_Information e Ada.Le eccezioni.Exception_Message.

Ho trovato una discussione da una prospettiva di sicurezza (individuazione di malware).Fondamentalmente ci sono 10 segnali che si possono provare, SIGSEGV è solo uno di loro.

Sembra che si può semplicemente chiamare sigaction(SIGSEGV, 0, SIG_DFL); per ripristinare l'impostazione predefinita comportamento di segnale.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top