> - Do you use the "hard-core" memory management methods of RepeatedPtrField,
> like AddAllocated()?  If so, investigate these calls to make sure that the
> pointers are valid and the ownership transfer is being respected.
No, we're not using those.

> In gdb you have to put single-quotes around scoped C++ names, e.g.:
>   p *('bd::Main' *)pb_pip_thread_data->bd_pb_data_msg.main_msg_hnd
> I don't know why gdb requires this.

I am still having trouble getting gdb to recognize my protobuf type
(bd::Main, as noted earlier) in a different core dump that I generated just
to try reproducing this gdb trouble:

(gdb) p main_msg
$1 = (struct bd::Main *) 0x953c290
(gdb) p *main_msg
$2 = <incomplete type>
(gdb) info symbol 0x953c290
No symbol matches 0x953c290.
(gdb) info address main_msg
Symbol "main_msg" is a variable with multiple locations.
(gdb) p *('bd::Main' *) main_msg
No symbol "bd::Main" in current context.
(gdb) p *(struct 'bd::Main' *) main_msg
No struct type named bd::Main.
(gdb) info types bd::Main
All types matching regular expression "bd::Main":

It seems like the protobuf classes are incomplete types or types that gdb
just don't recognize (see empty "info types" output)?  But what's weird is
that it does seem to "know" what a "struct bd::Main" is, given the output
when printing the pointer, but I can't then use that same name to
dereference it...

How do you query memory to "get at" the message when you run gdb on a core
dump?  Is this just something peculiar to the way we are compiling or
something general with the way protobuf generated code is compiled?

I really need help figuring out this core dump (and I'm sure others will
come) so any pointers on how to "get back" the protobuf message from a core
dump is really appreciated.

You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To post to this group, send email to proto...@googlegroups.com.
To unsubscribe from this group, send email to 
For more options, visit this group at 

Reply via email to