• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: How 'reliable' is MallocCheckHeap et al ?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: How 'reliable' is MallocCheckHeap et al ?


  • Subject: Re: How 'reliable' is MallocCheckHeap et al ?
  • From: Andrew Kimpton <email@hidden>
  • Date: Fri, 24 Sep 2004 20:36:14 -0700

Eric Albert wrote:

On Sep 24, 2004, at 11:07 AM, Andrew Kimpton wrote:

I'm struggling to chase down what at first glance should be a relatively simple memory smashing bug.

I'm using the MallocDebug environment variables :


Have you tried using Guard Malloc? It catches memory smashers very effectively and pinpoints the exact place of the fault. (It also causes your application to run about 100x slower than normal, but that's worth it when you catch a memory smasher as a result.)

I have but I'm not sure how much it helps :-) I now get a EXC_BAD_ACCESS from pthread_mutex_init(). My code uses boost_1_30_0 for it's shared_ptr classes and this particular pthread_mutex_init is being called to initialize a member mutex within the boost lightweight_mutex class. It *is* crashing from code called 'further along' the call stack I gave previously, but it's still very puzzling since the mutext structure passed in a class member for lightweight_mutex which is (ultimately) a class member.

Breaking on pthread_mutex_init the pointer being given seems to point to a 'short' block which is only 5 words (20 bytes) in length, The pthread headers indicate that the pthread_mutex_t is 44 bytes long (a long plus 40 char array). Previous calls (from the same constructor) to pthread_mutex_init seem to be supplying a large enough block.

This undersized allocation seems to be causing the problem but I'm not sure how it can be occurring in this one spot. The pthread_mutex_t is a class member and the pthread_mutex_init() is called in the class constructor. This code path is very well exercised so why would it fail here having been called hundreds (if not thousands) of times without error previously ? The code in question is boost_1_30_0/boost/detail/lwm_pthreads.hpp

Am I looking at some sort of strange compiler bug ?

I can certainly see how giving a 'short' block to pthread_mutex_init would cause all sorts of strange problems due to corruption etc. Although I'm a little surprised that this same *OBJECT* code is linked in (via a static library) to two other products and neither of them exhibit this failure (yet).


Andrew 8-)

_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


  • Follow-Ups:
    • Re: How 'reliable' is MallocCheckHeap et al ?
      • From: Eric Albert <email@hidden>
References: 
 >How 'reliable' is MallocCheckHeap et al ? (From: Andrew Kimpton <email@hidden>)
 >Re: How 'reliable' is MallocCheckHeap et al ? (From: Eric Albert <email@hidden>)

  • Prev by Date: Re: FAQ: How do you debug a C++ Standard Tool Application?
  • Next by Date: Re: Java, Xcode, CodeSense, java docs, etc.
  • Previous by thread: Re: How 'reliable' is MallocCheckHeap et al ?
  • Next by thread: Re: How 'reliable' is MallocCheckHeap et al ?
  • Index(es):
    • Date
    • Thread