Category Archives: Articoli

GDB: DON’T PANIC!

Articoli Leave a reply

don_t_panic_buttonChiunque di noi si sia cimentato almeno una volta nella programmazione C, sa quanto questa sia versatile ed utile per molte delle applicazioni più complesse, prime fra tutte i sistemi operativi.

È pur vero che se si è provato almeno una volta a creare un programma, anche il più semplice, questo puntualmente la prima volta si è rivelato un fiasco, andando in errore, o ci si è trovati ad affrontare il temibile SEGMENTATION FAULT, o in italiano, Errore di Segmentazione.

Il C non è molto di aiuto nello scovare queste inefficienze dei programmi e può portare la persona più santa del mondo ad imprecare come il miglior scaricatore di porto.

Esiste però un rimedio a tutto questo o almeno un piccolo aiuto: il suo nome è GDB, un applicativo da linea di comando in grado di permetterci un debug degno dei migliori linguaggi di programmazione ed anche di più.

Sottolineiamo che in questo articolo non abbiamo intenzione di scrivere una guida completa e perfetta di questo programma, in quanto non siamo in possesso delle conoscenze per poterlo fare; vogliamo però aiutare chi si trova nelle difficoltà precedentemente accennate, a districarsene come abbiamo fatto noi con un po’ di conoscenze da auto didatta.

Vediamo innanzitutto come questo programma funziona: è in grado di eseguire tutti gli eseguibili, ma eccelle con l’input di speciali file compilati in modo da mantenere molte delle caratteristiche che hanno in fase di programmazione (numeri di riga, nessuna ottimizzazione, etc…).

Per creare un eseguibile di questo tipo dobbiamo mettere mano ad un Makefile, o comunque a gcc, e compilare i nostri file C utilizzando la seguente opzione:

gcc -g [FILES] -o [OUTPUT FILE]

Una volta generato il nostro file, possiamo cominciare a debuggarlo: eseguiamo quindi sempre da riga di comando, nella cartella dove abbiamo generato il nuovo file:

gdb [OUTPUT FILE]

se però ci troviamo nella situazione in cui il nostro programma richieda dei dati in input dobbiamo far si che questi pervengano all’eseguibile, e scopriremo a nostre spese che non è possibile farlo dopo la chiamata di gdb. Andremo quindi ad utilizzare questo comando:

gdb –args [OUTPUT FILE] [ARGS]

Siamo a cavallo! Il programma è stato caricato in memoria dall’applicativo e possiamo cominciare a lavorare! Ma come?!
segmentation-faultGdb si presenta come un programma a linea di comando ed è molto di aiuto per l’utilizzo: basta scrivere il domando “help” per avere un’idea di come poter cominciare.

Vediamo un utilizzo base tipico. Per cominciare proviamo ad eseguire un programma: trovandoci nella shell di gdb digitiamo il semplice carattere “r” e subito il programma si eseguirà, come si eseguirebbe ad un semplice avvio del vero eseguibile; c’è però un aspetto interessante: anche senza l’ausilio dei break point, tipico esempio di esecuzione di programma in modalità debug, gdb è in grado di catturare segnali (es: SIGPIPE) o i temibili Segmentation Fault. Quando questo accade, il programma viene fermato, ponendo in evidenza la riga esatta in cui questo è avvenuto, ed è possibile visualizzare i valori delle variabili presenti in quel contesto, nel loro stato attuale; scrivendo nella shell

print [NOME VARIABILE]

o

print [FUNZIONE RITORNANTE]

possiamo verificare quale abbia causato l’errore e provare a capirne la motivazione.

Potrebbe essere però utile seguire l’esecuzione passo passo, cosi da capirne la logica mentre questa viene eseguita.

Porre un break point è un’operazione molto semplice: scrivendo semplicemente

break

possiamo porre un’interruzione nell’istruzione subito successiva a quella attuale. Questo tipo di utilizzo è però molto raro e poco utile; è di gran lunga più utile il seguente comando

break [NOME FUNZIONE]

in questo modo non appena la logica del programma ci porta all’interno della funzione indicata, l’esecuzione viene bloccata e possono essere stampati i valori delle variabile, verificare il ritorno delle funzioni, eseguire la prossima istruzione (Comando: “next” o semplicemente “n”) o riportare il programma ad un esecuzione lineare, fino almeno al prossimo break point (Comando: “continue”).

A volte una funzione può essere molto lunga e potrebbe non essere necessario eseguire le prime righe di codice per effettuare un debug; può risultare utile, se si è a conoscenza del numero di riga dal quale vogliamo cominciare, la seguente variante

break [NUMERO DI RIGA]

in grado di bloccarci solamente quando raggiunta tale riga, evitando tediose e ripetute pressioni di tasti.

I progetti C sono solitamente divisi in molti file di codice, alcuni dei quali contengono funzioni con stesso nome di quelle di altri. Come fa gdb a capire su quale di queste bloccarsi? E se il file C non contiene il dato numero di riga, in quanto presente in un altro file?

Ci vengono in aiuto due ulteriori versioni di questo comando, dedicate alle nostre specifiche richieste

break [NOME FILE]:[NOME FUNZIONE]

e

break [NOME FILE]:[NUMERO DI RIGA]

Ultima (nella nostra trattazione), ma non banale o poco utile, variante di questo comando è la seguente

break … if [CONDIZIONE]

questa ci permette di eseguire il debug nel migliore dei modi: al verificarsi di un dato evento, permettendo di facilitare ulteriormente il nostro lavoro.

L’utilizzo di gdb può essere immenso. Il nostro articolo purtroppo non può coprire tutti i casi, ma vi rimandiamo a seguente link http://www.chemie.fu-berlin.de/chemnet/use/info/gdb/ dove è possibile quietare i dubbi più intricati, se il nostro articolo non è riuscito a delucidarvi.

GDM: risolvere il loop durante il login

Articoli Leave a reply

Schermata di login utente. Inserite Nome e Password, date accedi e vi ritrovate alla schermata suddetta. Ma che sbadati, avrete magari sbagliato la password? Riprovate!… ancora non va? Allora il nome utente!… niente?

Niente paura, il problema è Ubuntu! Un bug noto e risolvibile, scovato dalla versione 10.04, in cui potreste incappare dopo l’aggiornamento del sistema o del kernel.
Alcuni mesi fa la questione ci fu posta da un ragazzo del gruppo Facebook del Roma2LUG. Unica possibilità di accesso era la modalità Gnome failsafe… decisamente scomoda! La sua personale risoluzione è stata reinstallare tutto ciò che ha a che fare con le GLX (nel suo caso libgl1-mesa-dri, libgl1-mesa-glx, libglitz-glx1, nvidia-173-kernel-source), ma la rete ci segnala che non si tratta di una risoluzione univoca.
A questo punto non ci è rimasto che rimboccarci le maniche e scavare, scavare, scavare… ed infine scovare, tra forum e assistenze varie, una procedura generica ed efficace su diversi modelli.

Prima di tutto, una condizione è necessaria: il terminale (ctrl+alt+F1) durante il loop deve essere perfettamente funzionante! Se così non fosse, da subito il consiglio è di reinstallare l’intero sistema, poiché il problema è ben più grave!
Passiamo ai primi tentativi di base: disinstallare e reinstallare gdm. Già qui il popolo di internet si divide, ad alcuni risolve, altri incappano in diverse bash riportanti errori critici.
Se fate parte della seconda schiera, non scoraggiatevi! Provate invece a creare un nuovo utente:

ctrl+alt+f1 per entrare nel terminale
sudo adduser NOME 
sudo adduser NOME admin
ctrl+alt+f7
per tornare al login

e provate a loggare con l’utente nuovo… nel caso funzionasse, il problema andrà pazientemente scovato nelle infinite impostazioni dell’utente, di cui non parleremo oggi.
Altrimenti, se nulla avrà funzionato, prima di formattare, potete provare una reinstallazione completa della parte grafica del sistema!

sudo apt-get remove --purge gdm*
sudo apt-get update
sudo apt-get upgrade
autoremove
sudo apt-get install ubuntu-desktop
reboot

Questa sembra la procedura che mette d’accordo e con il cuore in pace il 90% dei linuxiani di tutto il mondo. Addirittura alcuni annunciano una riduzione delle risorse occupate post-boot! A voi la tastiera dunque, comunicateci la vostra esperienza!

Tengo a ringraziare http://forum.ubuntu-it.org per le varie discussioni cui è stato estrapolato questo articolo e Daniele Angelucci per averci segnalato inizialmente il problema e la sua personale risoluzione poi!

Gabriele G.

How To: Install Linux on MarsBoard with Berryboot

Articoli Leave a reply

marsboard_a10MarsBoard is a MiniPC, just like the more famous Raspberry PI or the more classic BeagleBoard. Its intent is to provide the capability of a normal computer in a very small space. Marsboard mounts a Cortex A8 CPU operating at 1GHz, a Mali400 GPU and 1GB of RAM. All of this just in the space of a business card.

The problem with the MarsBoard is that it is a pretty young project and it lacks in documentation. I had never managed to install Linux on the external memory until I used the Berryboot launcher. From now on I will explain how to use this tool and install Linux on the MicroSD.

The only prerequisite you need to have is a working installation of Android on the NAND flash of the board. To achieve this, download this version of LiveSuit (for Windows only) and install one of the two images present on this page.

The steps for installing Linux through Berryboot are the following (remember to keep the LAN cable plugged in the board all the time):

  1. download the Berryboot application for Android from this website. You have to install it on the board. In order to accomplish this,  you can choose between downloading it directly from Android using the in-built browser or downloading it in your computer and then use an USB pendrive;
  2. once installed on the Marsboard, remove (eventually) any attached pendrive and insert the MicroSD where you want to install Linux;
  3. start the Berryboot application. You will have this screen:
    Berryboot_SD_card_writer_appPush “Write image to SD card” (see below if you have problems with this step). Do not uncheck the above entry;
  4. when the process of installation ends (it takes approx 1-2 minutes) reboot the board keeping the MicroSD in and cross your fingers! When it starts you should see this screen:
    Berryboot_installation_step1
    If you can see it, sigh with relief, worst is over;
  5. now you will be asked to install the Berryboot loader on the external memory. Follow the on-screen instructions (they are very easy: next -> next -> ok -> wait a moment -> ok again -> blah blah blah :)) and choose “mmcblk0” as destination drive. Probably you will be asked to update the loader too; do it and wait for the board to reboot.

After all these steps you should see a window with an empty box. This is the place where you will find your distros after having downloaded them. To do this, enter the Berryboot menu editor (image below) and push “Add OS“.

Berryboot_menu_editor

There’s a selection of installable distros; select what you want and wait until it’ll have been downloaded. Now press “Exit“, again from the menu editor and wait for the reboot. After that you will see your distro, ready to start.

Credits:
http://www.marsboard.com/forums/viewtopic.php?f=2&t=1220#p1269
http://linux-sunxi.org/Cubieboard/FirstSteps

PS:
If you encounter crash of the program during point 3, try installing Linux following the guide on this page. This procedure doesn’t make my Marsboard boot up, but, at least, it allows me to successfully complete the Berryboot installation.

Adb su Ubuntu non si avvia: risolviamo insieme

Articoli Leave a reply

Il titolo di questo articolo coincide con una affermazione che ultimamente è stata pronunciata spesso da persone che si presentano nella nostra auletta, per cui abbiamo pensato bene di farne un articolo, sperando di aiutare le tante persone che vogliono programmare su Android su ambiente linux. Innanzitutto vediamo in dettaglio il problema: una volta istallato eclipse con relativo plug-in per programmazione android e la android-sdk  in apparenza funziona tutto (macchine virtuali, librerie, ecc… ) però se si prova a connettere un dispositivo al pc per provare la nostra applicazione senza passare per macchine virtuali ci si presenta questa schermata:

Schermata del 2013-05-25 11:32:05

In poche parole il dispositivo non viene riconosciuto da adb, il motivo per cui si verifica questo è che probabilmente il server locale di adb non è stato avviato con i permessi di root, per cui bisogna andare nella directory dove è presente adb e dare i seguenti comandi:

sudo ./adb kill-server
sudo ./adb start-server

Risultato?

Schermata del 2013-05-25 11:45:47