J'ai un probl=E8me avec un OCX.
Celui ci permet d'instancier en RAM des images assez volumineuses via
une interface VB.
Or, apr=E8s quelques changements de r=E9solutions, les allocations me
renvoient "NULL". (bien sur , une lib=E9ration est faite avant chaque
allocation...)
Je pense que c'est li=E9 au tas , ci joint les trace du debugger MS :
(298.338): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=3D0241d498 ebx=3D02410000 ecx=3D00000002 edx=3D034ce508 esi=3D034cf000
edi=3D034ce508
eip=3D77fcca14 esp=3D0012e760 ebp=3D0012e76c iopl=3D0 nv up ei pl nz na po =
nc
cs=3D001b ss=3D0023 ds=3D0023 es=3D0023 fs=3D003b gs=3D0000 efl=3D00010206
ntdll!RtlFreeHeap+0x3d0
J'ai beau modifier les valeurs /HEAP ou /STACK au niveau du linker de
visual C mais rien n'y fait.
Auriez vous une id=E9=E9.=20
Merci d'avance
S=E9bastien
Une access violation, c'est que tu essaies d'accéder à une zone mémoire où tu n'a pas le droit d'accéder (soit tu déréferences un pointeur invalide, soit tu libère 2 fois le même bloc mémoire, etc...)
First chance exceptions are reported before any exception handling. This exception may be expected and handled. eax41d498 ebx410000 ecx 000002 edx4ce508 esi4cf000 edi4ce508 eipwfcca14 esp 12e760 ebp 12e76c iopl=0 nv up ei pl nz na po nc cs 1b ss 23 ds 23 es 23 fs 3b gs 00 efl 010206 ntdll!RtlFreeHeap+0x3d0
J'ai beau modifier les valeurs /HEAP ou /STACK au niveau du linker de visual C mais rien n'y fait.
Normal : c'est un bug de manipulation de pointeur dans ton code (à vu de nez, un double delete, mais impossible d'en dire plus sans une stack trace complète).
Arnaud
seb wrote:
Bonjour,
J'ai un problème avec un OCX.
Celui ci permet d'instancier en RAM des images assez volumineuses via
une interface VB.
Or, après quelques changements de résolutions, les allocations me
renvoient "NULL". (bien sur , une libération est faite avant chaque
allocation...)
Je pense que c'est lié au tas , ci joint les trace du debugger MS :
Une access violation, c'est que tu essaies d'accéder à une zone mémoire où
tu n'a pas le droit d'accéder (soit tu déréferences un pointeur invalide,
soit tu libère 2 fois le même bloc mémoire, etc...)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax41d498 ebx410000 ecx 000002 edx4ce508 esi4cf000
edi4ce508
eipwfcca14 esp 12e760 ebp 12e76c iopl=0 nv up ei pl nz na po nc
cs 1b ss 23 ds 23 es 23 fs 3b gs 00 efl 010206
ntdll!RtlFreeHeap+0x3d0
J'ai beau modifier les valeurs /HEAP ou /STACK au niveau du linker de
visual C mais rien n'y fait.
Normal : c'est un bug de manipulation de pointeur dans ton code (à vu de
nez, un double delete, mais impossible d'en dire plus sans une stack trace
complète).
Une access violation, c'est que tu essaies d'accéder à une zone mémoire où tu n'a pas le droit d'accéder (soit tu déréferences un pointeur invalide, soit tu libère 2 fois le même bloc mémoire, etc...)
First chance exceptions are reported before any exception handling. This exception may be expected and handled. eax41d498 ebx410000 ecx 000002 edx4ce508 esi4cf000 edi4ce508 eipwfcca14 esp 12e760 ebp 12e76c iopl=0 nv up ei pl nz na po nc cs 1b ss 23 ds 23 es 23 fs 3b gs 00 efl 010206 ntdll!RtlFreeHeap+0x3d0
J'ai beau modifier les valeurs /HEAP ou /STACK au niveau du linker de visual C mais rien n'y fait.
Normal : c'est un bug de manipulation de pointeur dans ton code (à vu de nez, un double delete, mais impossible d'en dire plus sans une stack trace complète).
Arnaud
seb
Merci pour l'info.
Pour les allocations et desallocations, je passe par une DLL codée par un de nos fournisseurs, c'est donc une boite noire pour moi... Or j'en ai parlé avec eux au tel; ils sont surs des allocations et desallocations memoire; pour eux, ceci provient de la quantité de memoire dispo. Je dois avoir environ 24Mo de RAM dispo quand le programme tourne .J'alloue et désalloues 3 images à la voléé d'environ 1Mo l'image ; je pense donc que c'est vraiment lié au tas (le problème n'apparait pas toujours au meme moment).
Je sais que sous VC, il est possible de modifier la taille du tas allouée par process (Windows alloue un tas avec une taille maxi figée pour chaque process). Cependant, les options de compil (d'apres ce que j'ai compris sur MSDN) ne fonctionnent que pour les executables; or ici , il s'agit d'un OCX. L'interface, elle, est faite en VB et coté VB il n'y as pas de possibilité de modifier la taille de la zone allouée pour le tas.
Sébastien.
Merci pour l'info.
Pour les allocations et desallocations, je passe par une DLL codée par
un de nos fournisseurs, c'est donc une boite noire pour moi...
Or j'en ai parlé avec eux au tel; ils sont surs des allocations et
desallocations memoire; pour eux, ceci provient de la quantité de
memoire dispo. Je dois avoir environ 24Mo de RAM dispo quand le
programme tourne .J'alloue et désalloues 3 images à la voléé
d'environ 1Mo l'image ; je pense donc que c'est vraiment lié au tas
(le problème n'apparait pas toujours au meme moment).
Je sais que sous VC, il est possible de modifier la taille du tas
allouée par process (Windows alloue un tas avec une taille maxi figée
pour chaque process). Cependant, les options de compil (d'apres ce que
j'ai compris sur MSDN) ne fonctionnent que pour les executables; or ici
, il s'agit d'un OCX.
L'interface, elle, est faite en VB et coté VB il n'y as pas de
possibilité de modifier la taille de la zone allouée pour le tas.
Pour les allocations et desallocations, je passe par une DLL codée par un de nos fournisseurs, c'est donc une boite noire pour moi... Or j'en ai parlé avec eux au tel; ils sont surs des allocations et desallocations memoire; pour eux, ceci provient de la quantité de memoire dispo. Je dois avoir environ 24Mo de RAM dispo quand le programme tourne .J'alloue et désalloues 3 images à la voléé d'environ 1Mo l'image ; je pense donc que c'est vraiment lié au tas (le problème n'apparait pas toujours au meme moment).
Je sais que sous VC, il est possible de modifier la taille du tas allouée par process (Windows alloue un tas avec une taille maxi figée pour chaque process). Cependant, les options de compil (d'apres ce que j'ai compris sur MSDN) ne fonctionnent que pour les executables; or ici , il s'agit d'un OCX. L'interface, elle, est faite en VB et coté VB il n'y as pas de possibilité de modifier la taille de la zone allouée pour le tas.
Sébastien.
adebaene
seb wrote:
Merci pour l'info.
Pour les allocations et desallocations, je passe par une DLL codée par un de nos fournisseurs, c'est donc une boite noire pour moi...
*Toutes* tes allocations? Tu ne fais jamais un new ou un malloc dans ton code? Tu n'utilises jamais une classe qui fait de l'allocation en interne (vector, string, etc...) ??? Tu n'utilises jamais un pointeur (ou un tableau C)? J'ai du mal à y croire...
Or j'en ai parlé avec eux au tel; ils sont surs des allocations et desallocations memoire; pour eux, ceci provient de la quantité de memoire dispo. Je dois avoir environ 24Mo de RAM dispo quand le programme tourne .
Quand je voie çà, je commence à prendre peur : ce qu'il te faut, c'est 24 MO de mémoire virtuelle disponible, certainement pas 24Mo de RAM... So ton fournisseur ne fait pas la diffférence, c'est inquiétant...
J'alloue et désalloues 3 images à la voléé d'environ 1Mo l'image ; je pense donc que c'est vraiment lié au tas (le problème n'apparait pas toujours au meme moment).
Ca ne proouve rien : si le programme est multithread, les erreurs ne sont pas reproductibles....
Je sais que sous VC, il est possible de modifier la taille du tas allouée par process (Windows alloue un tas avec une taille maxi figée pour chaque process).
Non : le heap par défaut peut grandir selon les besoins... Heureusement, sinon il ne serait pas possible d'allouer plus de 1Mo avec malloc, new, etc...
Voire http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dngenlib /html/msdn_heapmm.asp ou bien "Inside Windows 2000" pour les détails, mais je t'assure que ca ne pose *aucun* problème d'allouer 24 Mo d'un coup sur un Windows classique.
Cependant, les options de compil (d'apres ce que j'ai compris sur MSDN) ne fonctionnent que pour les executables; or ici , il s'agit d'un OCX. L'interface, elle, est faite en VB et coté VB il n'y as pas de possibilité de modifier la taille de la zone allouée pour le tas.
Tu ne cherches pas le problème du bon côté : ton problème est dû à une erreur de manipulation de pointeur, pas à une limitation de Windows! Tu ne peux pas avoir une stack-trace complète au moment de l'exception?
Arnaud
seb wrote:
Merci pour l'info.
Pour les allocations et desallocations, je passe par une DLL codée par
un de nos fournisseurs, c'est donc une boite noire pour moi...
*Toutes* tes allocations? Tu ne fais jamais un new ou un malloc dans
ton code? Tu n'utilises jamais une classe qui fait de l'allocation en
interne (vector, string, etc...) ??? Tu n'utilises jamais un pointeur
(ou un tableau C)? J'ai du mal à y croire...
Or j'en ai parlé avec eux au tel; ils sont surs des allocations et
desallocations memoire; pour eux, ceci provient de la quantité de
memoire dispo. Je dois avoir environ 24Mo de RAM dispo quand le
programme tourne .
Quand je voie çà, je commence à prendre peur : ce qu'il te faut,
c'est 24 MO de mémoire virtuelle disponible, certainement pas 24Mo de
RAM... So ton fournisseur ne fait pas la diffférence, c'est
inquiétant...
J'alloue et désalloues 3 images à la voléé
d'environ 1Mo l'image ; je pense donc que c'est vraiment lié au tas
(le problème n'apparait pas toujours au meme moment).
Ca ne proouve rien : si le programme est multithread, les erreurs ne
sont pas reproductibles....
Je sais que sous VC, il est possible de modifier la taille du tas
allouée par process (Windows alloue un tas avec une taille maxi figée
pour chaque process).
Non : le heap par défaut peut grandir selon les besoins...
Heureusement, sinon il ne serait pas possible d'allouer plus de 1Mo
avec malloc, new, etc...
Voire
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dngenlib /html/msdn_heapmm.asp
ou bien "Inside Windows 2000" pour les détails, mais je t'assure que
ca ne pose *aucun* problème d'allouer 24 Mo d'un coup sur un Windows
classique.
Cependant, les options de compil (d'apres ce que
j'ai compris sur MSDN) ne fonctionnent que pour les executables; or ici
, il s'agit d'un OCX.
L'interface, elle, est faite en VB et coté VB il n'y as pas de
possibilité de modifier la taille de la zone allouée pour le tas.
Tu ne cherches pas le problème du bon côté : ton problème est dû
à une erreur de manipulation de pointeur, pas à une limitation de
Windows! Tu ne peux pas avoir une stack-trace complète au moment de
l'exception?
Pour les allocations et desallocations, je passe par une DLL codée par un de nos fournisseurs, c'est donc une boite noire pour moi...
*Toutes* tes allocations? Tu ne fais jamais un new ou un malloc dans ton code? Tu n'utilises jamais une classe qui fait de l'allocation en interne (vector, string, etc...) ??? Tu n'utilises jamais un pointeur (ou un tableau C)? J'ai du mal à y croire...
Or j'en ai parlé avec eux au tel; ils sont surs des allocations et desallocations memoire; pour eux, ceci provient de la quantité de memoire dispo. Je dois avoir environ 24Mo de RAM dispo quand le programme tourne .
Quand je voie çà, je commence à prendre peur : ce qu'il te faut, c'est 24 MO de mémoire virtuelle disponible, certainement pas 24Mo de RAM... So ton fournisseur ne fait pas la diffférence, c'est inquiétant...
J'alloue et désalloues 3 images à la voléé d'environ 1Mo l'image ; je pense donc que c'est vraiment lié au tas (le problème n'apparait pas toujours au meme moment).
Ca ne proouve rien : si le programme est multithread, les erreurs ne sont pas reproductibles....
Je sais que sous VC, il est possible de modifier la taille du tas allouée par process (Windows alloue un tas avec une taille maxi figée pour chaque process).
Non : le heap par défaut peut grandir selon les besoins... Heureusement, sinon il ne serait pas possible d'allouer plus de 1Mo avec malloc, new, etc...
Voire http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dngenlib /html/msdn_heapmm.asp ou bien "Inside Windows 2000" pour les détails, mais je t'assure que ca ne pose *aucun* problème d'allouer 24 Mo d'un coup sur un Windows classique.
Cependant, les options de compil (d'apres ce que j'ai compris sur MSDN) ne fonctionnent que pour les executables; or ici , il s'agit d'un OCX. L'interface, elle, est faite en VB et coté VB il n'y as pas de possibilité de modifier la taille de la zone allouée pour le tas.
Tu ne cherches pas le problème du bon côté : ton problème est dû à une erreur de manipulation de pointeur, pas à une limitation de Windows! Tu ne peux pas avoir une stack-trace complète au moment de l'exception?
