[Gc] GoAhead WEBs server and GC
jim.marshall at wbemsolutions.com
Thu Jul 8 08:33:37 PDT 2004
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.
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
>(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.
>>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
>> We've been trying to track down some issues with a third
>>for about a month now, and have come up empty. I am hoping
>>on the alias may have some experience with this.
>>Our program is incorporating the GoAhead WEBs server
>>(https://webserver.goahead.com/webserver/webserver.htm). If you would
>>like to look at the WEBs code you can get it here
>>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
>>Has anyone had any experience with WEBs and using the GC with it?
>>Gc mailing list
>>Gc at linux.hpl.hp.com
More information about the Gc