Newsgroup: it.comp.programmare.win32
Titolo: Problema con Dll e liberazione della memoria.

Spero che qualcuno possa chiarirmi le idee riguardo.
Ho un programma  che utilizza delle funzioni contenute  in una mia DLL
su WinNT.
Il programma chiama una funzione della DLL che alloca memoria mediante
calloc().  Il puntatore al  buffer viene  restituito al  chiamante che
provvede a liberare la memoria chiamando free().
Schematizzando
+----------------------+
|                      |
|                      |
| char* retValP = NULL |
|                      |
| ...                  |          +------------------------+
|                      |          |                        |
| retValP = dllFnc();  | -------> | char* dllFnc(void)     |
|                      | <-+      | {                      |
| ...                  |   |      |   char* retValP = NULL |
|                      |   |      |                        |
| free(retValP);       |   |      |   ...                  |
|                      |   |      |                        |
+----------------------+   |      |   retValP = calloc();  |
    testDll.exe            |      |                        |
                           |      |   ...                  |
                           |      |                        |
                           +------|   return retValP       |
                                  | }                      |
                                  |                        |
                                  +------------------------+
                                     dllUnderTest.dll
Il problema e'  che non appena viene chiamata  free() ottengo l'errore
riportato sotto.
   HEAP[testDll.exe]: Invalid Address specified to
   RtlValidateHeap( 820000, 421650 )
errore  che sparisce se  definisco un  funzione dllFree(void*)  che si
trova nella dll e chiamo quella per liberare la memoria.
E'  normale  questo comportamento?  Debuggando  il  codice ho  trovato
questo commento
/*
 * If this ASSERT fails, a bad pointer has been passed in. It may be
 * totally bogus, or it may have been allocated from another heap.
 * The pointer MUST come from the 'local' heap.
 */
nel file dbgheap.c che  sembrerebbe confermare che il comportamento e'
corretto. Ma sotto WinNT la  distinzione tra heap locale e globale non
era sparita?
Qualcuno puo' risolvermi questi dubbi? Grazie.
C:\>iao Angelo
P.S. Sulle DLL non ho trovato molti riferimenti (decenti)  in rete
     qualcuno puo' suggerirmi un buon libro che tratta di DLL & Co.
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 era sparita?
La distinzione e' sparita ed entrambi i concetti sono obsoleti.
C'e' un unico heap per ogni precesso, a cui si accede mediante le funzioni
HeapAlloc, HeapCreate, HeapFree e analoghe.
Le funzioni malloc, calloc, realloc e free non vengono mappate direttamente
sulle funzioni Win32 per gestire lo heap, masono gestite per questioni di
ottimizzazione dalla libreria CRT (C runtime library).
Se hai linkato il programma e tutte le DLL usando la CRT statica, la CRT e'
inizializzazta separatamente per ogni DLL, quindi e' come se per malloc,
free, etc (e anche per new e delete) avressi heap diversi.
Per evitare il problema basta che linkare sia l'EXE che tutte le DLL con la
versione DLL della libreria CRT; come fare dipende dal sistema di sviluppo
che stai usando.
Oppure per tutti i blocchi di memoria da passsare da una dll ad un altra usi
le funzioni di heap Win32.

questo commento
Che compilatore usi ?
Nel caso fosse VC++, hai provato a compilare NON in modalita` debug ?
Quando sei in modalita` debug, con VC++, le normali routine
malloc/calloc/free vengono reindirizzate su
_malloc_dbg/_calloc_dbg/_free_dbg e allocano memoria sul Debug Heap.

le funzioni di heap Win32.
Non capisco, le funzioni malloc/calloc/free & C. distribuite con VC++,
non sono altro che wrapper sulle routine di gestione dello heap di
Win32, non e` cosi` ?

 _malloc_dbg/_calloc_dbg/_free_dbg e allocano memoria sul Debug Heap.
Qualche consiglio per poter continuare ad usare le funzioni standard
del "C" senza aver problemi in fase di debug...
C:\>iao Angelo
P.S. Qualche consiglio per un libro che tratti in modo approfondito la
     creazione di programmi sotto Windows?


"Andrea Laforgia" <x@x.x> wrote in message
news:bhh9tukt9g1j95dh4...@4ax.com

Ho trovato qualcosina nella MSDN. L'articolo ha il seguente titolo
Managing Heap Memory in Win32.
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

Managing Heap Memory in Win32.
Sul Richter stesso, comunque, c'e` scritto (come ci si aspetterebbe)
che le normali funzioni della libreria di rt del C sono wrapper per le
funzioni di gestione della memoria Heap di Win32.

"Andrea Laforgia" <x@x.x> wrote in message
news:hck9tusospmvjrikf...@4ax.com

Hei una domanda: ho acquistato la versione italiana del libro
Programmare
Applicazioni per Microsoft Windows. Il numero di pagine è diverso da
quella
inglese. E' stato tagliato qualcosa nella versione italiana?


     creazione di programmi sotto Windows?
Gli unici che conosco (e che ho letto) sono il Petzold e il Richter,
c'e` anche un testo di Prosise relativo a VC++, ma non so a che
versione sia aggiornato (credo alla 6).
Ci sono anche diversi testi di Mark Russinovich (il guru di
SysInternals, per intenderci) sugli "internals" di Windows, ma gia` il
testo di Richter mi sembra fin troppo avanzato per un programmatore
che si accinge a fare cose "normali", quello di Russinovich supera i
limiti e puoi cominciare a fare *vere* porcate ;-)

E' stato tagliato qualcosa nella versione italiana?
Non lo so, anch'io ho la versione italiana, pero` e` usanza comune,
tra gli editori italiani, mutilare i testi tecnici inglesi, nella
traduzione.  Non so, onestamente, il perche`.


No, non sono mappate direttamente: per una chiamata a malloc NON 
corrisponde una chimata a HeapAlloc
La gestione dello heap e' fatta dalla CRT, che chiama HeapAlloc solo 
piu' raramente quando richiede lo spazio preallocato non e' piu' 
sufficiente. (sto parlando della crt di MSVC 6 e 7)
Puoi semplicemente controllare debuggando una chiamata a malloc.


No, non sono mappate direttamente: per una chiamata a malloc NON 
corrisponde una chimata a HeapAlloc
La gestione dello heap e' fatta dalla CRT, che chiama HeapAlloc solo 
piu' raramente quando richiede lo spazio preallocato non e' piu' 
sufficiente. (sto parlando della crt di MSVC 6 e 7)
Puoi semplicemente controllare debuggando una chiamata a malloc.
(avevo sbagliato posizione per la risposta)

 ha scritto nel messaggio
news:ar2ffq$2vu$1...@news.newsland.it...

Io avevo letto qualcosa a riguardo sulla rivista WDJ, in un articolo si
parlava appunto della memoria alloccata da una DLL e liberata dal programma
chiamante.
*non si può fare* per lo meno con le chiamate a malloc/calloc; non ricordo
bene perchè. Se ti serve saperlo nel dettaglio provo a ricercare la rivista
e rileggo l'articolo.
Cmq se memoria non mi frega solo la DLL può liberare la memoria che ha
"alloccato".
Ciao
Giuliano

      Co. 
tutto quello che so l'ho imparato dai sorgenti di ReactOS. Parlo sul 
serio. Vedere cosa c'è dietro a LoadLibrary e simili è illuminante (c'è 
solo alcune cose che in ReactOS funzionano diversamente a causa, credo, 
del mancato supporto per le APC)
-- 
 < 
http://www.reactos.com/
 >  Open source clone of Windows NT. Current
     Don't stand, REACT!      version 0.0.20. C, C++ and ASM developers
                              and beta testers are welcome!

 inglese. E' stato tagliato qualcosa nella versione italiana?
Probabilmente la parte nella quale Richter usa gli oggetti di
sincronizzazione per animare una donna nuda...
Kiuhnm

 per deallocare la memoria allocata dalla DLL
Faccio di meglio, lascio la chiamata myDllFree() in bella mostra (anche perche'
il programma che utilizzera' la dll e' in MDL e comunque non prtrebbe usare la
free() direttamente). Volevo semplicemente capire come mai di questo strano
comportamento ed evitare la tentazione di togliere _DEBUG dalle opzioni di
compilazione per non vedere la dbox con l'errore. :-)
C:\>iao Angelo

 e rileggo l'articolo.
Se riesci a dirmi anche il numero della rivista mi faresti favore grande come
una casa :-)
C:\>iao Angelo

...
Grazie a tutti per l'aiuto.
C:\>iao Angelo

 compilazione per non vedere la dbox con l'errore. :-) 
quel warning ci sarebbe comunque


 MDL? keskesè?
Il linguaggio di sviluppo di MicroStation, un CAD della Bentley (TM): in
pratica un "C" interpretato (sic) e inutile dire che di classi non ne vuole
sapere.
C:\>iao Angelo

 ha scritto nel messaggio
news:f89d63e9.02111...@posting.google.com...
|
| Se riesci a dirmi anche il numero della rivista mi faresti favore grande
come
| una casa :-)
|
Scusa il ritardo con cui ti rispondo ma ho dovuto riguardami un po' di
numeri della rivista.
L'articolo in questione si trova sul numero di aprile 2000 ed è titolato
"bug of the month".
Ciao
Giuliano

 "bug of the month".
Provo a recuperarlo e ci do un'occhita.
Grazie.
C:\>iao Angelo