Newsgroup: it.comp.os.linux.development
Titolo: strano comportamento dell' emulatore di terminale

Salve a tutto il ng, scusate se ho postato anche su .iniziare, ma ho 
pensato che sarebbe stato piu' opportuno qui... Faccio un 
copia-incolla.
Mentre giochicchiavo con g++ su Mandrake 9, ho 
notato uno strano comportamento del sistema (sembra che finisca tutta 
la RAM, compresa quella virtuale) se vado ad eseguire , dopo averlo 
compilato, questo programma in C++, che (se non erro) dovrebbe dare uno 
stack overflow (per la mancanza di un controllo per un eventuale input 
negativo su ''int fatt(int n)'' ):
#include<iostream.h>
#include<stdlib.h>
int fatt(int n);
int main()
  {
   fatt(-1);
   return 0;  
  }
int fatt(int n)
  {
   if (n==0)
    {
      return 1;
    }
   return (n*fatt(n-1));
  }
Avrei potuto anche chiamare fatt(2) ad esempio , e nella funzione 
scrivere return (n*fatt(n)), ma non e' questo il punto.
Il punto e' che, compilato, (con g++ stoverflow.cpp - o stoverflow):
--se lo eseguo da una console virtuale con CTRL+F2 ad esempio, mi da'      
     semplicemente un segmentation fault e torna al prompt (anche se pen
savo che avrebbe scritto stack overflow, ma vabbe')
--se lo eseguo da una finestra di terminale sotto X , io ho usato 
Konsole sotto KDE3, il sistema dopo un attimo, diventa  
inutilizzabile : non si possono neanche switchare le console con 
ALT+F2 ecc, il mouse si incolla, come se finisse la RAM; su un Pentium 
III 1GHz 384 Mb di RAM, mi sembra strano...  :)
Cio' pero' non mi succede su Debian Woody, che usa g++ 2.95.4, mentre 
Mandrake 9 ha g++ 3.2.
Non penso di essere l'unico utente di Mandrake 9 che debba dare 
Fondamenti di Informatica II
e corra il rischio di trovarsi costretto a dover riavviare con la 
sequenza magica  ALT +SYSREQ + R S E I U B  (se non con un reset) se fa 
una svista che lo porta ad uno stack overflow!!! (pero' il programmino 
lo sapevo gia' che avrebbe dato uno stack overflow...) 
Mi sembra strano che sia un problema di compilatore, forse e' X con 
Mandrake che ha qualche opzione strana, o g++ che ha qualche alias 
impostato che io non so... non so cosa pensare...
Qualcuno mi saprebbe spiegare come fare per evitare questo fastidioso 
problema? Chiaramente senza soluzione brutale tipo abbandonare Mandrake 
di botto e passare integralmente a Debian, che ho iniziato a provare 
solo pochi giorni fa, e non ti 'imbocca' come Mandrake...
Aspetto speranzoso una vostra risposta...
-- 
           salvuz
     POST FATA RESVRGO
 Linux registered user #291700 | machine #174619

            salvuz
ciauz

sbirish wrote:

Perfetto, ho settato con ulimit -s 1024 la dimensione dello stack a 1024 
Kbytes , e ora da' segmentation fault senza mangiarsi tutta la RAM. 
Sono curioso di vedere con Debian quanto valgono i limiti...
Grazie per la dritta!


 Mandrake 9 ha g++ 3.2.
Effettivamente, ulimit -s su terminale, su Mdk(non ho Debian) dà 8192, su
console sotto X dà unlimited. E se non lo esegui da terminale ma da
Konqueror, ad esempio? Effettivamente tra i padri di konqueror c'è qualche
shell, ma viene usata per eseguire script, quindi non legge niente
all'avvio(solo il file indicato da $BASH_ENV, cioè nessuno). Quindi che
accade?
-- 
cat <<EOF
Paolo Giarrusso, aka Blaisorblade(togliere solo REMOVEONLYTHIS per rispondere)
Kernel 2.4.19 on an i686; Linux registered user n. 292729
EOF

 
Beh, io ora ho inserito in /home/salvuz/.bashrc la riga
ulimit -Ss 8192
e, dato che .bashrc viene letto al mio login, (io uso il runlevel 3), e 
startx viene dato dalla shell che ottengo al login, e che credo 'si 
porti appresso' anche kdeinit, ho che lo stack, anche sotto X, e' 
limitato (soft limit, per l'opzione S) a 8 MB, come verifico da 
Konsole, ma anche da RXvt, GNOME terminal, Xterm ecc, insomma da un 
qualsiasi emulatore di terminale sotto X, percio' anche eseguendo 
stoverflow da Konqueror, non accade nulla alla RAM, quindi ritengo che  
'stoverflow' termini per stack overflow come quando lo eseguivo da 
console virtuale con per es. ALT+F2. Con Debian Woody questo 
comportamento e' il default, anche se non ho verificato cosa contenga 
.bashrc, ma insomma, in questo modo ho risolto... La cosa strana e' che 
mentre man bash spiega che ulimit -s equivale a ulimit -Ss, in Mandrake 
9 equivale a ulimit -Hs, cioe' limite hard, che non puo' essere 
modificato a meno di cambiare .bashrc, poi fare logout e login... 
Meglio specificare S o H esplicitamente...


 ulimit -Ss 8192
un modo migliore per forzare questo limite in tutto il sistema
e` usare limits.conf di PAM ( /etc/security/limits.conf, su debian,
su altre pseudo-distro ( no flame tks ) non saprei ).
inoltre nei relativi file in /etc/pam.d/{login, ssh, etc} devi mettere
session required pam_limits.so ( se nn c`e` gia` di default ).
ciao :)
vjt
-- 
pub 1024D/F04476A2 :: 6807 EEA5 7F97 AC9A D8EF  AE73 64CD 71A2 F044 76A2
http://suxserv.sourceforge.net/vjt.asc
        ||  This signature has         
Free advertisement: 
http://www.freebsd.org/
   ||      Super Cow Powers.