fano
02-04-2013, 20:19
Oggi Linux me ne ha combinata un'altra ecco la situazione:
1. Programma con main() compilato con -E etc per usare dlopen()
2. Librarie dinamica dove giace buona parte del programma, in particolare define della callback che dlsym() dovrà poi trovarmi
Ad un certo chiedo a sto ammenicolo di trovarmi una funzione, me la trova bello paciarotto, ma avevo dimenticato di aggiornare la libreria :muro: e così il programma sembra terminare senza dirmi nulla a parte un "core" con valore 127 :confused: (che però non mi viene trappato dalla mia routine di signal).
Alla fine chiedo aiuto a San Google, patrone dei programmatori stanchi, e mi dice che 127 è "file non trovato" o "comando non trovato", di file non se ne parla, ma di comandi sì... se intende "funzioni" così costringo sto ammenicolo a stampare su stderr e vedo con disgusto:
"symbol lookup error xxx() not found".
Dopodiché ho cambiato la libreria con la mia e tutto ha ripreso a funzionare ed io me ne sono ito a casa incazzato come un'ape :muro:
Tipicamente in questi casi l'applicazione NON avrebbe dovuto manco partire, ma lo ha fatto, come? Forse ho dato qualcosa di "esotico" nei flags di compilazione...
Comunque mi andrebbe anche bene se riuscissi a trapparlo... sapete se ld (o il kernel o che ne so io) mi manda qualche segnale particolare per ammazzarmi il processo così che io possa rendermene conto?
Fate conto che c'abbiamo solo sta macchinetta su cui buttar roba e al progetto ci lavoriamo almeno in 3 (presto forse 4) è un attimo che l'eseguibile e la libreria dinamica si disallineano e poi mi sparano :muro:
Vorrei, quindi, poter scrivere una log da parte della stessa applicazione, visto che stderr è, ovviamente, mandato in c*lo ehm /dev/null insieme al suo amichetto stdout :Prrr:
Immagino che con wait() ce lo farei, ma un segnale sarebbe meglio visto che così è l'applicazione che "parla" :mbe:
1. Programma con main() compilato con -E etc per usare dlopen()
2. Librarie dinamica dove giace buona parte del programma, in particolare define della callback che dlsym() dovrà poi trovarmi
Ad un certo chiedo a sto ammenicolo di trovarmi una funzione, me la trova bello paciarotto, ma avevo dimenticato di aggiornare la libreria :muro: e così il programma sembra terminare senza dirmi nulla a parte un "core" con valore 127 :confused: (che però non mi viene trappato dalla mia routine di signal).
Alla fine chiedo aiuto a San Google, patrone dei programmatori stanchi, e mi dice che 127 è "file non trovato" o "comando non trovato", di file non se ne parla, ma di comandi sì... se intende "funzioni" così costringo sto ammenicolo a stampare su stderr e vedo con disgusto:
"symbol lookup error xxx() not found".
Dopodiché ho cambiato la libreria con la mia e tutto ha ripreso a funzionare ed io me ne sono ito a casa incazzato come un'ape :muro:
Tipicamente in questi casi l'applicazione NON avrebbe dovuto manco partire, ma lo ha fatto, come? Forse ho dato qualcosa di "esotico" nei flags di compilazione...
Comunque mi andrebbe anche bene se riuscissi a trapparlo... sapete se ld (o il kernel o che ne so io) mi manda qualche segnale particolare per ammazzarmi il processo così che io possa rendermene conto?
Fate conto che c'abbiamo solo sta macchinetta su cui buttar roba e al progetto ci lavoriamo almeno in 3 (presto forse 4) è un attimo che l'eseguibile e la libreria dinamica si disallineano e poi mi sparano :muro:
Vorrei, quindi, poter scrivere una log da parte della stessa applicazione, visto che stderr è, ovviamente, mandato in c*lo ehm /dev/null insieme al suo amichetto stdout :Prrr:
Immagino che con wait() ce lo farei, ma un segnale sarebbe meglio visto che così è l'applicazione che "parla" :mbe: