• 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: XCode debugging problems
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: XCode debugging problems


  • Subject: Re: XCode debugging problems
  • From: Jose Commins <email@hidden>
  • Date: Wed, 3 Dec 2003 12:13:53 +0000

On 2 Dec 2003, at 22:51, Jim Ingham wrote:


On Dec 2, 2003, at 6:48 AM, Jose Commins wrote:

	This may be a joint compiler/debugger problem, as I have similar
random crashes when debugging an app that works perfectly well without
the debugger (I've had to disassemble it using another app to see if
it was fine).

Xcode runs some functions in the address space of your program as part of its variable formatter. These should in general "do no harm" but it is possible they might not. This may indicate some latent bug in your program, or a bug in the formatters. Try turning of the Custom Data Formatting in the Xcode Debug menu and see if they go away. If they do, then it would be really helpful if we could figure out where you were stopped in your program, and what Xcode was trying to do, when the crash occurred.


I tell you, if it weren't for you guys and gals' invaluable help on these lists there would be a developer's riot outside Infinite Loop ;o)


I was pretty sure my function was kosher, as the disassembly showed nowt wrong, so I tried your suggestion of turning Custom Data Formatting off and (after Xcode crashing when selecting the menu item, having to do it again), the program debugged properly with no spurious crashes. It also stepped through the code faster.
When Custom Data Display is on I get that spurious 'gdb received 'EXC_BAD_ACCESS' signal, especially when tracing by line. This is the bit where it conks out usually, taken from the standard Carbon tab pane handler I use:


	if(window == adjustmentWindow)
	{
		controlID.signature = my_PANE_TABS_SIGNATURE;

		for ( i = 1 ; i < tabList[0] + 1 ; i++ )
		{
			controlID.id = tabList[i];
			GetControlByID( window, &controlID, &userPaneControl );

			if ( i == currentTabIndex )
			{
				selectedPaneControl = userPaneControl;
			 } else {
				SetControlVisibility( userPaneControl, false, true );
			}
		}
		if ( selectedPaneControl != NULL )
		{
			(void) ClearKeyboardFocus( window );
			SetControlVisibility( selectedPaneControl, true, true );
		}

		Draw1Control( tabControl );
	}


I reckon it could be the debugger is trying to walk a data reference in the wrong location; perhaps the .nib structure itself has bugs, resulting in dud pointers? It could explain the inconsistent display of dialogs when they use compositing on and off etc (I filed a bug report to a similar bug in .nib files), so it could be the OS structures the debugger is accessing which have an error.
If I am correct in my assumption, do I win a cuddly Apple bear? :o)



Regards, Jose.

--
Death, taxes and Microsoft. If you put it that way, the first two don't seem so bad.
_______________________________________________
xcode-users mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/xcode-users
Do not post admin requests to the list. They will be ignored.

  • Follow-Ups:
    • Re: XCode debugging problems
      • From: Jim Ingham <email@hidden>
  • Prev by Date: Re: What to do about "clobbered by `longjmp' or `vfork'" warnings?
  • Next by Date: using XCode with IBM XL C
  • Previous by thread: Re: XCode debugging problems and SIGBUS at certain breakpoints in 7K109
  • Next by thread: Re: XCode debugging problems
  • Index(es):
    • Date
    • Thread