Torna indietro   Hardware Upgrade Forum > Software > Programmazione

NZXT H9 Flow RGB+, Kraken Elite 420 e F140X: abbiamo provato il tris d'assi di NZXT
NZXT H9 Flow RGB+, Kraken Elite 420 e F140X: abbiamo provato il tris d'assi di NZXT
Nelle ultime settimane abbiamo provato tre delle proposte top di gamma di NZXT nelle categorie case, dissipatori e ventole. Rispettivamente, parliamo dell'H9 Flow RGB+, Kraken Elite 420 e F140X. Si tratta, chiaramente, di prodotti di fascia alta che si rivolgono agli utenti DIY che desiderano il massimo per la propria build. Tuttavia, mentre i primi due dispositivi mantengono questa direzione, le ventole purtroppo hanno mostrato qualche tallone d'Achille di troppo
ASUS ROG Swift OLED PG34WCDN recensione: il primo QD-OLED RGB da 360 Hz
ASUS ROG Swift OLED PG34WCDN recensione: il primo QD-OLED RGB da 360 Hz
ASUS ROG Swift OLED PG34WCDN è il primo monitor gaming con pannello QD-OLED Gen 5 a layout RGB Stripe Pixel e 360 Hz su 34 pollici: lo abbiamo misurato con sonde colorimetriche e NVIDIA LDAT. Ecco tutti i dati
Recensione Nothing Phone (4a) Pro: finalmente in alluminio, ma dal design sempre unico
Recensione Nothing Phone (4a) Pro: finalmente in alluminio, ma dal design sempre unico
Nothing Phone (4a) Pro cambia pelle: l'alluminio unibody sostituisce la trasparenza integrale, portando una solidità inedita. Sotto il cofano troviamo uno Snapdragon 7 Gen 4 che spinge forte, mentre il display è quasi da top dig amma. Con un teleobiettivo 3.5x e la Glyph Matrix evoluta, è la prova di maturità di Carl Pei. C'è qualche compromesso, ma a 499EUR la sostanza hardware e la sua unicità lo rendono un buon "flagship killer" in salsa 2026
Tutti gli articoli Tutte le news

Vai al Forum
Rispondi
 
Strumenti
Old 16-02-2005, 19:53   #1
fracarro
Senior Member
 
L'Avatar di fracarro
 
Iscritto dal: Jul 2002
Messaggi: 869
[C problemi con diverse versioni del gcc]

Salve a tutti,
ho un problema che mi sta facendo impazzire. Un amico mi ha fornito un codice C per la creazione di alcune istanze di un problema su grafi. Ora compilando il codice ( con le opzioni -Wall -ggdb3 ) sotto linux suse 9,1 ( gcc versione 3.3.3) non vengono riscontrati problemi o warning e l'output del programma è perfetto. Copiando il codice sotto un altro linux con la versione gcc version 3.4.2 20041017 (Red Hat 3.4.2-6.fc3) la compilazione va a buon fine ( nessun warning ) ma ci sono due procedure nel codice che mi danno problemi ( una cicla all'infinito e l'altra va in segmentation fault). Ora se il programma contiene accessi in zone di memoria non allocata (ragion per cui mi da la seg.fault) come mai su un computer il problema NON si presenta MAI e sull'altro SEMPRE? Ci sono altri flag in compilazione che posso utilizzare per "aumentare" la trasportabilità del codice o stabilire qual'è la causa del problema? Grazie per l'aiuto.

P.S. E' possibile installare la versione 3.4 del gcc sulla suse 9.1?
fracarro è offline   Rispondi citando il messaggio o parte di esso
Old 17-02-2005, 08:58   #2
AnonimoVeneziano
Senior Member
 
L'Avatar di AnonimoVeneziano
 
Iscritto dal: Aug 2001
Città: San Francisco, CA, USA
Messaggi: 13827
L'accesso a memoria non allocata su un sistema non dovrebbe mai verificarsi , poichè il risultato di tale accesso è imprevisto.

Per qualche motivo su un sistema non da problemi , e su un altro da Seg fault.

In ogni caso se tale accesso nel tuo programma c'è devi toglierlo per assicurarne il corretto funzionamento su ogni sistema
__________________
GPU Compiler Engineer
AnonimoVeneziano è offline   Rispondi citando il messaggio o parte di esso
Old 17-02-2005, 15:34   #3
fracarro
Senior Member
 
L'Avatar di fracarro
 
Iscritto dal: Jul 2002
Messaggi: 869
si sono riuscito a trovare e modificare la parte di codice che creava la seg fault ma tuttavia non riesco a capire com'è possibile che su una macchina venga segnalato l'errore e su un'altra no ( ho controllato le due esecuzioni del programma, SONO IDENTICHE, ovviamente, ma su una l'accesso alla zona di memoria non allocata da problemi e sull'altra no, bo?. Facendo delle ricerche ho scoperto il flag -lefence che dovrebbe dare ulteriori informazioni sui problemi di accesso in memoria o qualcosa del genere. Ebbene su un programma funzionante ho provato questo flag e voilà , mi segnalava una segmentation fault nell'allocazione della memoria per un array all'inizio del programma. Posso capire che usando flag come -O4 si possono verificare problemi nel codice per via delle ottimizzazioni ma non con il flag -lefence perchè?. Qualcuno sa darmi delucidazioni a riguardo? Grazie
fracarro è offline   Rispondi citando il messaggio o parte di esso
Old 17-02-2005, 15:55   #4
ilsensine
Senior Member
 
L'Avatar di ilsensine
 
Iscritto dal: Apr 2000
Città: Roma
Messaggi: 15625
Non capisco cosa pretendi...l'accesso a memoria non inizializzata (che _è_ un errore di programmazione, e non sempre dei più banali) dà per forza risultati imprevedibili e non riproducibili tra un sistema e un altro. Può aiutarti per il debug prendere l'abitudine di inizializzare sempre la memoria (ad es. allocandola con calloc invece che con malloc; inizializzando tutte le variabili di una classe nel costruttore, ecc.), quando non è evidente l'uso che ne verrà fatto.
__________________
0: or %edi, %ecx; adc %eax, (%edx); popf; je 0b-22; pop %ebx; fadds 0x56(%ecx); lds 0x56(%ebx), %esp; mov %al, %al
andeqs pc, r1, #147456; blpl 0xff8dd280; ldrgtb r4, [r6, #-472]; addgt r5, r8, r3, ror #12
ilsensine è offline   Rispondi citando il messaggio o parte di esso
Old 17-02-2005, 16:01   #5
anx721
Senior Member
 
L'Avatar di anx721
 
Iscritto dal: Oct 2002
Città: Roma
Messaggi: 1502
mi pare che non si tratti di un semplice flag..con -lefence linki la libreria electric fence che è un memory checker:

ElectricFence uses virtual memory hardware to detect when software overruns malloc() buffer boundaries, and/or to detect any accesses of memory released by free().

quello che so che fa electric fence è che se te allochi ad esempio 10 bytes, allora e-fence alloca 2 pagine di memoria:

|-----prima pagina---|---seconda pagina---|

e se p è l'indirizzo della seconda pagina, allora ti restituisce come indirizzo dell'allocazione (p-10)


Codice:
|-----prima pagina---|---seconda pagina---|
                 ^ 
.................| (p-10)
inoltre imposta per la seconda pagina una protezione che impedisce lettura e scrittura.

in questo modo se te per errore vai oltre le dieci locazioni del tuo array, vai a finire nella seconda pagina, che è protetta, e ci sarà segmentation fault. Se non ci fosse la seconda pagina, al suo posto potebbe eserci un altra variabile del tuo programma, e l'accesso erroneo a quella variabile non sarebbe considerato errore.

Il fatto che l'errore di seg fault scatti o meno dipende quindi a anche da come viene allocata la memoria per le variabili, da qual è la configurazione della memoria in quel momento in cui fai l'accesso, per cui anche due esecuzioni di uno stesso programma possono dare esiti diverse sulla stessa macchina
__________________
Sun Certified Java Programmer
EUCIP Core Level Certified

European Certification of Informatics Professionals
anx721 è offline   Rispondi citando il messaggio o parte di esso
Old 17-02-2005, 16:03   #6
ilsensine
Senior Member
 
L'Avatar di ilsensine
 
Iscritto dal: Apr 2000
Città: Roma
Messaggi: 15625
Quote:
Originariamente inviato da fracarro
Facendo delle ricerche ho scoperto il flag -lefence che dovrebbe dare ulteriori informazioni sui problemi di accesso in memoria o qualcosa del genere
La libreria libefence (che linki tramite -lefence) serve principalmente per il debug di buffer overflow o di accessi a memoria liberata con free; funziona inserendo degli hook sulle funzioni di allocazione. E' meno utile per individuare riferimenti a memoria allocata ma non inizializzata; potrebbe incidentalmente essere di aiuto anche in questo, ma non è il suo scopo principale. Non è di aiuto per il debug degli accessi a variabili globali(*) non inizializzate, ma solo quando l'allocazione della memoria è dinamica.


(*) Per beccare le variabili locali non inizializzate, generalmente è sufficiente compilare con -Wall
__________________
0: or %edi, %ecx; adc %eax, (%edx); popf; je 0b-22; pop %ebx; fadds 0x56(%ecx); lds 0x56(%ebx), %esp; mov %al, %al
andeqs pc, r1, #147456; blpl 0xff8dd280; ldrgtb r4, [r6, #-472]; addgt r5, r8, r3, ror #12
ilsensine è offline   Rispondi citando il messaggio o parte di esso
Old 17-02-2005, 16:22   #7
fracarro
Senior Member
 
L'Avatar di fracarro
 
Iscritto dal: Jul 2002
Messaggi: 869
forse non mi sono spiegato bene. Io non vado ad utilizzare zone di memoria non INIZIALIZZATA. Il mio problema è semplicemente che se dichiaro un array in questo modo "int pippo[10]", VORREI che un accesso del tipo pippo[1000] mi dia una seg fault perchè io non ho ALLOCATO la memoria per 1000 caselle. Tuttavia come mi faceva notare anx721, se sono talmente sfortunato da beccare con quella istruzione un'altra zona di memoria allocata dal mio programma sono fregato perchè CORRETTAMENTE non mi segnalerà la seg fault. I flag -W e -Wall purtroppo non mi aiutano in questo ma potrebbe farlo la electric fence mediante la sua seconda pagina protetta. Grazie ad entrambi per le risposte (tutti sti casini per un codice che non ho scritto io, sigh!!!)
fracarro è offline   Rispondi citando il messaggio o parte di esso
Old 17-02-2005, 16:25   #8
ilsensine
Senior Member
 
L'Avatar di ilsensine
 
Iscritto dal: Apr 2000
Città: Roma
Messaggi: 15625
Quote:
Originariamente inviato da fracarro
forse non mi sono spiegato bene. Io non vado ad utilizzare zone di memoria non INIZIALIZZATA
Ah ok
Quote:
Il mio problema è semplicemente che se dichiaro un array in questo modo "int pippo[10]", VORREI che un accesso del tipo pippo[1000] mi dia una seg fault perchè io non ho ALLOCATO la memoria per 1000 caselle.
Il classico buffer overflow. Non ci sono molte difese "automatiche" se la memoria non è allocata tramite malloc (solo così le efence possono essere d'aiuto).
__________________
0: or %edi, %ecx; adc %eax, (%edx); popf; je 0b-22; pop %ebx; fadds 0x56(%ecx); lds 0x56(%ebx), %esp; mov %al, %al
andeqs pc, r1, #147456; blpl 0xff8dd280; ldrgtb r4, [r6, #-472]; addgt r5, r8, r3, ror #12
ilsensine è offline   Rispondi citando il messaggio o parte di esso
Old 17-02-2005, 16:37   #9
fracarro
Senior Member
 
L'Avatar di fracarro
 
Iscritto dal: Jul 2002
Messaggi: 869
Concludendo, se ho capito bene mi conviene compilare con i seguenti flag -W -Wall -lefence per avere warning e maggiori informazioni sugli eventuali errori di accesso in memoria, giusto? L'esempio che ho fatto prima con un allocazione statica era solo per chiarire meglio il mio problema, in realtà gli array li alloco dinamicamente con la malloc. Mi consigliate di rimpiazzare quest'ultima con la calloc? (in questo modo mi verranno segnalati eventuali accessi iin memoria a zone non inizializzate, giusto?). Un'ultima cosa, a questo punto visti i problemi che ho avuto, poichè il programma compilato con lefence mi da seg fault posso essere certo che c'è qualche altro errore di accesso alla memoria? (se mi riscrivevo il codice d'accapo facevo prima!!!)
fracarro è offline   Rispondi citando il messaggio o parte di esso
Old 17-02-2005, 16:51   #10
anx721
Senior Member
 
L'Avatar di anx721
 
Iscritto dal: Oct 2002
Città: Roma
Messaggi: 1502
la calloc serve semplicemente a inizializare a zero il blocco di memoria allocato...se il programma con e-fence ti dà errore significa che c'è un accesso di memoria illegale
__________________
Sun Certified Java Programmer
EUCIP Core Level Certified

European Certification of Informatics Professionals
anx721 è offline   Rispondi citando il messaggio o parte di esso
 Rispondi


NZXT H9 Flow RGB+, Kraken Elite 420 e F140X: abbiamo provato il tris d'assi di NZXT NZXT H9 Flow RGB+, Kraken Elite 420 e F140X: abb...
ASUS ROG Swift OLED PG34WCDN recensione: il primo QD-OLED RGB da 360 Hz ASUS ROG Swift OLED PG34WCDN recensione: il prim...
Recensione Nothing Phone (4a) Pro: finalmente in alluminio, ma dal design sempre unico Recensione Nothing Phone (4a) Pro: finalmente in...
WoW: Midnight, Blizzard mette il primo, storico mattone per l'housing e molto altro WoW: Midnight, Blizzard mette il primo, storico ...
Ecovacs Goat O1200 LiDAR Pro: la prova del robot tagliaerba con tagliabordi integrato Ecovacs Goat O1200 LiDAR Pro: la prova del robot...
Climatizzatore Inverter A++ con Wi-Fi a ...
NZXT Flex, lo 'scandalo' del PC gaming a...
Robot lavavetri in offerta su Amazon: EC...
Attenti a questo update fake di Windows ...
NIO chiede la standardizzazione di batte...
Da 80 mesi-uomo a poche ore: l'AI cambia...
In 2 settimane senza social il cervello ...
Amazon top 7 di oggi: 2 portatili intere...
SteamGPT trapela dal client Steam: ecco ...
Boom clamoroso per questo piccolo produt...
Amazon Luna saluta gli store di terze pa...
Windows Update non sarà più un incubo: M...
Stampante HP con Wi-Fi e 3 mesi di inchi...
Metro 2039 potrebbe essere il nuovo capi...
Call of Duty: Modern Warfare 4 l'uscita ...
Chromium
GPU-Z
OCCT
LibreOffice Portable
Opera One Portable
Opera One 106
CCleaner Portable
CCleaner Standard
Cpu-Z
Driver NVIDIA GeForce 546.65 WHQL
SmartFTP
Trillian
Google Chrome Portable
Google Chrome 120
VirtualBox
Tutti gli articoli Tutte le news Tutti i download

Strumenti

Regole
Non Puoi aprire nuove discussioni
Non Puoi rispondere ai messaggi
Non Puoi allegare file
Non Puoi modificare i tuoi messaggi

Il codice vB è On
Le Faccine sono On
Il codice [IMG] è On
Il codice HTML è Off
Vai al Forum


Tutti gli orari sono GMT +1. Ora sono le: 15:21.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2026, Jelsoft Enterprises Ltd.
Served by www3v