[Gc] GoAhead WEBs server and GC
hans.boehm at hp.com
Thu Jul 8 10:40:36 PDT 2004
Unfortunately, after looking at the code again, I still have no
Note that the registered offsets are byte offsets.
To clarify: If GC_DEBUG is not defined, GC_register_displacement
and GC_REGISTER_DISPLACEMENT are synonymous. If GC_DEBUG is defined,
the collector itself adds a header to all objects allocated through
GC_MALLOC and the like. Hence any offsets you register are
added to the one introduced by the debug header. (Actually, both
the plain offset and the sum are registered in case you call GC_malloc
instead of GC_MALLOC.)
If you can easily use GC_DEBUG and haven't done so, I would try building
that way. It may point out a problem in the client code.
One specific client problem I would check for is the case in which
the offset is larger than the size of the object to which it applies,
so the resulting pointer is outside the object. In this case, the
collector won't retain the object. (Unless you've told the collector
not to add the extra byte at the end of objects, this shouldn't happen
in strictly conforming C code.)
You might also be able to isolate this sort of problem by, say, allocating
all objects with an extra 16 bytes. This will also hide many other sins.
If that fixes the problem, you can then track it down by gradually
overallocating more selectively.
> -----Original Message-----
> From: Jim Marshall [mailto:jim.marshall at wbemsolutions.com]
> Sent: Thursday, July 08, 2004 8:34 AM
> To: Boehm, Hans
> Cc: gc at napali.hpl.hp.com
> Subject: Re: [Gc] GoAhead WEBs server and GC
> 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.
> 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
> >has been called.
> >If not, stack and register interior pointers should still be
> >(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.
> >>-----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
> >> 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
> >>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
> >>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