[omniORB] Re: Testing OmniORB4 for memory leaks on Linux RH9 w/
valgrind
Sean Parker
supinlick at yahoo.com
Wed Jun 8 21:26:19 BST 2005
Hello -
I've finally had a chance to revisit the 'memory' - and
I've run valgrind, and found no leaks/errors for simply
bringing up the orb and then destroying it.
However when I add activating-the-POA, I get these two
kinds of errors from valgrind:
1) leak of ~8160 bytes due to pthread
2) several "use of uninitialized bytes"
I've seen both of these on my own testing framework, so
I'm not at all surprised. I had to have a fairly
substantial "suppress" file (to hide #2 issues) for
valgrind for things to "run clean" on my stuff.
However the first 'leak' is very annoying to me and I'm
wondering if anyone knows if a) I'm doing domething wrong
with pthread, b) there's a kernel patch, or c) there's a
glibc patch that would fix that "bug" in the pthread. (of
course the work around is to ignore it via supression
entry)
Does anyone know what valgrind is really complaining
about on the/any "unitialized bytes"? (for example placing
a shift operation in a while() makes valgrind complain the
whiled-value is unitialized) Do you guys out there that
have done more work with valgrind on omniORB simply make a
huge suppression file? If so - can I get a copy? If
valgrind has a lot of ridiculously-anal errors that we
always have to make supressions-for - has anyone submitted
requests for patches/changes?
Any assistance greatly appreciated... I'll push on - but
making a silly suppression file :-)
Cheers
Sean
P.S. I'm happy with valgrind aside from the 'unit-bytes'
issue, it of-course blows mtrace away...
--- "Visscher, Bruce" <VISSCHB at RJRT.com> wrote:
> Please search the archives before proceeding.
>
> Make sure you are doing everything properly w.r.t. memory
> allocation/deallocation.
>
> I don't have any problems with omniORB memory allocation
> going
> back to omniORB 2.8.0. I believe omniORB 4 addresses
> even
> "red herring" reports of memory leaks by various 3rd
> party tools.
>
> > -----Original Message-----
> > From: omniorb-list-bounces at omniorb-support.com
> > [mailto:omniorb-list-bounces at omniorb-support.com]On
> Behalf Of Sean
> > Parker
> > Sent: Monday, June 06, 2005 11:03 AM
> > To: Sean Parker; omniorb-list at omniorb-support.com
> > Subject: [omniORB] Re: Testing OmniORB4 for memory
> leaks on Linux RH9
> >
> >
> > Re: mtrace of ORB_init-then-orb->destroy:
> >
> > I did some 'commenting-out' in the ORB_init mehod, and
> > found most allocation-danglers dissappear when the
> > omniOptions-calls were gone - then even more go away
> when I
> > comment-out matching interecptor attach/detaches.
> >
> > Is the community open to me submitting a future patch
> that
> > begins to fix these leaks (after more digging and
> > uncommenting of course)? (it seems reasonable to expect
> an
> > ORB-init followed by orb->destroy would leave no
> dangling
> > memory, regardless of realtiy of the scenario)
> >
> > Cheers
> > Sean
> >
> >
> > --- Sean Parker <supinlick at yahoo.com> wrote:
> >
> > > Hello -
> > >
> > > I'm trying to begin using an ORB 'right' on our
> project
> > > and taking small steps... (I have > 5yrs exp w/
> CORBA,
> > > but
> > > new to C++ ORBs - I'm also <2yrs on Linux too)
> > > So using mtrace, and doing an ORB_init() then
> > > immediately
> > > an orb->destroy, then stopping mtrace, shows many
> (>40
> > > separate) allocations (ranging from 0x4 to 0x100
> bytes).
> > > Are these 'static' allocations? Has anyone else done
> > > this/seen this behavior with mtrace? (I have a
> testing
> > > framework using mtrace, and I'm confident it's the
> > > ORB-part
> > > due to no memory leaks when I comment-out the
> > > ORB_init/destroy)
> > >
> > > For giggles, I tried activating the POAManager in
> > > between, and it showed only several more allocations.
>
> > >
> > > If anyone has experience w/ mtrace and omniORB4,
> please
> > > send confidence/lessons learned, etc. I'd like to use
> > > omniORB4, but can't if these are legitimate
> (unwanted)
> > > leaks.
> > >
> > > Cheers,
> > > Sean
> > >
> > > P.S. I found the user manual very easy to follow, and
> a
> > > few
> > > steps above any other ORB user guides I've seen (but
> of
> > > course that hinges on my level of experience...)
> > > It would be nice to have a section on troubleshooting
> > > build
> > > issues (ie. what happens when the libraries are out
> of
> > > order for ld/gcc linking)
> > >
> > >
> > >
> > >
> > > God Bless
> > > Sean Parker
> > >
> > >
> > >
> > >
> > >
> > >
> > > __________________________________
> > > Discover Yahoo!
> > > Find restaurants, movies, travel and more fun for the
> > > weekend. Check it out!
> > > http://discover.yahoo.com/weekend.html
> > >
> > >
> >
> >
> >
> >
> >
> > God Bless
> > Sean Parker
> >
> >
> >
> >
> >
> >
> > __________________________________
> > Do you Yahoo!?
> > Read only the mail you want - Yahoo! Mail SpamGuard.
> > http://promotions.yahoo.com/new_mail
> >
> > _______________________________________________
> > omniORB-list mailing list
> > omniORB-list at omniorb-support.com
> >
>
http://www.omniorb-support.com/mailman/listinfo/omniorb-list
> >
>
> -----------------------------------------
> CONFIDENTIALITY NOTE: This e-mail message, including any
> attachment(s),
> contains information that may be confidential, protected
> by the attorney-
> client or other legal privileges, and/or proprietary
> non-public
> information. If you are not an intended recipient of
> this message or an
> authorized assistant to an intended recipient, please
> notify the sender by
> replying to this message and then delete it from your
> system. Use,
> dissemination, distribution, or reproduction of this
> message and/or any of
> its attachments (if any) by unintended recipients is not
> authorized and
> may be unlawful.
>
>
God Bless
Sean Parker
__________________________________
Discover Yahoo!
Find restaurants, movies, travel and more fun for the weekend. Check it out!
http://discover.yahoo.com/weekend.html
More information about the omniORB-list
mailing list