Hi all,
Just to remind about my problem:
After updating from latest CVS I still had problems with internal
hashtables. I want to make internal class constants and the engine reports
memory leaks.
So I made this patch wich works for me and removed all memory leaks
regarding hashtables.
This patch introduces a new macro called ZEND_INIT_INTERNAL_SYMTABLE wich is
to be used instead of ZEND_INIT_SYMTABLE when the hashtables is internal.
That's the only change that should be done in sources that needs internal
hashtables.
Best Regards,
Cristiano Duarte
Here is the patch without the printf's. Sorry. ;-)
Cristiano Duarte
At 02:53 PM 10/26/2003 -0200, Cristiano Duarte wrote:
Hi all,
Just to remind about my problem:
After updating from latest CVS I still had problems with internal
hashtables. I want to make internal class constants and the engine reports
memory leaks.So I made this patch wich works for me and removed all memory leaks
regarding hashtables.This patch introduces a new macro called ZEND_INIT_INTERNAL_SYMTABLE wich is
to be used instead of ZEND_INIT_SYMTABLE when the hashtables is internal.
That's the only change that should be done in sources that needs internal
hashtables.
This doesn't look right. Shouldn't you make sure that module shutdown frees
the hashtables? You can change the dtor if you need.
I'm sorry but I don't quite understand what made you come up with this
solution. Maybe I'm missing something.
Andi
"Andi Gutmans" andi@zend.com escreveu na mensagem
news:5.1.0.14.2.20031026213148.03145288@127.0.0.1...
This doesn't look right. Shouldn't you make sure that module shutdown
frees
the hashtables? You can change the dtor if you need.
I'm sorry but I don't quite understand what made you come up with this
solution. Maybe I'm missing something.
Shure I can free the hashtable on module shutdown, but since the hashtable
is inside a class definition(class constants), should I unregister the class
too ?
I just put this code because the current symtable only supports userland
defined class constants.
What is the good practice in developing PHP extensions ? Free all classes
defined within an extension at module shutdown ?
Best Regards,
Cristiano Duarte
Hi Andi,
In fact Moriyoshi pointed out this problem in hist "Registering constants to
internal classes (ZE2)" message:
http://www.zend.com/lists/php-dev/200307/msg00023.html
The code I provided fix this problem, if it's a problem...
Cristiano Duarte
Oops, I figure out that the patch was incorrect, since the function call
should be "zend_hash_destroy" instead of "zend_hash_clean". Sorry. :-p
New patch included.
Now the memory leaks are gone forever !
Cristiano Duarte
Oops, I figure out that the patch was incorrect, since the function call
should be "zend_hash_destroy" instead of "zend_hash_clean". Sorry. :-p
New patch included.
Now the memory leaks are gone forever !
Can you please not send uuencoded stuff but just attach the files as
plain text?
Derick
begin 666 ze2_internal_symtables.patch
M/R!P:' M<W)C+UIE;F1%;F=I;F4Q"DEN9&5X.B!P:' M<W)C+UIE;F0O>F5N
M9%]A;&QO8RYC"CT]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]
M/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T4D-3(&9I;&4Z("]R
M97!O<VET;W)Y+UIE;F1%;F=I;F4R+WIE;F1?86QL;V,N8RQV"G)E=')I979I
M;F<@<F5V:7-I;VX@,2XQ,CD9&EF9B M=2 M<C$N,3(Y('IE;F1?86QL;V,N
M8PHM+2T@<&AP+7-R8R]:96YD+WIE;F1?86QL;V,N8PDQ-R!/8W0@,C P,R P
M,CHR.3HP-B M,# P, DQ+C$R.0HKRL@<&AP+7-R8R]:96YD+WIE;F1?86QL
M;V,N8PDR-B!/8W0@,C P,R Q-CHU-SHS.2 M,# P, I 0" M-#<W+#8@S0W
M-RPQ,"! 0 H@"7IE;F1?=6EN="!G<F%N9%]T;W1A;%]L96%K<STP.PH@(V5N
M9&EF"B PEI9B H>F5N9%]I;G1E<FYA;%]N3V9(87-H5&%B;&5S"D@/B P
M2!["BL)"7IE;F1?9V-?9&5S=')O>5]I;G1E<FYA;%]H87-H=&%B;&5S"D[
M"BL)?0HK"B C:68@9&5F:6YE9"A:14Y$7TU-2 F)B A6D5.1%]$14)51PH@
M"6EF("AC;&5A;E]C86-H92D@>PH@"0EZ96YD7VUM7W-H=71D;W=N"9!1RAM
M;5]H96%P2D["DEN9&5X.B!P:' M<W)C+UIE;F0O>F5N9%]H87-H+F,/3T]
M/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]
M/3T]/3T]/3T]/3T]/3T]/3T]/0I20U,@9FEL93H@+W)E<&]S:71O<GDO6F5N
M9$5N9VEN93(O>F5N9%]H87-H+F,L=@IR971R:65V:6YG(')E=FES:6]N(#$N
M,3$S"F1I9F8@+74@+7(Q+C$Q,R!Z96YD7VAA<V@N8PHM+2T@<&AP+7-R8R]:
M96YD+WIE;F1?:&%S:"YC"3(Y($%U9R R,# S(# W.C,T.C,W("TP,# P"3$N
M,3$S"BLKR!P:' M<W)C+UIE;F0O>F5N9%]H87-H+F,),C8@3V-T(#(P,#,@
M,38Z-3<Z-# @+3 P,# 0$ @+3$S,3,L-B K,3,Q,RPT."! 0 H@?0H@(V5N
M9&EF"B W-T<G5C="!?:6YT97)N86Q?:&%S:'1A8FQE<R!["BL)2&%S:%1A
M8FQE("HJ;&ES=#LPEI;G0@;D]F2&%S:%1A8FQE<SLWT["BMS=')U8W0@
M7VEN=&5R;F%L7VAA<VAT86)L97,@FEN=&5R;F%L7VAA<VAT86)L97,@/2!.
M54Q,.PHK"BMI;G0@>F5N9%]I;G1E<FYA;%]N3V9(87-H5&%B;&5S"D@>PHK
M"7)E='5R;B H:6YT97)N86Q?:&%S:'1A8FQE<R ]/2!.54Q,2 _(# @.B!I
M;G1E<FYA;%]H87-H=&%B;&5S+3YN3V9(87-H5&%B;&5S.PHK?0HK"BMV;VED
M('IE;F1?9V-?861D7VEN=&5R;F%L7VAA<VAT86)L92A(87-H5&%B;&4@FAT
M(%134DU,4U]$0RD@>PHK"4AA<VA486)L92 JG!T<CLPEI9B H:6YT97)N
M86Q?:&%S:'1A8FQE<R ]/2!.54Q,2!["BL)"6EN=&5R;F%L7VAA<VAT86)L
M97,@/2!M86QL;V,H<VEZ96]F'-T<G5C="!?:6YT97)N86Q?:&%S:'1A8FQE
M<RDI.PHK"0EI;G1E<FYA;%]H87-H=&%B;&5S+3YN3V9(87-H5&%B;&5S(#T@
M,#LPD):6YT97)N86Q?:&%S:'1A8FQE<RT^;&ES=" ]($Y53$P["BL)?0HK
M"6EN=&5R;F%L7VAA<VAT86)L97,M/FQI<W0@/2!R96%L;&]C&EN=&5R;F%L
M7VAA<VAT86)L97,M/FQI<W0L('-I>F5O9BA(87-H5&%B;&4J2 J("AI;G1E
M<FYA;%]H87-H=&%B;&5S+3YN3V9(87-H5&%B;&5S("L@,2DI.PHK"7!T<B ]
M(&EN=&5R;F%L7VAA<VAT86)L97,M/FQI<W0["BL)<'1R("L](&EN=&5R;F%L
M7VAA<VAT86)L97,M/FY/9DAA<VA486)L97,["BL)G!T<B ](&AT.PHK"2LK
M&EN=&5R;F%L7VAA<VAT86)L97,M/FY/9DAA<VA486)L97,I.PHK?0HK"BMV
M;VED('IE;F1?9V-?9&5S=')O>5]I;G1E<FYA;%]H87-H=&%B;&5S*"D@>PHK
M"4AA<VA486)L92 JG!T<CLPEI9B H:6YT97)N86Q?:&%S:'1A8FQE<R A
M/2!.54Q,2L97,M/FQI<W0[
M"BL)"6EF("AP='(@(3T@3E5,3"D@>PHK"0D):6YT(&D["BL)"0EF;W(@&D@
M/2 P.R!I(#P@:6YT97)N86Q?:&%S:'1A8FQE<RT^;D]F2&%S:%1A8FQE<SL@
MRMI2!["BL)"0D)>F5N9%]H87-H7V1E<W1R;WDHG!T<BD"BL)"0D)RMP
M='(["BL)"0E]"BL)"0EF<F5E&EN=&5R;F%L7VAA<VAT86)L97,M/FQI<W0I
M.PHK"0D):6YT97)N86Q?:&%S:'1A8FQE<RT^;&ES=" "0EF
M<F5E*&EN=&5R;F%L7VAA<VAT86)L97,I.PHK"0D):6YT97)N86Q?:&%S:'1A
M8FQE<R ]($Y53$P["BL)"7TPE]"BM]"BL("\J"B @B!,;V-A;"!V87)I
M86)L97,Z"B @B!T86(M=VED=&@Z(#026YD97@Z('!H<"US<F,O6F5N9"]Z
M96YD7VAA<V@N: H]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]
M/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]"E)#4R!F:6QE.B O
M<F5P;W-I=&]R>2]:96YD16YG:6YE,B]Z96YD7VAA<V@N:"QV"G)E=')I979I
M;F<@<F5V:7-I;VX@,2XW-0ID:69F("UU("UR,2XW-2!Z96YD7VAA<V@N: HM
M+2T@<&AP+7-R8R]:96YD+WIE;F1?:&%S:"YH"3(U(%-E<" R,# S(#$U.C,X
M.C,U("TP,# P"3$N-S4RLK('!H<"US<F,O6F5N9"]Z96YD7VAA<V@N: DR
M-B!/8W0@,C P,R Q-CHU-SHT," M,# P, I 0" M,S4P+#8@S,U,"PQ-"!
M0 H@"7)E='5R;B!Z96YD7VAA<VA?97AI<W1S&AT+"!A<DME>2P@;DME>4QE
M;F=T:"D["B!]"B R-D969I;F4@6D5.1%])3DE47TE.5$523D%,7U-9351!
M0DQ%&AT2!<"BL@(" @(" @(%I%3D1?24Y)5%]364U404),12AH="D[(%P*
MR @(" @(" @>F5N9%]G8U]A9&1?:6YT97)N86Q?:&%S:'1A8FQE&AT(%13
M4DU,4U]#0RD["BLVEN="!Z96YD7VEN=&5R;F%L7VY/9DAA<VA486)L97,H
M3LW9O:60@>F5N9%]G8U]A9&1?:6YT97)N86Q?:&%S:'1A8FQE$AA<VA4
M86)L92 J:'0@5%-234Q37T1#3LW9O:60@>F5N9%]G8U]D97-T<F]Y7VEN
M=&5R;F%L7VAA<VAT86)L97,H3L**PH@(V5N9&EF"0D)"0D)"2\J(%I%3D1?
02$%32%](("HO"B *("\J"@``
`
end
--
"Interpreting what the GPL actually means is a job best left to those
that read the future by examining animal entrails."
Derick Rethans http://derickrethans.nl/
International PHP Magazine http://php-mag.net/
Can you please not send uuencoded stuff but just attach the files as
plain text?
Sorry Derick, I didn't mean to.
The patch is now included as plain text.
Cristiano Duarte
Can you please not send uuencoded stuff but just attach the files as
plain text?
Sorry Derick, I didn't mean to.
The patch is now included as plain text.
Cristiano Duarte
Derick Rethans wrote:
Can you please not send uuencoded stuff but just attach the files as
plain text?
Sorry Derick, I didn't mean to. :-(
The patch is attached as plain text now.
Cristiano Duarte
Hi all,
I guess I found a bug at "zend_compile.c". IMHO when you want to create
an internal hashtable, that will be filled with internal zvals
(malloc'ed instead of emalloc'ed), you should pass the "internal zval
destructor" to the hashtable initialization function. Currently,
"zend_compile.c" uses the "default zval destructor" for internal and
standard zvals. It leads to some error messages (about efree'ing blocks
that weren't emalloc'ed) at the end of execution.
Am I right, I mean is this the correct behaviour of an internal
hashtable ? Anyway, the patch attached fixes it.
Best Regards,
Cristiano Duarte
Hi all,
I guess I found a bug at "zend_compile.c". IMHO when you want to create
an internal hashtable, that will be filled with internal zvals
(malloc'ed instead of emalloc'ed), you should pass the "internal zval
destructor" to the hashtable initialization function. Currently,
"zend_compile.c" uses the "default zval destructor" for internal and
standard zvals. It leads to some error messages (about efree'ing blocks
that weren't emalloc'ed) at the end of execution.
Am I right, I mean is this the correct behaviour of an internal
hashtable ? Anyway, the patch attached fixes it.
Best Regards,
Cristiano Duarte