Il problema di fondo era che la chiamata JNI_CreateJavaVM produceva il segnale SIGABRT quando invocato all’interno di un altro framework, nello specifico stavo utilizzando l’SDK BoKS.

La porzione di codice interessata, a parte dovuti accorgimenti, era del tutto coerente con quanto riportato da HP al link

http://www.docs.hp.com/en/JAVAPROGUIDE/JNI_java2.html

Provando ad utilizzare i parametri di inizializzazione della VM più svariati non si è cavato un ragno dal buco, seguendo comunque le linee guida riportate qui http://www.docs.hp.com/en/JAVAPROGUIDE/JNI_java2.html#primordial, si è ipotizzato da subito un problema con lo stacksize su HP-UX, su Solaris, infatti, non erano stati riscontrati problemi di sorta.

Una sessione con tusc ha confermato quanto supposto:

La soluzione?

Un semplice export della variabile PTHREAD_DEFAULT_STACK_SIZE a 524288.

Si sarebbe anche potuta usare la chiamata pthread_default_stacksize_np(), ma poiché la parte di codice che crea i thread non è personalizzabile in quel dato SDK, l’export della variabile d’ambiente è stata l’unica soluzione attuabile.

Alla prossima!

Sulle mailing list è possibile leggere molto a riguardo, sul fatto che “normalmente” un riavvio del server X non dovrebbe essere necessario e su quanto, per un nuovo utente, possa essere semplice digitare accidentalmente la combinazione e ritrovarsi con il lavoro perso e una bella schermata di login senza sapere perché.

In effetti le ragioni sono plausibili, ma per alcuni il “normalmente”, significa aver necessità di riavviare X senza dover eseguire il kill del processo da un terminale: in passato mi sono capitate delle situazioni in cui X si è completamente congelato e con un ctrl+alt+backspace si è ripristinato il tutto senza dover riavviare l’intero sistema. Avendo l’opzione disabilitata, se il terminale (ctrl+alt+f1…f6) non risponde ai comandi allora non resta che il reset. Nel mio caso, ho preferito riabilitare l’opzione, aggiungendo al file xorg.conf (solitamente in /etc/X11) l’opzione “DontZap” ed impostandola a “false“. In proposito, riporto la sezione del mio file di configurazione:

In successivi aggiornamenti, è stata introdotta anche su HAL una disabilitazione della combinazione. Per riattivarla è sufficiente aggiungere questa entry

all’interno del file /etc/hal/fdi/policy/10-keymap.fdi

In caso il file non fosse presente, copiarlo da /usr/share/hal/fdi/policy/10osvendor

E modificarlo aggiungendo la entry di cui sopra.

Riporto di seguito il mio file keymap che funziona correttamente utilizzando entrance come login manager:

Infine, se non si sta usando l’integrazione Xorg/HAL occorrerà aggiungere una opzione nel file /etc/X11/xorg.conf all’interno della sezione keyboard

Al solito, spero che a qualcuno sia utile ;)

Il titolo vuole essere più un gioco di parole dal mio punto di vista che altro. Infatti, ho appena ricevuto da last.fm una mail che riporta:

“Your free trial to Last.fm Radio is about to end. If you’re enjoying it, why not
subscribe for only 3.00/month and continue listening to non-stop personalised
radio.

http://www.last.fm/subscribe

Best Regards,
The Last.fm Team”

Ovvero, non avrò più la possibilità di ascoltare la radio organizzata per genere gratuitamente. Ora se è vero che 3 euro al mese non sono una cifra esorbitante (neanche trascurabile visto che un server semidedicato ne costa 5) è anche vero che questa presa di posizione non vale per tutti i paesi del mondo: germania, regno unito e stati uniti continueranno a usufruire del servizio gratuitamente, poiché il bacino di utenza di questi stati garantisce proventi sufficienti dalla pubblicità. Ragionevole, ma un po’ ingiusto.

Al momento sto considerando se sottoscrivere questo abbonamento per continuare ad ascoltare la buona musica casuale che passa o se accantonarla del tutto. L’aspetto di “social network” del servizio non mi interessa più di tanto.

Vuoi vedere che non torno ad ascoltare la radio fm in casa come faccio in macchina?

La stazione sarebbe sicuramente Radio Rock ;) Tanto più che trasmettono anche in streaming :)