☠ non compilate KDE 4 oggi ☠

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.

teschio.jpg

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

33 pensieri su “☠ non compilate KDE 4 oggi ☠

  1. 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

  2. io mi sorprendo della facilità con cui un unico processo impazzito possa mettere in ginocchio Linux…

    ulimit… Dovrebbero essere le distro a configurarlo, pero’ in un ambiente desktop praticamente monoutente in effetti non ha molto senso.

  3. 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.

  4. 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).

  5. 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.

  6. thunder teaser quella raccomandazione NON può valere ora che le kdelibs sono in freeze e già rilasciate come realease candidate… :|

  7. 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.

  8. @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 :)

  9. 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 ;)

  10. 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.
    :)

  11. 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

  12. Ma io ho compilato stamattina e non ho avuto problemi… forse i cambiamenti sono avvenuti più tardi?

  13. 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…

  14. 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 …

  15. 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?

Lascia un commento

Inserisci i tuoi dati qui sotto o clicca su un'icona per effettuare l'accesso:

Logo WordPress.com

Stai commentando usando il tuo account WordPress.com. Chiudi sessione / Modifica )

Foto Twitter

Stai commentando usando il tuo account Twitter. Chiudi sessione / Modifica )

Foto di Facebook

Stai commentando usando il tuo account Facebook. Chiudi sessione / Modifica )

Google+ photo

Stai commentando usando il tuo account Google+. Chiudi sessione / Modifica )

Connessione a %s...