Aggiornamento: come indicato da Riccardo “ruphy” Iaconelli (aggiornalo il blog!) già da ieri sera è tutto tornato a posto e si può tornare a compilare senza alcun timore. Grazie Ruphy per aver sistemato così velocemente, siamo dei privilegiati ad averti tra i lettori! :)
—
Se provate a compilare KDE Base da svn, magari seguendo la guida “KDE 4 per Ubuntu Gutsy, in un paio d’ore ;)“, avrete una sgradevole sorpresa, come segnalato anche da alcuni commenti a quella pagina.
All’improvviso, e nel giro di pochi secondi, il compilatore dovrebbe mettersi ad utilizzare tutta la vostra memoria fino ad esaurirla, costringendovi ad un bel reset. Seguite questo spazio, appena si sistemano le cose sarò il primo a dare nuovamente il “via libera”.
Fatemi sapere se a differenza da me e da chi ha avuto il problema voi la passate liscia, ma ad ogni modo come nel famigerato caso di “Come uccidere Linux in tre secondi” io mi sorprendo della facilità con cui un unico processo impazzito possa mettere in ginocchio Linux…
Si è anche se fate come me che ho lanciato più volte sudo kdesvn-build arrivando al 100% vi si blocca lì è non va avanti XD
Bhwa ha ha! è solo la prima parte della vendetta per il tuo tradimento !
ulimit… Dovrebbero essere le distro a configurarlo, pero’ in un ambiente desktop praticamente monoutente in effetti non ha molto senso.
Io ho avuto lo stesso problema, il sistema è diventato una mega lumaca ma non si è bloccato. Lasciandolo fare per qualche secondo poi, esce e ritorna alla normalità senza fare alcun reset brutale.
A me non si pianta, semplicemente si rifiuta di compilare riferendo “Nessun file o directory”
Il problema nasce dalla compilazione di “kdebase/workspace/plasma/applets/digital-clock”, per un problema introdotto nella revisione 735561. credo.
Per compilare forzando un comportamento corretto:
svn up -r 735549 kdebase/workspace/plasma/applets/digital-clock
A me dopo 4 minuti il gcc satura tutta la ram ed a quel punto (un po’ troppo tardi, imho) parte l’OOM killer che killa il gcc fermando la compilazione. Si potrebbe aggiungere un modulo di controllo a hal/kded4 o quello che è per intervenire (killando) prima che lo faccia il kernel (si risparmierebbe un po’ di “piantosità” del sistema quando la ram scarseggia).
Linux è un sistema estremamente resistente, una condizione limite nel quale è costretto a fare molto swapping lo può portare a rallentare e a sembrare non responsivo. Esistono comunque le Magic SysRq Keys (http://en.wikipedia.org/wiki/Magic_SysRq_key) che permettono di mandare comandi direttamente al kernel, per riprendere la situazione in mano. ad esempio SysRq+k e SysRq+f potrebbero essere un idea in simili situazioni.
E te pareva, proprio oggi che volevo ricompilare da capo :D
C’è scritto nella guida avanzata! NON compilate il lunedì, perché avvengono modifiche di rilevanza maggiore in kdelibs!
non sarà perchè gc è release candidate?
Belle ste SysRq :D
Cmq stanno lavorando come pazzi ‘sti sviluppatori :-)
thunder teaser quella raccomandazione NON può valere ora che le kdelibs sono in freeze e già rilasciate come realease candidate… :|
Su techbase c’è scritto da mesi di evitare di compilare il lunedì perché è il giorno in cui ci sono più cambiamenti e la probabilità di errori/crash/bug gravi è molto alta.
@loopback:
Chiediamo al distributore se “si potrebbe avere una configurazione predefinita che non faccia morire il sistema operativo con una GIF animata, grazie?” :)
@enricoros:
Preziosa segnalazione… mi fa piacere leggerti qui :)
@Alessandro:
Beh direi che la configurazione predefinita per distro da desktop sarebbe quella di evitare cose del genere, non credo che nessuno debba conoscere questi (per me interessantissimi) “nerdismi” per poter usare il PC :)
@Thunder Teaser:
@Giovanni:
@Tyler:
A parte che le librerie sono ormai praticamente stabili, qui si parla di KDE Base, non KDE Libs :)
usando i precompilati di suse ovviamente nessun problema..al massimo si blocca la compilazione nel build service! ^__^
Di solito questi memory leaks sono causati dal compilatore c++ : in passato è capitato compilando alcune versioni di wine , amule , blender …
Il rimedio più indicato per evitare la scocciante attesa – a volte veramente lunga – necessaria finchè il sistema torni in sè , è usare le Magic SysReq Keys come correttamente indicato da Alessandro et altri ;)
Ciao.
Ho avuto questo bug oggi e lo ho anche segnalato
agli sviluppatori di kde.
NON è assolutamente vero che fa crashare il pc
perlomeno non il mio,vi spiego come fare
appena parte il processo killer(inizia tra il 70 e il 90%
della compilazione di kdebase),attendete fiduciosi…
il sistema inizia a swappare di brutto(si sentono sinistri
rumori dell’hd) quando il mouse inizia a scattare siete
quasi al limite,allora premete ctrl-alt-sysrq-e,questo killerà TUTTI i processi eccetto X e init.
Vi apparirà quindi una bella shell,riavviate i processi
principali(udev,acpi,hal,messagebus,etc)
e vi ritrovate linux perfettamente funzionante.
Ovviamente se non avete magic sysrq attivato nel kernel..che dio vi assista.
:)
un unico processo?
e le fork bomb allora ;-)
ah… sebas….
provvedo.
@ felipe: compreso, non avevo capito il problema! -.-“
Non lo hanno ancora fixato :(
Ho compilato venerdì seguendo la guida (e aggiungendo amarok). Premetto che mi piace molto il progetto KDE4 (la riorganizzazione delle librerie e i suoi pilastri costitutivi phonon, plasma, solid, ecc), anche se sono sempre stato legato a GNOME. Bene, grazie per la guida, ha compilato tutto senza errori!!
Però, domanda da profano: è giusto che il sistema sia super spoglio, senza un systray, senza apps e con amarok ridotto a poco più che uno scheletro? E’ perchè è tutto ancora in beta o sono io che ho dimenticato/sminchiato qualcosa? E poi, ci sono applicazioni aggiuntive da compilare, per provarle un po’? Un saluto a tutti
Ma io ho compilato stamattina e non ho avuto problemi… forse i cambiamenti sono avvenuti più tardi?
ho trovato il problema pare…. sto tentando di risolvere, posto qui non appena ho fatto.
pare sia un dialogo .ui un po’ incasinato.
Ma quale Magic SysRq Keys! E’ inammissibile che basti una stupidissima gif (se non vi ricordate a quale mi riferisco se volete posso linkarvela) o un qualsiasi processo che satura la ram per uccidere il sistema operativo, come è inammissibile dover ricorrere alle magic sysrq keys per queste cose. Gli sviluppatori dovrebbero essere un pochino più coscienziosi, anziché fregarsene perché tanto per un uso desktop non è considerato un problema rilevante. Posso capire in una distro rustica, dove sta all’utente fare hardening e configurarsi tutto come meglio crede, ma in ubuntu…
Qualcuno ci avvisi quando possiamo tornare a compilare!! :D
ora va, compilate pure
Confermo. Anche io stamattina sono riuscito a compilare kdebase.
pollycoke… aggiorna…
Sono d’accordo, che non sia accettabile che basti un processo che saturi le risorse per mettere in ginocchio un sistema serve un gestore di memoria che impedisca questi problemi. Io comincio ad essere un po’ stufo di vedere il mio caro vecchio desktop, un P4 1.4 Ghz e 512 di ram freezarsi perchè girano un paio di programmi pesanti …
ebbravo filippo ;-)
Scusate, io ho compilato e funziona. Solo che non riesco a spostare la barra delle applicazioni aperte sul pannello in basso. E’ come bloccata a metà schermo (non vicino al menu K) e non c’è verso di muoverla… Qualcuno sa come fare?