More detailed information:<br><br><br>==15424== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 23 from 1)<br>==15424== malloc/free: in use at exit: 2,256 bytes in 112 blocks.<br>==15424== malloc/free: 15,476 allocs, 15,364 frees, 6,641,755 bytes allocated.<br>
==15424== For counts of detected errors, rerun with: -v<br>==15424== searching for pointers to 112 not-freed blocks.<br>==15424== checked 124,560 bytes.<br>==15424==<br>==15424== 2,248 (2,008 direct, 240 indirect) bytes in 99 blocks are definitely lost in loss record 3 of 3<br>
==15424==&nbsp;&nbsp;&nbsp; at 0x401C6CA: calloc (vg_replace_malloc.c:279)<br>==15424==&nbsp;&nbsp;&nbsp; by 0x8090D32: u_zalloc (memory.c:63)<br>==15424==&nbsp;&nbsp;&nbsp; by 0x808E1B3: u_hmap_o_new (hmap.c:1072)<br>==15424==&nbsp;&nbsp;&nbsp; by 0x80748FC: emb_register (emb.c:69)<br>
==15424==&nbsp;&nbsp;&nbsp; by 0x807D92A: module_init_3c03a85447646e5d5127801337173786 (pg_3c03a85447646e5d5127801337173786.c:67)<br>==15424==&nbsp;&nbsp;&nbsp; by 0x80793D0: do_register (register.c:22)<br>==15424==&nbsp;&nbsp;&nbsp; by 0x80793BD: register_pages (register.c:9)<br>
==15424==&nbsp;&nbsp;&nbsp; by 0x80746FF: emb_init (emb.c:32)<br>==15424==&nbsp;&nbsp;&nbsp; by 0x805072D: app_init (main.c:96)<br>==15424==&nbsp;&nbsp;&nbsp; by 0x8050DF4: main (entry.c:397)<br>==15424==<br>==15424== LEAK SUMMARY:<br>==15424==&nbsp;&nbsp;&nbsp; definitely lost: 2,008 bytes in 99 blocks.<br>
==15424==&nbsp;&nbsp;&nbsp; indirectly lost: 240 bytes in 12 blocks.<br>==15424==&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; possibly lost: 0 bytes in 0 blocks.<br>==15424==&nbsp;&nbsp;&nbsp; still reachable: 8 bytes in 1 blocks.<br>==15424==&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; suppressed: 0 bytes in 0 blocks.<br>==15424== Reachable blocks (those to which a pointer was found) are not shown.<br>
==15424== To see them, rerun with: --show-reachable=yes<br><br><br><div class="gmail_quote">2008/12/5 Steven Van Ingelgem <span dir="ltr">&lt;<a href="mailto:steven@vaningelgem.be">steven@vaningelgem.be</a>&gt;</span><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Seems that did the trick ;-)<br><br>Still:<br>==9064== LEAK SUMMARY:<br>==9064==&nbsp;&nbsp;&nbsp; definitely lost: 2,248 bytes in 111 blocks.<br>
==9064==&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; possibly lost: 0 bytes in 0 blocks.<br>==9064==&nbsp;&nbsp;&nbsp; still reachable: 8 bytes in 1 blocks.<br>
==9064==&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; suppressed: 0 bytes in 0 blocks.<br><br><br><br><div class="gmail_quote"><div class="Ih2E3d">2008/12/5 Stefano Barbato <span dir="ltr">&lt;<a href="mailto:barbato@koanlogic.com" target="_blank">barbato@koanlogic.com</a>&gt;</span><br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br><div><div></div><div class="Wj3C7c">
Hi Steven,<br>
<br>
the attached patch should fix the POST-timeout bug you reported. Add the following code to the top-level Makefile:<br>
<br>
 &nbsp; &nbsp; &nbsp; &nbsp;KLONE_TARGET_PATCH_FILE = $(CURDIR)/klone-2.1.1-post-timeout.patch<br>
<br>
<br>
All POSTs with &quot;Content-length: 0&quot; were affected (the expiration timeout didn&#39;t get cleared in such condition).<br>
<br>
Please let me know if the patch solve your issues.<br>
<br>
Thanks again for your bug report,<div><br>
s<br>
<br>
<br>
<br>
<br>
<br>
On 05/dic/08, at 12:47, Steven Van Ingelgem wrote:<br>
<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><div></div><div>
Hi all,<br>
<br>
<br>
I bring in remembering my mail from 29/09/2008 about this problem.<br>
This issue still exists and I could replicate it.<br>
<br>
In attachment you will find the files I used to replicate the problem.<br>
Those will go into the webapp-directory.<br>
<br>
Best is that you re-configure the post-timeout to a very low value (I<br>
used 5s). You don&#39;t have, but then you&#39;ll have to wait 10 minutes to<br>
have kloned crash.<br>
<br>
The behaviour is as follows: It reads a JSON document from the server,<br>
and displays its context into the page. So you should have 1. 50, 2.<br>
50 etc etc with the 1st number always increasing indefinitly.<br>
What is happening is that kloned crashes around the 4th to 6th run (so<br>
after 5s after the 1st post done).<br>
<br>
<br>
Personally I think it&#39;s because some timer is not being removed while<br>
the request has already been handled (and removed).<br>
<br>
<br>
Greetings,<br>
Steven<br></div></div>
&lt;tmp.zip&gt;<br>
</blockquote>
<br></div></div>_______________________________________________<br>
Klone-users mailing list<br>
<a href="mailto:Klone-users@koanlogic.com" target="_blank">Klone-users@koanlogic.com</a><br>
<a href="http://koanlogic.com/cgi-bin/mailman/listinfo/klone-users" target="_blank">http://koanlogic.com/cgi-bin/mailman/listinfo/klone-users</a><br>
<br></blockquote></div><br>
</blockquote></div><br>