Below is the valgrind output. Seem like it is OpenSSL's fault? Thus I am not filling another bug report. Or can you do anything about it?
b. ==12933== ==12933== IN SUMMARY: 563339 errors from 307 contexts (suppressed: 69 from 1) ==12933== ==12933== malloc/free: in use at exit: 1,628 bytes in 44 blocks. ==12933== malloc/free: 25,390 allocs, 25,346 frees, 3,335,313 bytes allocated. ==12933== ==12933== searching for pointers to 44 not-freed blocks. ==12933== checked 1,023,180 bytes. ==12933== ==12933== ==12933== 348 bytes in 30 blocks are definitely lost in loss record 2 of 3 ==12933== at 0x40237B9: malloc (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so) ==12933== by 0x4261D9A: default_malloc_ex (in /usr/local/openssl-0.9.8l-1/lib/libcrypto.so.0.9.8) ==12933== ==12933== LEAK SUMMARY: ==12933== definitely lost: 348 bytes in 30 blocks. ==12933== possibly lost: 0 bytes in 0 blocks. ==12933== still reachable: 1,280 bytes in 14 blocks. ==12933== suppressed: 0 bytes in 0 blocks. ==12933== Reachable blocks (those to which a pointer was found) are not shown. ==12933== To see them, rerun with: --leak-check=full --show-reachable=yes --12933-- memcheck: sanity checks: 165 cheap, 8 expensive --12933-- memcheck: auxmaps: 0 auxmap entries (0k, 0M) in use --12933-- memcheck: auxmaps_L1: 0 searches, 0 cmps, ratio 0:10 --12933-- memcheck: auxmaps_L2: 0 searches, 0 nodes --12933-- memcheck: SMs: n_issued = 102 (1632k, 1M) --12933-- memcheck: SMs: n_deissued = 9 (144k, 0M) --12933-- memcheck: SMs: max_noaccess = 65535 (1048560k, 1023M) --12933-- memcheck: SMs: max_undefined = 3 (48k, 0M) --12933-- memcheck: SMs: max_defined = 737 (11792k, 11M) --12933-- memcheck: SMs: max_non_DSM = 98 (1568k, 1M) --12933-- memcheck: max sec V bit nodes: 1189 (60k, 0M) --12933-- memcheck: set_sec_vbits8 calls: 167151 (new: 1189, updates: 165962) --12933-- memcheck: max shadow mem size: 1932k, 1M --12933-- translate: fast SP updates identified: 83,889 ( 93.1%) --12933-- translate: generic_known SP updates identified: 4,337 ( 4.8%) --12933-- translate: generic_unknown SP updates identified: 1,816 ( 2.0%) --12933-- tt/tc: 87,945 tt lookups requiring 121,849 probes --12933-- tt/tc: 87,945 fast-cache updates, 4 flushes --12933-- transtab: new 28,388 (755,681 -> 12,187,193; ratio 161:10) [0 scs] --12933-- transtab: dumped 0 (0 -> ??) --12933-- transtab: discarded 186 (3,146 -> ??) --12933-- scheduler: 16,567,751 jumps (bb entries). --12933-- scheduler: 165/111,191 major/minor sched events. --12933-- sanity: 166 cheap, 8 expensive checks. --12933-- exectx: 12,289 lists, 11,746 contexts (avg 0 per list) --12933-- exectx: 614,084 searches, 611,160 full compares (995 per 1000) --12933-- exectx: 1,029,878 cmp2, 839,523 cmp4, 0 cmpAll --12933-- errormgr: 318 supplist searches, 318 comparisons during search --12933-- errormgr: 563,408 errlist searches, 2,219,261 comparisons during search On 21 February 2010 14:51, Pierre Joye <pierre....@gmail.com> wrote: > hi, > > can you run it through valgrind and paste the output in a new bug report > please? > > Cheers, > > On Sun, Feb 21, 2010 at 2:47 AM, Bostjan Skufca <bost...@a2o.si> wrote: > > a) If you would like to see an example of memory leak, here is how I > > reproduce it. > > > > 1. Clone this git repository: > > http://github.com/bostjan/PHP-application-server > > > > 2. Copy/move/Symlink contents to /opt/daemons/AppSrv > > > > 3. cd to /opt/daemons/AppSrv/demos/demo_https > > > > 4. start the daemon: ./demo -d5 > > - binds and listens on port 30000 > > - does not fork into background > > 7. execute ./client_openssl_nocert > > > > 5. with another shell go to: /opt/daemons/AppSrv/demos/demo_https > > > > 6. execute this: while (true); do ./client_curl; done > > > > 7. start another shell and watch increasing residental memory of PHP > > server process > > > > > > > > b) If you would like to see an example of stale openssl_x509 resource > > bug, here is how I reproduce it. > > Follow the steps 1-5 above > > > > 6. execute ./client_openssl > > - make some input, double return > > - watch at server console how correct CN appears two times > > > > 7. execute ./client_openssl_nocert > > - watch at server console how STALE CN from previous connection appears > > > > 8. execute ./client_openssl_nocert > > - and the bug is gone to hiding > > > > 9. If you repeat steps 6-8 bug reappears/redissapears. > > > > > > > > I hope this helps, > > b. > > > > > > > > On 21 February 2010 01:45, Bostjan Skufca <bost...@a2o.si> wrote: > >> The patch includes code which is very similar but it's functionality > >> goes just the other way around. > >> > >> The original code takes remote CN and if that contains asterisk, it > >> tries to 'limited-wildcard-match' of CN_match against remote CN > >> (remote CN is the pattern in this case, if you will). > >> > >> On the other hand, added code checks if CN_match contains asterisk and > >> if so, it does 'limited-wildcard-match' of REMOTE CN against CN_match > >> pattern. > >> > >> > >> The original version 'could' be enough if you are only considering PHP > >> as a SSL client. > >> > >> > >> Now, what I am trying to achieve is a whole standalone application > >> server written in PHP. That is, whole forking/process management etc > >> stuff. And I would like to set it up like this: > >> - it has a SSL listening socket > >> - set CN_match for listening socket to '*.example.org' > >> - create listening socket with stream_socket_server > >> All above in order to accept connections only from clients which > >> present themselves with appropriate certificate (based on cacert check > >> which works OK) and appropriate CN. > >> > >> To illustrate the desired functionality: > >> - CNs host1.example.org and host2.example.org are OK, > >> - but not CN host3.otherdomain.org, even if it presents a certificate > >> from the same CA as the two above. > >> > >> > >> Was I clear enough now? :) > >> b. > >> > >> > >> > >> PS: I've just discovered another issue. In the context of creating > >> listening socket with stream_socket_create, again. > >> > >> If a preceeding SSL client has introduced itself with client > >> certificate, and the current client does not, the > >> [ssl][peer_certificate] of the new socket's context options still > >> contains a reference to a resource of preceeding client's certificate. > >> Later, subsequent client connections without certificate do not > >> exhibit the same behaviour. > >> If the pattern reoccurs (... ---> client-with-cert ---> followed by > >> client-without-cert), the story repeats. > >> > >> There is also a memory leak in this - when I looped the client to > >> establish hundreds of sequential SSL connections, the residental > >> memory footprint of php server process was ever increasing. When I > >> switched my App server to HTTP protocol and repeated the test the > >> memory leak was not present anymore. And I did openssl_x509_free() > >> call on peer_certificate resource upon client disconnect. > >> > >> > >> > >> > >> > >> On 21 February 2010 00:05, Pierre Joye <pierre....@gmail.com> wrote: > >>> hi, > >>> > >>> Is it not suppose to work already? As your patch basically does what > >>> is done earlier in the code if match fails. If there is a bug in this > >>> area, we should fix instead of adding the same thing later :) > >>> > >>> I will check this issue next week. > >>> > >>> Btw, there is no chance to get this in 5.2.13 or 5.3.2 at this stage, > >>> it is too late in the process. > >>> > >>> Thanks for your work! > >>> > >>> Cheers, > >>> > >>> On Sat, Feb 20, 2010 at 8:56 PM, Bostjan Skufca <bost...@a2o.si> > wrote: > >>>> Hi! > >>>> > >>>> I've created a patch that enables PHP to do "limited wildcard > >>>> matching" if CN_match option in stream context is specified as > >>>> '*.example.org'. > >>>> Also I have filled a bug report for this, here: > >>>> http://bugs.php.net/bug.php?id=51100 > >>>> > >>>> Patch is here: > >>>> http://source.a2o.si/php/php-ext-openssl-CN_match-wildcard.diff > >>>> > >>>> It was made against 5.2.12 but I checked it with SVN: > >>>> - for 5.2 branch the offset is only +6 lines > >>>> - for trunk it is cca +800 lines > >>>> > >>>> Can you include it in 5.2.13 release and 5.3? I know the former is > >>>> already in RC stage but this does can't break anything I believe. > >>>> > >>>> Best regards, > >>>> b. > >>>> > >>>> -- > >>>> PHP Internals - PHP Runtime Development Mailing List > >>>> To unsubscribe, visit: http://www.php.net/unsub.php > >>>> > >>>> > >>> > >>> > >>> > >>> -- > >>> Pierre > >>> > >>> @pierrejoye | http://blog.thepimp.net | http://www.libgd.org > >>> > >> > > > > > > -- > Pierre > > @pierrejoye | http://blog.thepimp.net | http://www.libgd.org >
