[Klone-users] Re: "Segmentation fault" in kloned

[Steven Van Ingelgem]

More detailed information:


==15424== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 23 from 1)
==15424== malloc/free: in use at exit: 2,256 bytes in 112 blocks.
==15424== malloc/free: 15,476 allocs, 15,364 frees, 6,641,755 bytes
allocated.
==15424== For counts of detected errors, rerun with: -v
==15424== searching for pointers to 112 not-freed blocks.
==15424== checked 124,560 bytes.
==15424==
==15424== 2,248 (2,008 direct, 240 indirect) bytes in 99 blocks are
definitely lost in loss record 3 of 3
==15424==    at 0x401C6CA: calloc (vg_replace_malloc.c:279)
==15424==    by 0x8090D32: u_zalloc (memory.c:63)
==15424==    by 0x808E1B3: u_hmap_o_new (hmap.c:1072)
==15424==    by 0x80748FC: emb_register (emb.c:69)
==15424==    by 0x807D92A: module_init_3c03a85447646e5d5127801337173786
(pg_3c03a85447646e5d5127801337173786.c:67)
==15424==    by 0x80793D0: do_register (register.c:22)
==15424==    by 0x80793BD: register_pages (register.c:9)
==15424==    by 0x80746FF: emb_init (emb.c:32)
==15424==    by 0x805072D: app_init (main.c:96)
==15424==    by 0x8050DF4: main (entry.c:397)
==15424==
==15424== LEAK SUMMARY:
==15424==    definitely lost: 2,008 bytes in 99 blocks.
==15424==    indirectly lost: 240 bytes in 12 blocks.
==15424==      possibly lost: 0 bytes in 0 blocks.
==15424==    still reachable: 8 bytes in 1 blocks.
==15424==         suppressed: 0 bytes in 0 blocks.
==15424== Reachable blocks (those to which a pointer was found) are not
shown.
==15424== To see them, rerun with: --show-reachable=yes


2008/12/5 Steven Van Ingelgem <steven at vaningelgem.be>

> Seems that did the trick ;-)
>
> Still:
> ==9064== LEAK SUMMARY:
> ==9064==    definitely lost: 2,248 bytes in 111 blocks.
> ==9064==      possibly lost: 0 bytes in 0 blocks.
> ==9064==    still reachable: 8 bytes in 1 blocks.
> ==9064==         suppressed: 0 bytes in 0 blocks.
>
>
>
> 2008/12/5 Stefano Barbato <barbato at koanlogic.com>
>
>>
>> Hi Steven,
>>
>> the attached patch should fix the POST-timeout bug you reported. Add the
>> following code to the top-level Makefile:
>>
>>        KLONE_TARGET_PATCH_FILE = $(CURDIR)/klone-2.1.1-post-timeout.patch
>>
>>
>> All POSTs with "Content-length: 0" were affected (the expiration timeout
>> didn't get cleared in such condition).
>>
>> Please let me know if the patch solve your issues.
>>
>> Thanks again for your bug report,
>> s
>>
>>
>>
>>
>>
>> On 05/dic/08, at 12:47, Steven Van Ingelgem wrote:
>>
>>  Hi all,
>>>
>>>
>>> I bring in remembering my mail from 29/09/2008 about this problem.
>>> This issue still exists and I could replicate it.
>>>
>>> In attachment you will find the files I used to replicate the problem.
>>> Those will go into the webapp-directory.
>>>
>>> Best is that you re-configure the post-timeout to a very low value (I
>>> used 5s). You don't have, but then you'll have to wait 10 minutes to
>>> have kloned crash.
>>>
>>> The behaviour is as follows: It reads a JSON document from the server,
>>> and displays its context into the page. So you should have 1. 50, 2.
>>> 50 etc etc with the 1st number always increasing indefinitly.
>>> What is happening is that kloned crashes around the 4th to 6th run (so
>>> after 5s after the 1st post done).
>>>
>>>
>>> Personally I think it's because some timer is not being removed while
>>> the request has already been handled (and removed).
>>>
>>>
>>> Greetings,
>>> Steven
>>> <tmp.zip>
>>>
>>
>> _______________________________________________
>> Klone-users mailing list
>> Klone-users at koanlogic.com
>> http://koanlogic.com/cgi-bin/mailman/listinfo/klone-users
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://koanlogic.com/pipermail/klone-users/attachments/20081205/0cb28156/attachment.htm