[Gc] OpenSSL with GC 6.2 - NO RESPONSE REQUIRED

Alec Orr Alec.Orr at wbemsolutions.com
Fri Feb 13 17:44:08 PST 2004


Folks:

Just to close this out:  The problem we were having was caused by a 
recursion happening in the webserver's socket event loop.  Due to poorly 
crafted conditional, our socket event handler was being called and just 
falling out (without pulling the PENDING and READABLE socket data, or 
closing the socket handler).  Hence the socket handler stacks kept 
piling up and stack variables to allocated stuctures were still around 
(and pointed to once - #1 below) so the mark-sweep gc had no reason to 
think they were freed.

Bottom line:  The problem was not the garbage collector or SSL with the GC.

Thanks again David and Hans for your suggestions in tracking this down,
Alec Orr
WBEM Solutions

Boehm, Hans wrote:

> The # of marks set number is just a count of the mark bits set for that heap
> block.  Between collections this will be the number of objects in the block
> that were reachable at the last GC.  It excludes newly allocated objects, even
> if they are reachable.
> 
> I'd put a conditional breakpoint in GC_malloc to see who's allocating 4100 byte
> objects.  That's a bit annoying anyway, since that's a pessimal object size;
> they occupy 8192 bytes.  Presumably the request is for 4096 bytes, but the
> collector adds 4 to deal with one-past-the-end pointers.
> 
> If I had to make a wild guess, I'd say that either:
> 
> 1) These objects are permanently referenced.  The original code may have deallocated
> them, but left a dangling reference which was (hopefully) never followed.  
> 
> 2) They are part of an unboundedly growing data structure (typically a linked queue)
> that was hit by a false reference.
> 
> I think (1) is more likely than (2) in this case, though both are very rare.
> The fix in both cases would be to arrange to clear the offending link field, or
> possibly to preserve explicit deallocations for these objects, or perhaps to
> manage these objects differently altogether.
> 
> Hans
> 
> 
>>-----Original Message-----
>>From: gc-bounces at napali.hpl.hp.com
>>[mailto:gc-bounces at napali.hpl.hp.com]On Behalf Of Alec Orr
>>Sent: Monday, February 09, 2004 4:02 PM
>>To: gc at napali.hpl.hp.com
>>Subject: [Gc] Has anyone tried using OpenSSL with GC 6.2 in Linux?
>>
>>
>>RH 8.  GC 6.2 compiled debug w/ posix target, ALL_INTERIOR_POINTERS, 
>>redirect_malloc, gc-assertions enabled.
>>
>>Good evening,
>>
>>I realize there's not much anyone can do (too many variables 
>>here), but 
>>if anyone recalls any pitfalls with using OpenSSL in a GC enabled 
>>environment, or suggestions , would be greatly appreciated.
>>
>>We have a test application which makes use of OpenSSL 9.7b 
>>(shared lib). 
>>  When we combine OpenSSL (via GoAhead webserver) with GC, we notice 
>>many 4100 byte normal blocks which are allocated and never 
>>freed.  These 
>>blocks stay in memory forever, and continue to grow.
>>
>>One question.  In a GC_dump() there is a field for 
>>#_marks_set, to what 
>>does this refer?
>>
>>Thank you,
>>Alec Orr
>>WBEM Solutions
>>
>>
>>BEFORE SSL REQEUST:
>>==================
>>***Static roots:
>> From 0x8049000 to 0x804a000  (temporary)
>> From 0x804a000 to 0x805a000  (temporary)
>> From 0x40012000 to 0x40013000  (temporary)
>> From 0x40017000 to 0x40018000  (temporary)
>> From 0x40018000 to 0x40019000  (temporary)
>> From 0x40034000 to 0x40039000  (temporary)
>> From 0x40039000 to 0x40044000  (temporary)
>> From 0x40048000 to 0x40049000  (temporary)
>> From 0x4004b000 to 0x4004c000  (temporary)
>> From 0x4004e000 to 0x4004f000  (temporary)
>> From 0x40077000 to 0x40079000  (temporary)
>> From 0x4007b000 to 0x4007c000  (temporary)
>> From 0x4007f000 to 0x40080000  (temporary)
>> From 0x40080000 to 0x40081000  (temporary)
>> From 0x40087000 to 0x40088000  (temporary)
>> From 0x40095000 to 0x40098000  (temporary)
>> From 0x40098000 to 0x400b8000  (temporary)
>> From 0x400d8000 to 0x400d9000  (temporary)
>> From 0x400de000 to 0x400df000  (temporary)
>> From 0x401d1000 to 0x401e4000  (temporary)
>> From 0x401e4000 to 0x401e7000  (temporary)
>> From 0x4043f000 to 0x40440000  (temporary)
>> From 0x40445000 to 0x40446000  (temporary)
>> From 0x40466000 to 0x4046a000  (temporary)
>> From 0x40473000 to 0x40474000  (temporary)
>> From 0x42126000 to 0x4212b000  (temporary)
>> From 0x4212b000 to 0x4212f000  (temporary)
>>Total size: 491520
>>
>>***Heap sections:
>>Tota
>>l heap size: 319488
>>Section 0 from 0x805a000 to 0x806a000 0/16 blacklisted
>>Section 1 from 0x807a000 to 0x808a000 1/16 blacklisted
>>Section 2 from 0x809a000 to 0x80b4000 0/26 blacklisted
>>Section 3 from 0x80b4000 to 0x80c8000 1/20 blacklisted
>>
>>***Free blocks:
>>Free list 1 (Total size 8192):
>>         0x807f000 size 4096 not black listed
>>         0x807a000 size 4096 start black listed
>>Free list 3 (Total size 12288):
>>         0x80b4000 size 12288 not black listed
>>Free list 16 (Total size 65536):
>>         0x80b8000 size 65536 partially black listed
>>Total of 86016 bytes on free list
>>
>>***Blocks in use:
>>(kind(0=ptrfree,1=normal,2=unc.,3=stubborn):size_in_bytes, 
>>#_marks_set)
>>(1:24,23)(1:16,197)(1:4100,1)(1:16,256)(1:16,256)(1:16,256)(1:
>>16,256)(1:16,256)(
>>1:24,170)(1:16,256)(1:61444,1)(1:312,11)(1:584,3)(1:1360,1)(1:
>>816,1)(1:8164,1)(1
>>:24,58)(1:256,1)(1:224,5)(1:192,2)(1:168,9)(1:72,6)(1:48,17)(1
>>:8,47)(1:32,50)(1:
>>128,2)(1:80,6)(1:56,11)(1:112,7)(1:584,7)(1:64,3)(1:96,7)(1:40
>>,24)(1:8220,1)(1:3
>>68,1)(1:16,82)(1:144,3)(1:24,94)
>>blocks = 38, bytes = 233472
>>
>>***Finalization statistics:
>>0 finalization table entries; 0 disappearing links
>>0 objects are eligible for immediate finalization
>>
>>
>>AFTER 1 SSL REQEUST AND 1 INVOKED GC - GC_gcollect():
>>=====================================================
>>
>>***Static roots:
>> From 0x8049000 to 0x804a000  (temporary)
>> From 0x804a000 to 0x805a000  (temporary)
>> From 0x40012000 to 0x40013000  (temporary)
>> From 0x40017000 to 0x40018000  (temporary)
>> From 0x40018000 to 0x40019000  (temporary)
>> From 0x40034000 to 0x40039000  (temporary)
>> From 0x40039000 to 0x40044000  (temporary)
>> From 0x40048000 to 0x40049000  (temporary)
>> From 0x4004b000 to 0x4004c000  (temporary)
>> From 0x4004e000 to 0x4004f000  (temporary)
>> From 0x40077000 to 0x40079000  (temporary)
>> From 0x4007b000 to 0x4007c000  (temporary)
>> From 0x4007f000 to 0x40080000  (temporary)
>> From 0x40080000 to 0x40081000  (temporary)
>> From 0x40087000 to 0x40088000  (temporary)
>> From 0x40095000 to 0x40098000  (temporary)
>> From 0x40098000 to 0x400b8000  (temporary)
>> From 0x400d8000 to 0x400d9000  (temporary)
>> From 0x400de000 to 0x400df000  (temporary)
>> From 0x401d1000 to 0x401e4000  (temporary)
>> From 0x401e4000 to 0x401e7000  (temporary)
>> From 0x4043f000 to 0x40440000  (temporary)
>> From 0x40445000 to 0x40446000  (temporary)
>> From 0x40466000 to 0x4046a000  (temporary)
>> From 0x40473000 to 0x40474000  (temporary)
>> From 0x42126000 to 0x4212b000  (temporary)
>> From 0x4212b000 to 0x4212f000  (temporary)
>>Total size: 491520
>>
>>***Heap sections:
>>Total heap size: 786432
>>Section 0 from 0x805a000 to 0x806a000 0/16 blacklisted
>>Section 1 from 0x807a000 to 0x808a000 0/16 blacklisted
>>Section 2 from 0x809a000 to 0x80b4000 0/26 blacklisted
>>Section 3 from 0x80b4000 to 0x80c8000 1/20 blacklisted
>>Section 4 from 0x80c8000 to 0x80e4000 1/28 blacklisted
>>Section 5 from 0x80e4000 to 0x8109000 0/37 blacklisted
>>Section 6 from 0x8109000 to 0x813a000 2/49 blacklisted
>>
>>***Free blocks:
>>Free list 1 (Total size 16384):
>>         0x8109000 size 4096 start black listed
>>         0x80e0000 size 4096 start black listed
>>         0x80e4000 size 4096 not black listed
>>         0x80c0000 size 4096 start black listed
>>Free list 33 (Total size 180224):
>>         0x810e000 size 180224 partially black listed
>>Total of 196608 bytes on free list
>>
>>***Blocks in use:
>>(kind(0=ptrfree,1=normal,2=unc.,3=stubborn):size_in_bytes, 
>>#_marks_set)
>>(1:4100,1)(1:4100,1)(1:4100,1)(1:4100,1)(1:4100,1)(1:4100,1)(1
>>:4100,1)(1:4100,1)
>>(1:4100,1)(1:4100,1)(1:4100,1)(1:4100,1)(1:4100,1)(1:4100,1)(1
>>:4100,1)(1:4100,1)
>>(1:4100,1)(1:4100,1)(1:4100,1)(1:4100,1)(1:816,5)(1:4100,1)(1:
>>312,5)(1:4100,1)(1
>>:4100,1)(1:4100,1)(1:4100,1)(1:4100,1)(1:4100,1)(1:4100,1)(1:4
>>100,1)(1:4100,1)(1
>>:4100,1)(1:4100,1)(1:816,1)(1:72,10)(1:4100,1)(1:4100,1)(1:410
>>0,1)(1:4100,1)(1:4
>>100,1)(1:4100,1)(1:4100,1)(1:24,23)(1:312,13)(1:4100,1)(1:16,1
>>97)(1:4100,1)(1:16
>>,256)(1:16,256)(1:16,256)(1:16,256)(1:16,256)(1:24,170)(1:16,2
>>56)(1:61444,1)(1:3
>>12,13)(1:584,3)(1:1360,1)(1:816,5)(1:8164,1)(1:24,58)(1:256,1)
>>(1:224,5)(1:192,2)
>>(1:816,5)(1:168,8)(1:72,56)(1:48,17)(1:8,47)(1:816,5)(1:32,70)
>>(1:128,2)(1:80,26)
>>(1:56,11)(1:112,7)(1:584,7)(1:64,3)(1:96,5)(1:40,44)(1:8220,1)
>>(1:368,1)(1:16,84)
>>(1:144,3)(1:24,94)
>>blocks = 85, bytes = 589824
>>
>>_______________________________________________
>>Gc mailing list
>>Gc at linux.hpl.hp.com
>>http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
>>
> 
> _______________________________________________
> Gc mailing list
> Gc at linux.hpl.hp.com
> http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
> 
> 
> 




More information about the Gc mailing list