[Gc] GoAhead WEBs server and GC

Jim Marshall jim.marshall at wbemsolutions.com
Thu Jul 8 08:33:37 PDT 2004


Hi Hans,
 Yes Alec and I have been working on this problem together. We did get 
your reply and as far as we can tell we already have the 
GC_all_interior_pointers set, in addition Alec tried the 
GC_register_displacement as you suggested with no luck. We will look at 
the all caps version. Perhaps we don't fully understand how these 
functions should be used? Basically when our application starts we 
called GC_register_displacement with a value of 2 (which is the offset 
in the WEBs code).
 I had hoped (it was a fleeting hope) that someone on the alias had 
possibly used WEBs before and may have run into this or had some 
thoughts on it.

 It appears that WEBs uses a "fancy" hashtable, where they allocate a 
block of memory and then return an offset into the allocated block (the 
code Alec sent was basically what they do). We have not been able to 
write a small example to duplicate the problem, the one test case we did 
get to fail had a very large offset and neither of us felt it really 
applied to our problem. Anyway when we enable http keep alive in WEBs we 
always get smashed objects when this hashtable code tries to free 
memory. But we can not narrow down why.

We have been working on this for a month now (at least) and it is 
seriously impacting our products schedule. We finally got to a point 
where we can use http keep alive without the smashed objects, by having 
the WEBs code use the uncollectable heap. Unfortunately this causes our 
applications heap usage to grow endlessly (albeit slowly).

Any input you may have is welcome.

Thank you for your time.
-Jim

Boehm, Hans wrote:

>I think Alec Orr posted the same question earlier today.  I posted a partial reply.
>You need to check whether your GC configuration is correct.  If so, a small
>self-contained test case that fails would make this much easier to track down.
>The standard test program tests this to some extent, so I would be surprised if
>the interior pointer support were completely broken.
>
>It's also worth checking that the pointer manipulation code which adds the
>offset is doing something plausible.  The code that Alec posted is
>suspicious because allocMem does not add OFFSET to the size of the object
>it requests from GC_MALLOC, but that may have been the way the code was
>abbreviated.
>
>(If you plan to use GC_DEBUG, you should really use the all-caps
>GC_REGISTER_DISPLACEMENT, not GC_register_displacement as I suggested below.)
>
>My earlier reply:
>
>This depends on the GC configuration.  The code below should be OK
>if GC_all_interior_pointers is set, or if GC_register_displacement(OFFSET)
>has been called.
>
>If not, stack and register interior pointers should still be recognized
>(to deal with frequent compiler optimizations), but interior pointers
>from the heap and static data will not be.
>
>If you have a small example for which the GC doesn't behave that way, I'd love
>to see it.
>
>Hans
>
>  
>
>>-----Original Message-----
>>From: gc-bounces at napali.hpl.hp.com
>>[mailto:gc-bounces at napali.hpl.hp.com]On Behalf Of Jim Marshall
>>Sent: Wednesday, July 07, 2004 1:53 PM
>>To: gc at napali.hpl.hp.com
>>Subject: [Gc] GoAhead WEBs server and GC 
>>
>>
>>Hi,
>> We've been trying to track down some issues with a third 
>>party program 
>>for about a month now, and have come up empty. I am hoping 
>>that someone 
>>on the alias may have some experience with this.
>>
>>Our program is incorporating the GoAhead WEBs server 
>>(http://webserver.goahead.com/webserver/webserver.htm). If you would 
>>like to look at the WEBs code you can get it here 
>>http://www.iconnextion.com/~jm109344/webs218.tar.gz
>>
>>Basically, if we enable the http keep alive (uncomment line 28 in 
>>wsIntrn.h), and we make multiple requests with the same 
>>client we start 
>>getting smashed objects. This seems to occur in code which allocates 
>>memory but doesn't return the base of the allocation, but instead 
>>returns an offset into that allocated buffer.
>>
>>This works (or appears to) with regular malloc and dmalloc reports no 
>>errors.
>>
>>Has anyone had any experience with WEBs and using the GC with it?
>>
>>desperately
>>-Jim
>>
>>_______________________________________________
>>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