• 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: Debugging with Xcode 2.3 crashes gdb.
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Debugging with Xcode 2.3 crashes gdb.


  • Subject: Re: Debugging with Xcode 2.3 crashes gdb.
  • From: "Arne Scheffler" <email@hidden>
  • Date: Thu, 25 May 2006 23:44:59 +0200

I have a sample project. Look at my bugreport. It doesn't crash Xcode,
but it brings gdb into an infinite loop while trying to print out the
class. I think this should be the problem we have here.

arne


On 5/25/06, Jim Ingham <email@hidden> wrote:
Eh, I should have remembered this...

In the first log, we were crashing on listing the arguments for

StMedia::FolderNode::getSubNodes

In the newest log, we crash listing the arguments for
FNFileSystem::getDrives.

Are there any common types between these two?  You could try running
in command-line gdb, and:

(gdb) print <ARG>

for all the function arguments in these functions, and see if one of
these goes south.  That's the major difference between Xcode &
command-line gdb, Xcode always fetches values for all the arguments.

Jim


On May 25, 2006, at 12:20 PM, Arne Scheffler wrote:

> done. see bug 4504668
>
> thanks
> arne
>
>
> On 5/25/06, Jim Ingham <email@hidden> wrote:
>> Interesting...  Can you get the Xcode-gdb log for the crashing
>> session and file a bug including that.  To get the log, do:
>>
>> 1) Quit Xcode.
>> 2) In Terminal, say:
>>
>> $ defaults write com.apple.Xcode PBXGDBDebuggerLogToFile YES
>> $ defaults write com.apple.Xcode PBXGDBDebuggerLogFileName /tmp/
>> IncludeInBug.log
>>
>> 3) Restart Xcode, and do whatever you need to to make it fail.
>> 4) Attach /tmp/IncludeInBug.log to the Radar.
>>
>> Also, before generating the log can you create a file called
>> ".gdbinit" in your home directory (if you don't already have one) and
>> put:
>>
>> set verbose 1
>>
>> in there.  That will cause gdb to print a record each time is scarfs
>> the debug info from a module.
>>
>> This way we can at least tell what operation on what file is causing
>> the crash.  I'll be better able to tell where to go from there.
>>
>> Thanks,
>>
>> Jim
>>
>> On May 25, 2006, at 11:29 AM, Arne Scheffler wrote:
>>
>> > It's already switched to DWARF. Running my app with gdb (outside
>> > Xcode) does not result in a crash.
>> >
>> > arne
>> >
>> > On 5/25/06, Jim Ingham <email@hidden> wrote:
>> >> Try switching debug formats to DWARF from stabs.  This crash is
>> the
>> >> result of some cycle in the type information for some object.
>> This
>> >> can happen in stabs if you use C++ namespaces because stabs
>> doesn't
>> >> record namespace info.
>> >>
>> >> Jim
>> >>
>> >> On May 25, 2006, at 11:03 AM, Arne Scheffler wrote:
>> >>
>> >> > Hi,
>> >> > I'm just searching for others having the same crashes as I am.
>> >> While
>> >> > stepping through our code, Xcode seems to send bogus stuff to
>> gdb,
>> >> > where gdb just crashes. Half of the time I'm trying to debug
>> >> > something, it crashes. Then I need to use printf to track bugs
>> >> down.
>> >> >
>> >> > Bug ID : 4504668
>> >> >
>> >> > Here are the first few lines of the crashlog :
>> >> >
>> >> > Thread 0 Crashed:
>> >> > 0   libSystem.B.dylib         0x900101d4 __sfvwrite + 20
>> >> > 1   libSystem.B.dylib         0x9000fe88 __vfprintf$LDBL128 +
>> 15824
>> >> > 2   libSystem.B.dylib         0x900ee820 vasprintf$LDBL128 + 244
>> >> > 3   gdb-powerpc-apple-darwin  0x0001ddc4 xstrvprintf + 48
>> >> > 4   gdb-powerpc-apple-darwin  0x0001f094 vfprintf_maybe_filtered
>> >> + 52
>> >> > 5   gdb-powerpc-apple-darwin  0x0001f148 fprintf_filtered + 56
>> >> > 6   gdb-powerpc-apple-darwin  0x00110f88 cp_print_value_fields +
>> >> 116
>> >> > 7   gdb-powerpc-apple-darwin  0x00111674 cp_print_value_fields +
>> >> 1888
>> >> > 8   gdb-powerpc-apple-darwin  0x00111da8 cp_print_value + 1204
>> >> > 9   gdb-powerpc-apple-darwin  0x00110fe4 cp_print_value_fields +
>> >> 208
>> >> > 10  gdb-powerpc-apple-darwin  0x00111da8 cp_print_value + 1204
>> >> > 11  gdb-powerpc-apple-darwin  0x00110fe4 cp_print_value_fields +
>> >> 208
>> >> > 12  gdb-powerpc-apple-darwin  0x00111674 cp_print_value_fields +
>> >> 1888
>> >> > 13  gdb-powerpc-apple-darwin  0x00111da8 cp_print_value + 1204
>> >> > 14  gdb-powerpc-apple-darwin  0x00110fe4 cp_print_value_fields +
>> >> 208
>> >> >
>> >> > it goes on until line 508. I investigated further, attached a
>> >> gdb to
>> >> > gdb to see what the start of this crash looks like, and gdb
>> >> shows me
>> >> > this stack trace :
>> >> >
>> >> > #30118 0x000d1070 in cp_print_value_fields ()
>> >> > #30119 0x000d1920 in cp_print_value ()
>> >> > #30120 0x000d08b4 in cp_print_value_fields ()
>> >> > #30121 0x000d1070 in cp_print_value_fields ()
>> >> > #30122 0x000d1920 in cp_print_value ()
>> >> > #30123 0x000d08b4 in cp_print_value_fields ()
>> >> > #30124 0x000d1070 in cp_print_value_fields ()
>> >> > #30125 0x000d1920 in cp_print_value ()
>> >> > #30126 0x000d08b4 in cp_print_value_fields ()
>> >> > #30127 0x000d1920 in cp_print_value ()
>> >> > #30128 0x000d08b4 in cp_print_value_fields ()
>> >> > #30129 0x000cfa3b in c_val_print ()
>> >> > #30130 0x00047f46 in common_val_print ()
>> >> > #30131 0x000cf95a in c_val_print ()
>> >> > #30132 0x00047f46 in common_val_print ()
>> >> > #30133 0x000c58ab in c_value_of_variable ()
>> >> > #30134 0x000c72d6 in gdb_varobj_get_value ()
>> >> > #30135 0x0001152f in print_syms_for_block ()
>> >> > #30136 0x00011f1f in list_args_or_locals ()
>> >> > #30137 0x00012097 in mi_cmd_stack_list_args ()
>> >> > #30138 0x0001715c in captured_mi_execute_command ()
>> >> > #30139 0x00074239 in catch_exception ()
>> >> > #30140 0x00016548 in mi_execute_command ()
>> >> > #30141 0x000166ef in mi_execute_command_wrapper ()
>> >> > #30142 0x00076c03 in handle_file_event ()
>> >> > #30143 0x00076603 in process_event ()
>> >> > #30144 0x000774df in gdb_do_one_event ()
>> >> > #30145 0x00074457 in catch_errors ()
>> >> > #30146 0x00076661 in start_event_loop ()
>> >> > #30147 0x00075189 in captured_command_loop ()
>> >> > #30148 0x00074457 in catch_errors ()
>> >> > #30149 0x000764d1 in captured_main ()
>> >> > #30150 0x00074457 in catch_errors ()
>> >> > #30151 0x00076511 in gdb_main ()
>> >> > #30152 0x00002639 in main ()
>> >> >
>> >> > I'm out of any ideas how to help apple to fix this, as I can not
>> >> break
>> >> > this bug down to a reproducible sample and I can't give them the
>> >> code.
>> >> >
>> >> > thanks
>> >> > arne
>> >> > _______________________________________________
>> >> > Do not post admin requests to the list. They will be ignored.
>> >> > Xcode-users mailing list      (email@hidden)
>> >> > Help/Unsubscribe/Update your Subscription:
>> >> 40apple.com
>> >> >
>> >> > This email sent to email@hidden
>> >>
>> >>
>>
>>


_______________________________________________
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


References: 
 >Debugging with Xcode 2.3 crashes gdb. (From: "Arne Scheffler" <email@hidden>)
 >Re: Debugging with Xcode 2.3 crashes gdb. (From: Jim Ingham <email@hidden>)
 >Re: Debugging with Xcode 2.3 crashes gdb. (From: "Arne Scheffler" <email@hidden>)
 >Re: Debugging with Xcode 2.3 crashes gdb. (From: Jim Ingham <email@hidden>)
 >Re: Debugging with Xcode 2.3 crashes gdb. (From: "Arne Scheffler" <email@hidden>)
 >Re: Debugging with Xcode 2.3 crashes gdb. (From: Jim Ingham <email@hidden>)

  • Prev by Date: Re: Sample Code Help: ImageClient - how is it supposed to work ?
  • Next by Date: Re: How to load my framework programatically ?
  • Previous by thread: Re: Debugging with Xcode 2.3 crashes gdb.
  • Next by thread: Fix & Continue still broken?
  • Index(es):
    • Date
    • Thread