Torna indietro   Hardware Upgrade Forum > Software > Programmazione

TCL 65C8L, la recensione del SQD-Mini LED da 4400 nit misurati
TCL 65C8L, la recensione del SQD-Mini LED da 4400 nit misurati
La tecnologia SQD-Mini LED di TCL arriva sul taglio da 65 pollici con la serie C8L: 2040 zone, pannello WHVA 2.0 e un picco che alle rilevazioni delle sonde tocca i 4400 nit nel profilo Filmmaker e un HDR quasi perfetto
MSI Maestro 500 Wireless: ANC e 90 ore di autonomia a 70 euro
MSI Maestro 500 Wireless: ANC e 90 ore di autonomia a 70 euro
Wireless 2.4 GHz, Bluetooth 5.4, cancellazione attiva del rumore, design pieghevole e un'autonomia che mette in imbarazzo prodotti che costano il doppio. Le Maestro 500 non eccellono in nulla, ma offrono tutto. E a questo prezzo è difficile chiedere di più
NL-LC1 è il primo dissipatore a liquido AIO di Noctua: silenzio è la parola d'ordine
NL-LC1 è il primo dissipatore a liquido AIO di Noctua: silenzio è la parola d'ordine
Dopo anni di attesa e una lunga fase di sviluppo, Noctua entra nel mercato dei dissipatori a liquido AIO con la nuova serie NL-LC1. Forte dell'esperienza maturata nel raffreddamento ad aria, l'azienda austriaca promette di portare la propria filosofia fatta di qualità costruttiva, attenzione ai dettagli e silenziosità anche in questo segmento. Abbiamo provato il nuovo sistema per scoprire se riesce a distinguersi in un mercato ormai molto competitivo.
Tutti gli articoli Tutte le news

Vai al Forum
Rispondi
 
Strumenti
Old 11-11-2010, 13:52   #1
yngwie21
Junior Member
 
Iscritto dal: Nov 2010
Messaggi: 3
[C] allocazione dinamica(e non) limitata

Salve a tutti!

Ho realizzato un programmino in C che effettua una ricerca di soluzioni espandendo ricorsivamente un albero. Per far questo, ad ogni nuova espansione di un nodo creo altri nodi dinamicamente (malloc() ) fino a che la ricerca non termina con successo.

Quando la soluzione è a profondità accettabile non vi sono problemi visto che il programma termina correttamente restituendo la soluzione corretta, mentre quando la soluzione è ad una profondità eccessiva il programma non termina correttamente (crasha).

Ogni nodo occupa 88 byte... le ricerche più complesse arrivano a creare parecchie migliaia di istanze in memoria. Il crash si verifica a 21000 nuovi nodi allocati dinamicamente, sotto winsows, col dev C++ , mentre col gcc di linux arriva a 81000 istanze dopo di che termina col seguente messaggio "segmentation fault".

Pensavo fosse solo una questione di allocazione dinamica relativa a malloc() e quindi al limitato spazio della heap, ma mi sono accorto che non è cosi poichè ottengo gli stessi risultati se in un qualsiasi programma istanzio (non dinamicamente) un vettore delle dimensioni succitate. Ad esempio :

struct nodo N[21000]

dove la struct nodo è di dimensione 88 byte, genera errori.

Come posso risolvere questo problema?
E' possibile dare al programma maggior spazio?
Se SI questo implica delle impostazione del compilatore o del sis. op.?


Grazie in anticipo per le risposte!
yngwie21 è offline   Rispondi citando il messaggio o parte di esso
Old 11-11-2010, 14:56   #2
sottovento
Senior Member
 
L'Avatar di sottovento
 
Iscritto dal: Nov 2005
Città: Texas
Messaggi: 1722
Spannometricamente: hai un crash dopo aver creato circa 21000 nodi, dove ogni nodo occupa 100 bytes. Quindi hai allocato 2100000 bytes, cioe' 2 Mb.
Per i computer attuali non e' poi cosi' tanto. Io cercherei da un'altra parte.
Sei sicuro al 100% delle tue ricerche? Potrebbe essere che c'e' un bug che si verifica dopo il suddetto numero di passaggi?

Inoltre: se il problema e' davvero e' la mancanza di memoria, devo supporre che non hai fatto controlli! (in azienda viene considerato errore da lapis rosso), vale a dire:
Codice:
buf = malloc (100);
if (buf == NULL)
{
   // Gestisci l'errore. Se non sai come gestirlo, segnala l'errore in qualche modo ed esci!!!
}
else
{
   // Usa pure la tua memoria
}
Se hai fatto questi controlli (correttamente) non dovresti andare in crash, giusto? Quindi, se li hai fatti, non stiamo parlando di mancanza di memoria.
Se non li hai fatti, non sai distinguere il problema, quindi mettili.

Una volta aggiunti, fai girare l'applicazione sotto debugger ed analizza i tuoi puntatori al momento del crash. E' probabile che manchi una condizione particolare...


Quote:
Originariamente inviato da yngwie21 Guarda i messaggi
Salve a tutti!

Ho realizzato un programmino in C che effettua una ricerca di soluzioni espandendo ricorsivamente un albero. Per far questo, ad ogni nuova espansione di un nodo creo altri nodi dinamicamente (malloc() ) fino a che la ricerca non termina con successo.

Quando la soluzione è a profondità accettabile non vi sono problemi visto che il programma termina correttamente restituendo la soluzione corretta, mentre quando la soluzione è ad una profondità eccessiva il programma non termina correttamente (crasha).

Ogni nodo occupa 88 byte... le ricerche più complesse arrivano a creare parecchie migliaia di istanze in memoria. Il crash si verifica a 21000 nuovi nodi allocati dinamicamente, sotto winsows, col dev C++ , mentre col gcc di linux arriva a 81000 istanze dopo di che termina col seguente messaggio "segmentation fault".

Pensavo fosse solo una questione di allocazione dinamica relativa a malloc() e quindi al limitato spazio della heap, ma mi sono accorto che non è cosi poichè ottengo gli stessi risultati se in un qualsiasi programma istanzio (non dinamicamente) un vettore delle dimensioni succitate. Ad esempio :

struct nodo N[21000]

dove la struct nodo è di dimensione 88 byte, genera errori.

Come posso risolvere questo problema?
E' possibile dare al programma maggior spazio?
Se SI questo implica delle impostazione del compilatore o del sis. op.?


Grazie in anticipo per le risposte!
__________________
In God we trust; all others bring data
sottovento è offline   Rispondi citando il messaggio o parte di esso
Old 11-11-2010, 16:02   #3
yngwie21
Junior Member
 
Iscritto dal: Nov 2010
Messaggi: 3
Non è un problema di controlli (che cmq ho fatto) infatti come avevo spiegato prima ho lo stesso problema se dichiaro un array di dimensione di strutture di 21000 elementi.
yngwie21 è offline   Rispondi citando il messaggio o parte di esso
Old 11-11-2010, 16:51   #4
GByTe87
Senior Member
 
L'Avatar di GByTe87
 
Iscritto dal: Mar 2007
Città: Milano Beach
Messaggi: 1696
Magari dico una cazzata.

Provato a settare ulimit (in particolare per quato riguarda lo stack, per le variabili statiche) a valori più alti?

Bye!
__________________
~ Cthulhu: MacBookPro 13.3" ~ Azathoth: D510MO
GByTe87 è offline   Rispondi citando il messaggio o parte di esso
Old 11-11-2010, 17:30   #5
yngwie21
Junior Member
 
Iscritto dal: Nov 2010
Messaggi: 3
Quote:
Originariamente inviato da GByTe87 Guarda i messaggi
Magari dico una cazzata.

Provato a settare ulimit (in particolare per quato riguarda lo stack, per le variabili statiche) a valori più alti?

Bye!
Ma ulimit, che io sappia, può essere usato se opportunamente settato per fare in modo che in caso di errori si generi un dump nella RAM di dimensione illimitata. Ha cmq a che vedere con la fase di debug.
yngwie21 è offline   Rispondi citando il messaggio o parte di esso
Old 11-11-2010, 22:09   #6
Supdario
Member
 
Iscritto dal: Mar 2008
Messaggi: 267
Quote:
Originariamente inviato da yngwie21 Guarda i messaggi
Per far questo, ad ogni nuova espansione di un nodo creo altri nodi dinamicamente (malloc() ) fino a che la ricerca non termina con successo.
Ti sei assicurato che una volta che il nodo non è più utile, venga rimosso dalla memoria con la funzione free()?
Supdario è offline   Rispondi citando il messaggio o parte di esso
Old 11-11-2010, 23:41   #7
WarDuck
Senior Member
 
L'Avatar di WarDuck
 
Iscritto dal: May 2001
Messaggi: 13002
Non è che il problema sia di diversa natura? Magari potrebbe essere un accesso in memoria sbagliato...

Sotto Linux usa l'ottimo Valgrind, ti saprà aiutare .
WarDuck è offline   Rispondi citando il messaggio o parte di esso
Old 12-11-2010, 06:58   #8
sottovento
Senior Member
 
L'Avatar di sottovento
 
Iscritto dal: Nov 2005
Città: Texas
Messaggi: 1722
Quote:
Originariamente inviato da yngwie21 Guarda i messaggi
Non è un problema di controlli (che cmq ho fatto) infatti come avevo spiegato prima ho lo stesso problema se dichiaro un array di dimensione di strutture di 21000 elementi.
E' sempre piu' probabile che ci sia un piccolo bug nel software. Come suggerito da WarDuck, usa Valgrind oppure fai girare l'applicazione sotto debugger, immagino che troverai il crash facilmente.

In alternativa, posta il codice qui
__________________
In God we trust; all others bring data
sottovento è offline   Rispondi citando il messaggio o parte di esso
 Rispondi


TCL 65C8L, la recensione del SQD-Mini LED da 4400 nit misurati TCL 65C8L, la recensione del SQD-Mini LED da 440...
MSI Maestro 500 Wireless: ANC e 90 ore di autonomia a 70 euro MSI Maestro 500 Wireless: ANC e 90 ore di autono...
NL-LC1 è il primo dissipatore a liquido AIO di Noctua: silenzio è la parola d'ordine NL-LC1 è il primo dissipatore a liquido A...
Boox Go 10.3 (Gen II) Lumi: il tablet e-ink con Android 15 e penna, dal prezzo super Boox Go 10.3 (Gen II) Lumi: il tablet e-ink con ...
Gigabyte MO32U24 OLED: il 4K a 240Hz su un pannello OLED ideale per il gaming Gigabyte MO32U24 OLED: il 4K a 240Hz su un panne...
Il supercomputer più potente al m...
VSCO lancia Studio Pro su iOS: batch edi...
GPT-NL, il modello linguistico olandese ...
Apple Watch SE 3 crolla a 199€: il prezz...
'Non c'è spazio per console econo...
AutoUncle fotografa il mercato dell'usat...
Robase, il malware che ruba interi gioch...
DeepSeek invece di OpenAI in Copilot Cow...
Matter 1.6 rivoluziona la smart home: co...
ASUS ROG Strix LC IV: prestazioni e impa...
Gemini Code Assist e Gemini CLI danno l'...
Windows: problemi di avvio per alcune ap...
QuEra sbaraglia tutte le previsioni e pr...
Reno16 Series ufficiale: OPPO annuncia l...
Previsioni sempre più fosche per il 2026...
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:45.


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