probleme with memory management in threads and dll modules
14 réponses
ouech
hi,
i've got a problem on a school project im working on. it's
a web server wich processes requests throught modules that
can hook at any stage of the request treatment.
these modules are classes that has the same base and do their
job in a member function. they are dlls loaded dynamically
throught configuration file or user command. modules store their
results in a class containing the request.
each client/request is managed in a thread and the data object
that store the request is created at the begining of the thread
proc function. it is passed throught each module and used to store
their result in public string members vars (most). those strings are
modified in the modules member functions with constant strings like :
data->result_string = "HTTP/1.1 200 OK\r\n";
so i come to my problem :) after that my server send the response,
when the thread proc is finished, the destructor of my data class
is called then destructors of the members strings. and at the
time the string destructor delete the _Ptr member of the string
class (in function deallocate), i've got a user breakpoint (the
programme stop) in debugging mode folowed (if i resume execution)
by a "debug assertion failed" error in dbgheap.c at expression
_CrtIsValidHeapPointer. the adress of _Ptr is the same that when
i initialized it in the modules functions.
I've tried some things like replacing the string member by a char*
initialized by strdup("mystr") but i can't free it in the destructor
and if i don't, it's the precedent member string in the data class
declaration that causes the same trouble.
i even thought that it was because the stack of the thread was freed
before the destructor of my class was called, so i tried allocating
the class with the new operator and deleting it at the end of the
thread. but it was strictly the same.
i don't really have anymore idea. i use dll like this for the first
time. it seems that the locals and allocated adresses are
not anymore valid after a module function was executed.
i really don't know how to produce data in a module if it's the case :)
does i have to allocate a big buffer before calling the modules
in order to put all the strings they produce in? it would suck a lot :)
Le Mon, 7 Feb 2005 11:38:56 +0100, Vincent Burel a écrit:
"ouech" wrote in message news:
Le Mon, 7 Feb 2005 11:03:46 +0100, Vincent Burel a écrit:
En conséquence de quoi, vous ne pouvez pas avoir de problème de validiter de mémoire dans une application Win32. Sauf erreur de votre part.
VB
merci, je vais finalement commencer par regarder si jai une erreur :)
-- Lucas Montes
ouech
Le Mon, 07 Feb 2005 12:12:55 +0100, ouech a écrit:
Le Mon, 7 Feb 2005 11:38:56 +0100, Vincent Burel a écrit:
"ouech" wrote in message news:
Le Mon, 7 Feb 2005 11:03:46 +0100, Vincent Burel a écrit:
En conséquence de quoi, vous ne pouvez pas avoir de problème de validiter de mémoire dans une application Win32. Sauf erreur de votre part.
VB
merci, je vais finalement commencer par regarder si jai une erreur :)
bah je trouve pas et comme c du code assez simple et que quelque soit l'adresse et la facon dont je l'alloue je ne peux pas la delete, je me demandais si ca ne pouvais pas venir des options de configurations de mes projets (modules et server). la runtime lib est pourtant /MDd dans les dll et MTd dans le projet principal. voila si quelqun a une idee autre qu'une segfault je suis preneur :) (meme si je la cherche toujours)
-- Lucas Montes
Le Mon, 07 Feb 2005 12:12:55 +0100, ouech <loucs_93@nospamhotmail.com> a
écrit:
Le Mon, 7 Feb 2005 11:38:56 +0100, Vincent Burel
<vincent.burel@spam-wanadoo.fr> a écrit:
"ouech" <loucs_93@nospamhotmail.com> wrote in message
news:opsltn3knaozxxof@loucs...
Le Mon, 7 Feb 2005 11:03:46 +0100, Vincent Burel
<vincent.burel@spam-wanadoo.fr> a écrit:
En conséquence de quoi, vous ne pouvez pas avoir de problème de
validiter de
mémoire dans une application Win32. Sauf erreur de votre part.
VB
merci, je vais finalement commencer par regarder si jai une erreur :)
bah je trouve pas et comme c du code assez simple et que quelque soit
l'adresse et la facon dont je l'alloue je ne peux pas la delete, je
me demandais si ca ne pouvais pas venir des options de configurations de
mes projets (modules et server). la runtime lib est pourtant /MDd dans les
dll
et MTd dans le projet principal. voila si quelqun a une idee autre qu'une
segfault je suis preneur :) (meme si je la cherche toujours)
Le Mon, 07 Feb 2005 12:12:55 +0100, ouech a écrit:
Le Mon, 7 Feb 2005 11:38:56 +0100, Vincent Burel a écrit:
"ouech" wrote in message news:
Le Mon, 7 Feb 2005 11:03:46 +0100, Vincent Burel a écrit:
En conséquence de quoi, vous ne pouvez pas avoir de problème de validiter de mémoire dans une application Win32. Sauf erreur de votre part.
VB
merci, je vais finalement commencer par regarder si jai une erreur :)
bah je trouve pas et comme c du code assez simple et que quelque soit l'adresse et la facon dont je l'alloue je ne peux pas la delete, je me demandais si ca ne pouvais pas venir des options de configurations de mes projets (modules et server). la runtime lib est pourtant /MDd dans les dll et MTd dans le projet principal. voila si quelqun a une idee autre qu'une segfault je suis preneur :) (meme si je la cherche toujours)
-- Lucas Montes
ouech
Le Mon, 07 Feb 2005 14:43:23 +0100, ouech a écrit:
Le Mon, 07 Feb 2005 12:12:55 +0100, ouech a écrit:
Le Mon, 7 Feb 2005 11:38:56 +0100, Vincent Burel a écrit:
"ouech" wrote in message news:
Le Mon, 7 Feb 2005 11:03:46 +0100, Vincent Burel a écrit:
En conséquence de quoi, vous ne pouvez pas avoir de problème de validiter de mémoire dans une application Win32. Sauf erreur de votre part.
VB
merci, je vais finalement commencer par regarder si jai une erreur :)
bah je trouve pas et comme c du code assez simple et que quelque soit l'adresse et la facon dont je l'alloue je ne peux pas la delete, je me demandais si ca ne pouvais pas venir des options de configurations de mes projets (modules et server). la runtime lib est pourtant /MDd dans les dll et MTd dans le projet principal. voila si quelqun a une idee autre qu'une segfault je suis preneur :) (meme si je la cherche toujours)
YES !!! :) c'etait bien ca, je commencait a desesperer :) il fallait mettre le projet principal en MDd (multiple threaded dll) alors que c un .exe.. (aaah windows quand tu nous tient) j'ai jamais eu a me prendre la tete comme ca avec les .so des unix.
-- Lucas Montes
ps : merci au mec qui parle de ca dans le post des dll et allocation de memoire.
Le Mon, 07 Feb 2005 14:43:23 +0100, ouech <loucs_93@nospamhotmail.com> a
écrit:
Le Mon, 07 Feb 2005 12:12:55 +0100, ouech <loucs_93@nospamhotmail.com> a
écrit:
Le Mon, 7 Feb 2005 11:38:56 +0100, Vincent Burel
<vincent.burel@spam-wanadoo.fr> a écrit:
"ouech" <loucs_93@nospamhotmail.com> wrote in message
news:opsltn3knaozxxof@loucs...
Le Mon, 7 Feb 2005 11:03:46 +0100, Vincent Burel
<vincent.burel@spam-wanadoo.fr> a écrit:
En conséquence de quoi, vous ne pouvez pas avoir de problème de
validiter de
mémoire dans une application Win32. Sauf erreur de votre part.
VB
merci, je vais finalement commencer par regarder si jai une erreur :)
bah je trouve pas et comme c du code assez simple et que quelque soit
l'adresse et la facon dont je l'alloue je ne peux pas la delete, je
me demandais si ca ne pouvais pas venir des options de configurations de
mes projets (modules et server). la runtime lib est pourtant /MDd dans
les dll
et MTd dans le projet principal. voila si quelqun a une idee autre qu'une
segfault je suis preneur :) (meme si je la cherche toujours)
YES !!! :) c'etait bien ca, je commencait a desesperer :) il fallait
mettre le projet
principal en MDd (multiple threaded dll) alors que c un .exe.. (aaah
windows quand tu
nous tient) j'ai jamais eu a me prendre la tete comme ca avec les .so des
unix.
--
Lucas
Montes
ps : merci au mec qui parle de ca dans le post des dll et allocation de
memoire.
Le Mon, 07 Feb 2005 14:43:23 +0100, ouech a écrit:
Le Mon, 07 Feb 2005 12:12:55 +0100, ouech a écrit:
Le Mon, 7 Feb 2005 11:38:56 +0100, Vincent Burel a écrit:
"ouech" wrote in message news:
Le Mon, 7 Feb 2005 11:03:46 +0100, Vincent Burel a écrit:
En conséquence de quoi, vous ne pouvez pas avoir de problème de validiter de mémoire dans une application Win32. Sauf erreur de votre part.
VB
merci, je vais finalement commencer par regarder si jai une erreur :)
bah je trouve pas et comme c du code assez simple et que quelque soit l'adresse et la facon dont je l'alloue je ne peux pas la delete, je me demandais si ca ne pouvais pas venir des options de configurations de mes projets (modules et server). la runtime lib est pourtant /MDd dans les dll et MTd dans le projet principal. voila si quelqun a une idee autre qu'une segfault je suis preneur :) (meme si je la cherche toujours)
YES !!! :) c'etait bien ca, je commencait a desesperer :) il fallait mettre le projet principal en MDd (multiple threaded dll) alors que c un .exe.. (aaah windows quand tu nous tient) j'ai jamais eu a me prendre la tete comme ca avec les .so des unix.
-- Lucas Montes
ps : merci au mec qui parle de ca dans le post des dll et allocation de memoire.
WillyNT
> YES !!! :) c'etait bien ca, je commencait a desesperer :) il fallait mettre le projet principal en MDd (multiple threaded dll) alors que c un .exe.. (aaah windows quand tu nous tient) j'ai jamais eu a me prendre la tete comme ca avec les .so des unix.
le "D" pour DLL n'a rien à voir avec le fait que ton projet soir un exe pour une dll. Ca indique si la runtime c doit etre utilisée dynamiquement en dll (msvcrt.dll, le nom dépend des versions) ou liée statiquement à ton projet. Il est fortement recommandé d'utiliser la meme config dans tous les modules du projet. Ca évite justement ces problèmes de mémoire...
-- William Levra-Juillet http://www.directupdate.net/
> YES !!! :) c'etait bien ca, je commencait a desesperer :) il fallait
mettre le projet
principal en MDd (multiple threaded dll) alors que c un .exe.. (aaah
windows quand tu
nous tient) j'ai jamais eu a me prendre la tete comme ca avec les .so des
unix.
le "D" pour DLL n'a rien à voir avec le fait que ton projet soir un exe pour
une dll.
Ca indique si la runtime c doit etre utilisée dynamiquement en dll
(msvcrt.dll, le nom dépend des versions) ou liée statiquement à ton projet.
Il est fortement recommandé d'utiliser la meme config dans tous les modules
du projet.
Ca évite justement ces problèmes de mémoire...
--
William Levra-Juillet
http://www.directupdate.net/
> YES !!! :) c'etait bien ca, je commencait a desesperer :) il fallait mettre le projet principal en MDd (multiple threaded dll) alors que c un .exe.. (aaah windows quand tu nous tient) j'ai jamais eu a me prendre la tete comme ca avec les .so des unix.
le "D" pour DLL n'a rien à voir avec le fait que ton projet soir un exe pour une dll. Ca indique si la runtime c doit etre utilisée dynamiquement en dll (msvcrt.dll, le nom dépend des versions) ou liée statiquement à ton projet. Il est fortement recommandé d'utiliser la meme config dans tous les modules du projet. Ca évite justement ces problèmes de mémoire...
-- William Levra-Juillet http://www.directupdate.net/