[protobuf] Re: On SnowLeopard, EXC_CRASH (SIGABRT)

[Ryan Rosario]

This is now resolved.

There were no significant differences in our config logs. I renamed /
usr/local (containing my advisor's 64 bit OpenMP distributions of
everything) and built libprotobuf as well as other stuff (rprotobuf
and RHIPE) and it works fine.

I wish I knew what the problem was, but I am glad this finally works.

Thanks,
Ryan

On Dec 18, 9:33 pm, Kenton Varda  wrote:
> Attached.
>
>
>
> On Fri, Dec 18, 2009 at 7:39 PM, Ryan Rosario  wrote:
> > Ugh.
> > I am using XCode 3.2.1's gcc and g++. I am really tempted to wipe this
> > system clean, as I think my advisor's distribution messed up a lot of
> > stuff.
>
> > Would you mind posting or sending your config.log? I'd like to see if
> > there is something significantly different or strange about my
> > parameters etc.
>
> > - Ryan
>
> > On Dec 18, 12:25 am, Kenton Varda  wrote:
> > > FYI, I've verified that protobuf-2.2.0 works correctly on Snow Leopard
> > with
> > > the latest Xcode compiler.
>
> > > On Wed, Nov 11, 2009 at 2:10 PM, Kenton Varda  wrote:
> > > > I have no idea what the problem could be.  However, I have a fancy new
> > Mac
> > > > laptop arriving next week on which I will make sure to test protocol
> > > > buffers.
>
> > > > On Tue, Nov 10, 2009 at 9:13 PM, Ryan Rosario  > >wrote:
>
> > > >> Hi,
>
> > > >> I am the fellow that has been dealing with this problem on Snow
> > > >> Leopard.
> > > >> I am left scratching my head as to the cause.
>
> > > >> I installed VMware in Snow Leopard and loaded Snow Leopard Server onto
> > > >> VMware (not possible to install regular Snow Leopard on it).
> > > >> I wanted to experiment with a clean system that only has an OS and
> > > >> XCode on it.
>
> > > >> I built pkg-config as well as protobuf using the Apple g++. I am able
> > > >> to get a bit further with Saptarshi's example program given earlier,
> > > >> and then I get the same crash. It seems like it may be occurring in
> > > >> some type of destructor, when the program ends. I am not sure if this
> > > >> progress is due to the clean configuration, or if it is due to the
> > > >> fact that I am using 10.6 Server instead of regular 10.6.
>
> > > >> I also tried adding -D_GLIBCXX_FULLY_DYNAMIC_STRING to CPPFLAGS and
> > > >> even CXXFLAGS to the makefiles for both protobuf and the example and
> > > >> rebuilding protobuf and the examples to no avail.
>
> > > >> If more information is needed, let me know and I will post.
>
> > > >> -Ryan
>
> > > >> 10.6 Server, "clean" configuration with Apple compilers
>
> > > >> Program received signal SIGABRT, Aborted.
> > > >> 0x7fff869b8ff6 in __kill ()
> > > >> (gdb) backtrace
> > > >> #0  0x7fff869b8ff6 in __kill ()
> > > >> #1  0x7fff86a5a072 in abort ()
> > > >> #2  0x7fff86971095 in free ()
> > > >> #3  0x00018399 in __tcf_1 () at basic_string.h:238
> > > >> #4  0x7fff8697d274 in __cxa_finalize ()
> > > >> #5  0x7fff8697d18c in exit ()
> > > >> #6  0x0001187f in start () at atomicity.h:50
>
> > > >> 10.6, custom configuration, GCC 4.5
>
> > > >> #0  0x7fff836bdff6 in __kill ()
> > > >> #1  0x7fff8375f072 in abort ()
> > > >> #2  0x7fff83676095 in free ()
> > > >> #3  0x7fff87aa71e8 in std::string::reserve ()
> > > >> #4  0x7fff87aa742b in std::string::append ()
> > > >> #5  0x00010002fd3c in
> > > >> google::protobuf::io::CodedInputStream::ReadString ()
> > > >> #6  0x0001346c in
> > > >> google::protobuf::internal::WireFormatLite::ReadString () at /usr/
> > > >> local/include/google/protobuf/wire_format_lite_inl.h:142
> > > >> #7  0x0001346c in STRING::MergePartialFromCodedStream
> > > >> (this=0x1004014b0, input=0x7fff5fbfeed0) at wire_format_lite_inl.h:939
> > > >> #8  0x00014e58 in ReadMessageNoVirtual [inlined] ()
> > > >> at /usr/local/include/google/protobuf/wire_format_lite_inl.h:200
> > > >> #9  0x00014e58 in REXP::MergePartialFromCodedStream
> > > >> (this=0x1004012c0, input=0x7fff5fbfeed0) at wire_format_lite_inl.h:397
> > > >> #10 0x000152b8 in ReadMessageNoVirtual [inlined] () at /
> > > >> usr/local/include/google/protobuf/wire_format_lite_inl.h:200
> > > >> #11 0x000152b8 in REXP::MergePartialFromCodedStream
> > > >> (this=0x7fff5fbfef70, input=0x7fff5fbfeed0) at wire_format_lite_inl.h:
> > > >> 438
> > > >> #12 0x00010001736e in
> > > >> google::protobuf::MessageLite::ParseFromArray ()
> > > >> #13 0x000181ca in main (argc= > > >> due to optimizations>, argv= > > >> optimizations>) at testparse.cc:25
>
> > > >> On Nov 1, 6:35 am, Saptarshi Guha  wrote:
> > > >> > Hello,
> > > >> > Your explanation sounds right. Neither do I have Snow Leopard, so
> > will
> > > >> > have to ask the user.
> > > >> > Personally, I would never (unless absolutely  forced to) install
> > > >> > another GCC.  Tried it once, and so many things started failing it
> > was
> > > >> > miserable.
>
> > > >> > I'll get back to this thread.
>
> > > >> > Regards
> > > >> > Saptarshi
>

[protobuf] Re: On SnowLeopard, EXC_CRASH (SIGABRT)

[Ryan Rosario]

Ugh.
I am using XCode 3.2.1's gcc and g++. I am really tempted to wipe this
system clean, as I think my advisor's distribution messed up a lot of
stuff.

Would you mind posting or sending your config.log? I'd like to see if
there is something significantly different or strange about my
parameters etc.

- Ryan

On Dec 18, 12:25 am, Kenton Varda  wrote:
> FYI, I've verified that protobuf-2.2.0 works correctly on Snow Leopard with
> the latest Xcode compiler.
>
>
>
> On Wed, Nov 11, 2009 at 2:10 PM, Kenton Varda  wrote:
> > I have no idea what the problem could be.  However, I have a fancy new Mac
> > laptop arriving next week on which I will make sure to test protocol
> > buffers.
>
> > On Tue, Nov 10, 2009 at 9:13 PM, Ryan Rosario wrote:
>
> >> Hi,
>
> >> I am the fellow that has been dealing with this problem on Snow
> >> Leopard.
> >> I am left scratching my head as to the cause.
>
> >> I installed VMware in Snow Leopard and loaded Snow Leopard Server onto
> >> VMware (not possible to install regular Snow Leopard on it).
> >> I wanted to experiment with a clean system that only has an OS and
> >> XCode on it.
>
> >> I built pkg-config as well as protobuf using the Apple g++. I am able
> >> to get a bit further with Saptarshi's example program given earlier,
> >> and then I get the same crash. It seems like it may be occurring in
> >> some type of destructor, when the program ends. I am not sure if this
> >> progress is due to the clean configuration, or if it is due to the
> >> fact that I am using 10.6 Server instead of regular 10.6.
>
> >> I also tried adding -D_GLIBCXX_FULLY_DYNAMIC_STRING to CPPFLAGS and
> >> even CXXFLAGS to the makefiles for both protobuf and the example and
> >> rebuilding protobuf and the examples to no avail.
>
> >> If more information is needed, let me know and I will post.
>
> >> -Ryan
>
> >> 10.6 Server, "clean" configuration with Apple compilers
>
> >> Program received signal SIGABRT, Aborted.
> >> 0x7fff869b8ff6 in __kill ()
> >> (gdb) backtrace
> >> #0  0x7fff869b8ff6 in __kill ()
> >> #1  0x7fff86a5a072 in abort ()
> >> #2  0x7fff86971095 in free ()
> >> #3  0x00018399 in __tcf_1 () at basic_string.h:238
> >> #4  0x7fff8697d274 in __cxa_finalize ()
> >> #5  0x7fff8697d18c in exit ()
> >> #6  0x0001187f in start () at atomicity.h:50
>
> >> 10.6, custom configuration, GCC 4.5
>
> >> #0  0x7fff836bdff6 in __kill ()
> >> #1  0x7fff8375f072 in abort ()
> >> #2  0x7fff83676095 in free ()
> >> #3  0x7fff87aa71e8 in std::string::reserve ()
> >> #4  0x7fff87aa742b in std::string::append ()
> >> #5  0x00010002fd3c in
> >> google::protobuf::io::CodedInputStream::ReadString ()
> >> #6  0x0001346c in
> >> google::protobuf::internal::WireFormatLite::ReadString () at /usr/
> >> local/include/google/protobuf/wire_format_lite_inl.h:142
> >> #7  0x0001346c in STRING::MergePartialFromCodedStream
> >> (this=0x1004014b0, input=0x7fff5fbfeed0) at wire_format_lite_inl.h:939
> >> #8  0x00014e58 in ReadMessageNoVirtual [inlined] ()
> >> at /usr/local/include/google/protobuf/wire_format_lite_inl.h:200
> >> #9  0x00014e58 in REXP::MergePartialFromCodedStream
> >> (this=0x1004012c0, input=0x7fff5fbfeed0) at wire_format_lite_inl.h:397
> >> #10 0x000152b8 in ReadMessageNoVirtual [inlined] () at /
> >> usr/local/include/google/protobuf/wire_format_lite_inl.h:200
> >> #11 0x000152b8 in REXP::MergePartialFromCodedStream
> >> (this=0x7fff5fbfef70, input=0x7fff5fbfeed0) at wire_format_lite_inl.h:
> >> 438
> >> #12 0x00010001736e in
> >> google::protobuf::MessageLite::ParseFromArray ()
> >> #13 0x000181ca in main (argc= >> due to optimizations>, argv= >> optimizations>) at testparse.cc:25
>
> >> On Nov 1, 6:35 am, Saptarshi Guha  wrote:
> >> > Hello,
> >> > Your explanation sounds right. Neither do I have Snow Leopard, so will
> >> > have to ask the user.
> >> > Personally, I would never (unless absolutely  forced to) install
> >> > another GCC.  Tried it once, and so many things started failing it was
> >> > miserable.
>
> >> > I'll get back to this thread.
>
> >> > Regards
> >> > Saptarshi
>
> >> > On Nov 1, 2009, at 3:15 AM, Kenton Varda wrote:
>
> >> > > Sorry, I don't have access to a Snow Leopard machine to test this on.
>
> >> > > However, your second link looks like a very likely culprit.  They
> >> > > seem to be saying that all C++ code on Snow Leopard needs to be
> >> > > compiled with -D_GLIBCXX_FULLY_DYNAMIC_STRING, otherwise it will
> >> > > likely crash.  So, I'd recommend re-compiling libprotobuf and your
> >> > > app with this flag.
>
> >> > > But I'm confused.  This seems like a truly massive bug --
> >> > > essentially, it sounds like Apple has released a C++ compiler that,
> >> > > by default, is not compatible with their C++ standard library.  Is
> >> > > it really possible that such a huge problem would make it through
> >> > > basic testing, let alone be shipped a

Re: [protobuf] Re: On SnowLeopard, EXC_CRASH (SIGABRT)

[Kenton Varda]

FYI, I've verified that protobuf-2.2.0 works correctly on Snow Leopard with
the latest Xcode compiler.

On Wed, Nov 11, 2009 at 2:10 PM, Kenton Varda  wrote:

> I have no idea what the problem could be.  However, I have a fancy new Mac
> laptop arriving next week on which I will make sure to test protocol
> buffers.
>
>
> On Tue, Nov 10, 2009 at 9:13 PM, Ryan Rosario wrote:
>
>>
>> Hi,
>>
>> I am the fellow that has been dealing with this problem on Snow
>> Leopard.
>> I am left scratching my head as to the cause.
>>
>> I installed VMware in Snow Leopard and loaded Snow Leopard Server onto
>> VMware (not possible to install regular Snow Leopard on it).
>> I wanted to experiment with a clean system that only has an OS and
>> XCode on it.
>>
>> I built pkg-config as well as protobuf using the Apple g++. I am able
>> to get a bit further with Saptarshi's example program given earlier,
>> and then I get the same crash. It seems like it may be occurring in
>> some type of destructor, when the program ends. I am not sure if this
>> progress is due to the clean configuration, or if it is due to the
>> fact that I am using 10.6 Server instead of regular 10.6.
>>
>> I also tried adding -D_GLIBCXX_FULLY_DYNAMIC_STRING to CPPFLAGS and
>> even CXXFLAGS to the makefiles for both protobuf and the example and
>> rebuilding protobuf and the examples to no avail.
>>
>> If more information is needed, let me know and I will post.
>>
>> -Ryan
>>
>> 10.6 Server, "clean" configuration with Apple compilers
>>
>> Program received signal SIGABRT, Aborted.
>> 0x7fff869b8ff6 in __kill ()
>> (gdb) backtrace
>> #0  0x7fff869b8ff6 in __kill ()
>> #1  0x7fff86a5a072 in abort ()
>> #2  0x7fff86971095 in free ()
>> #3  0x00018399 in __tcf_1 () at basic_string.h:238
>> #4  0x7fff8697d274 in __cxa_finalize ()
>> #5  0x7fff8697d18c in exit ()
>> #6  0x0001187f in start () at atomicity.h:50
>>
>> 10.6, custom configuration, GCC 4.5
>>
>> #0  0x7fff836bdff6 in __kill ()
>> #1  0x7fff8375f072 in abort ()
>> #2  0x7fff83676095 in free ()
>> #3  0x7fff87aa71e8 in std::string::reserve ()
>> #4  0x7fff87aa742b in std::string::append ()
>> #5  0x00010002fd3c in
>> google::protobuf::io::CodedInputStream::ReadString ()
>> #6  0x0001346c in
>> google::protobuf::internal::WireFormatLite::ReadString () at /usr/
>> local/include/google/protobuf/wire_format_lite_inl.h:142
>> #7  0x0001346c in STRING::MergePartialFromCodedStream
>> (this=0x1004014b0, input=0x7fff5fbfeed0) at wire_format_lite_inl.h:939
>> #8  0x00014e58 in ReadMessageNoVirtual [inlined] ()
>> at /usr/local/include/google/protobuf/wire_format_lite_inl.h:200
>> #9  0x00014e58 in REXP::MergePartialFromCodedStream
>> (this=0x1004012c0, input=0x7fff5fbfeed0) at wire_format_lite_inl.h:397
>> #10 0x000152b8 in ReadMessageNoVirtual [inlined] () at /
>> usr/local/include/google/protobuf/wire_format_lite_inl.h:200
>> #11 0x000152b8 in REXP::MergePartialFromCodedStream
>> (this=0x7fff5fbfef70, input=0x7fff5fbfeed0) at wire_format_lite_inl.h:
>> 438
>> #12 0x00010001736e in
>> google::protobuf::MessageLite::ParseFromArray ()
>> #13 0x000181ca in main (argc=> due to optimizations>, argv=> optimizations>) at testparse.cc:25
>>
>>
>> On Nov 1, 6:35 am, Saptarshi Guha  wrote:
>> > Hello,
>> > Your explanation sounds right. Neither do I have Snow Leopard, so will
>> > have to ask the user.
>> > Personally, I would never (unless absolutely  forced to) install
>> > another GCC.  Tried it once, and so many things started failing it was
>> > miserable.
>> >
>> > I'll get back to this thread.
>> >
>> > Regards
>> > Saptarshi
>> >
>> > On Nov 1, 2009, at 3:15 AM, Kenton Varda wrote:
>> >
>> >
>> >
>> > > Sorry, I don't have access to a Snow Leopard machine to test this on.
>> >
>> > > However, your second link looks like a very likely culprit.  They
>> > > seem to be saying that all C++ code on Snow Leopard needs to be
>> > > compiled with -D_GLIBCXX_FULLY_DYNAMIC_STRING, otherwise it will
>> > > likely crash.  So, I'd recommend re-compiling libprotobuf and your
>> > > app with this flag.
>> >
>> > > But I'm confused.  This seems like a truly massive bug --
>> > > essentially, it sounds like Apple has released a C++ compiler that,
>> > > by default, is not compatible with their C++ standard library.  Is
>> > > it really possible that such a huge problem would make it through
>> > > basic testing, let alone be shipped and live several months with
>> > > fewer than 10 sites on the entire internet mentioning it?
>> >
>> > > No, that seems unlikely to me.  My guess is that the Apple release
>> > > of GCC actually sets this flag correctly by default, but you are
>> > > actually using some other GCC, perhaps from MacPorts or some such.
>> > > Could this be the case?
>> >
>> > > On Sat, Oct 31, 2009 at 5:58 PM, Saptarshi Guha <
>> saptarshi.g...@gmail.com
>> > > > wrote:
>> >
>> > > On Oct 30, 2009,

[protobuf] Re: On SnowLeopard, EXC_CRASH (SIGABRT)

[Kenton Varda]

I have no idea what the problem could be.  However, I have a fancy new Mac
laptop arriving next week on which I will make sure to test protocol
buffers.

On Tue, Nov 10, 2009 at 9:13 PM, Ryan Rosario  wrote:

>
> Hi,
>
> I am the fellow that has been dealing with this problem on Snow
> Leopard.
> I am left scratching my head as to the cause.
>
> I installed VMware in Snow Leopard and loaded Snow Leopard Server onto
> VMware (not possible to install regular Snow Leopard on it).
> I wanted to experiment with a clean system that only has an OS and
> XCode on it.
>
> I built pkg-config as well as protobuf using the Apple g++. I am able
> to get a bit further with Saptarshi's example program given earlier,
> and then I get the same crash. It seems like it may be occurring in
> some type of destructor, when the program ends. I am not sure if this
> progress is due to the clean configuration, or if it is due to the
> fact that I am using 10.6 Server instead of regular 10.6.
>
> I also tried adding -D_GLIBCXX_FULLY_DYNAMIC_STRING to CPPFLAGS and
> even CXXFLAGS to the makefiles for both protobuf and the example and
> rebuilding protobuf and the examples to no avail.
>
> If more information is needed, let me know and I will post.
>
> -Ryan
>
> 10.6 Server, "clean" configuration with Apple compilers
>
> Program received signal SIGABRT, Aborted.
> 0x7fff869b8ff6 in __kill ()
> (gdb) backtrace
> #0  0x7fff869b8ff6 in __kill ()
> #1  0x7fff86a5a072 in abort ()
> #2  0x7fff86971095 in free ()
> #3  0x00018399 in __tcf_1 () at basic_string.h:238
> #4  0x7fff8697d274 in __cxa_finalize ()
> #5  0x7fff8697d18c in exit ()
> #6  0x0001187f in start () at atomicity.h:50
>
> 10.6, custom configuration, GCC 4.5
>
> #0  0x7fff836bdff6 in __kill ()
> #1  0x7fff8375f072 in abort ()
> #2  0x7fff83676095 in free ()
> #3  0x7fff87aa71e8 in std::string::reserve ()
> #4  0x7fff87aa742b in std::string::append ()
> #5  0x00010002fd3c in
> google::protobuf::io::CodedInputStream::ReadString ()
> #6  0x0001346c in
> google::protobuf::internal::WireFormatLite::ReadString () at /usr/
> local/include/google/protobuf/wire_format_lite_inl.h:142
> #7  0x0001346c in STRING::MergePartialFromCodedStream
> (this=0x1004014b0, input=0x7fff5fbfeed0) at wire_format_lite_inl.h:939
> #8  0x00014e58 in ReadMessageNoVirtual [inlined] ()
> at /usr/local/include/google/protobuf/wire_format_lite_inl.h:200
> #9  0x00014e58 in REXP::MergePartialFromCodedStream
> (this=0x1004012c0, input=0x7fff5fbfeed0) at wire_format_lite_inl.h:397
> #10 0x000152b8 in ReadMessageNoVirtual [inlined] () at /
> usr/local/include/google/protobuf/wire_format_lite_inl.h:200
> #11 0x000152b8 in REXP::MergePartialFromCodedStream
> (this=0x7fff5fbfef70, input=0x7fff5fbfeed0) at wire_format_lite_inl.h:
> 438
> #12 0x00010001736e in
> google::protobuf::MessageLite::ParseFromArray ()
> #13 0x000181ca in main (argc= due to optimizations>, argv= optimizations>) at testparse.cc:25
>
>
> On Nov 1, 6:35 am, Saptarshi Guha  wrote:
> > Hello,
> > Your explanation sounds right. Neither do I have Snow Leopard, so will
> > have to ask the user.
> > Personally, I would never (unless absolutely  forced to) install
> > another GCC.  Tried it once, and so many things started failing it was
> > miserable.
> >
> > I'll get back to this thread.
> >
> > Regards
> > Saptarshi
> >
> > On Nov 1, 2009, at 3:15 AM, Kenton Varda wrote:
> >
> >
> >
> > > Sorry, I don't have access to a Snow Leopard machine to test this on.
> >
> > > However, your second link looks like a very likely culprit.  They
> > > seem to be saying that all C++ code on Snow Leopard needs to be
> > > compiled with -D_GLIBCXX_FULLY_DYNAMIC_STRING, otherwise it will
> > > likely crash.  So, I'd recommend re-compiling libprotobuf and your
> > > app with this flag.
> >
> > > But I'm confused.  This seems like a truly massive bug --
> > > essentially, it sounds like Apple has released a C++ compiler that,
> > > by default, is not compatible with their C++ standard library.  Is
> > > it really possible that such a huge problem would make it through
> > > basic testing, let alone be shipped and live several months with
> > > fewer than 10 sites on the entire internet mentioning it?
> >
> > > No, that seems unlikely to me.  My guess is that the Apple release
> > > of GCC actually sets this flag correctly by default, but you are
> > > actually using some other GCC, perhaps from MacPorts or some such.
> > > Could this be the case?
> >
> > > On Sat, Oct 31, 2009 at 5:58 PM, Saptarshi Guha <
> saptarshi.g...@gmail.com
> > > > wrote:
> >
> > > On Oct 30, 2009, at 7:14 PM, Kenton Varda wrote:
> >
> > > > There's not much we can do with this without a reproducible demo.
> >
> > > Hello,
> > > I have placed a link[1] to tgz file, which can be run like
> >
> > > tar zxvf test.parse.tgz
> > > cd testdata
> > > make
> > > ./testme testdata.bi

[protobuf] Re: On SnowLeopard, EXC_CRASH (SIGABRT)

[Ryan Rosario]

Hi,

I am the fellow that has been dealing with this problem on Snow
Leopard.
I am left scratching my head as to the cause.

I installed VMware in Snow Leopard and loaded Snow Leopard Server onto
VMware (not possible to install regular Snow Leopard on it).
I wanted to experiment with a clean system that only has an OS and
XCode on it.

I built pkg-config as well as protobuf using the Apple g++. I am able
to get a bit further with Saptarshi's example program given earlier,
and then I get the same crash. It seems like it may be occurring in
some type of destructor, when the program ends. I am not sure if this
progress is due to the clean configuration, or if it is due to the
fact that I am using 10.6 Server instead of regular 10.6.

I also tried adding -D_GLIBCXX_FULLY_DYNAMIC_STRING to CPPFLAGS and
even CXXFLAGS to the makefiles for both protobuf and the example and
rebuilding protobuf and the examples to no avail.

If more information is needed, let me know and I will post.

-Ryan

10.6 Server, "clean" configuration with Apple compilers

Program received signal SIGABRT, Aborted.
0x7fff869b8ff6 in __kill ()
(gdb) backtrace
#0  0x7fff869b8ff6 in __kill ()
#1  0x7fff86a5a072 in abort ()
#2  0x7fff86971095 in free ()
#3  0x00018399 in __tcf_1 () at basic_string.h:238
#4  0x7fff8697d274 in __cxa_finalize ()
#5  0x7fff8697d18c in exit ()
#6  0x0001187f in start () at atomicity.h:50

10.6, custom configuration, GCC 4.5

#0  0x7fff836bdff6 in __kill ()
#1  0x7fff8375f072 in abort ()
#2  0x7fff83676095 in free ()
#3  0x7fff87aa71e8 in std::string::reserve ()
#4  0x7fff87aa742b in std::string::append ()
#5  0x00010002fd3c in
google::protobuf::io::CodedInputStream::ReadString ()
#6  0x0001346c in
google::protobuf::internal::WireFormatLite::ReadString () at /usr/
local/include/google/protobuf/wire_format_lite_inl.h:142
#7  0x0001346c in STRING::MergePartialFromCodedStream
(this=0x1004014b0, input=0x7fff5fbfeed0) at wire_format_lite_inl.h:939
#8  0x00014e58 in ReadMessageNoVirtual [inlined] ()
at /usr/local/include/google/protobuf/wire_format_lite_inl.h:200
#9  0x00014e58 in REXP::MergePartialFromCodedStream
(this=0x1004012c0, input=0x7fff5fbfeed0) at wire_format_lite_inl.h:397
#10 0x000152b8 in ReadMessageNoVirtual [inlined] () at /
usr/local/include/google/protobuf/wire_format_lite_inl.h:200
#11 0x000152b8 in REXP::MergePartialFromCodedStream
(this=0x7fff5fbfef70, input=0x7fff5fbfeed0) at wire_format_lite_inl.h:
438
#12 0x00010001736e in
google::protobuf::MessageLite::ParseFromArray ()
#13 0x000181ca in main (argc=, argv=) at testparse.cc:25


On Nov 1, 6:35 am, Saptarshi Guha  wrote:
> Hello,
> Your explanation sounds right. Neither do I have Snow Leopard, so will  
> have to ask the user.
> Personally, I would never (unless absolutely  forced to) install  
> another GCC.  Tried it once, and so many things started failing it was  
> miserable.
>
> I'll get back to this thread.
>
> Regards
> Saptarshi
>
> On Nov 1, 2009, at 3:15 AM, Kenton Varda wrote:
>
>
>
> > Sorry, I don't have access to a Snow Leopard machine to test this on.
>
> > However, your second link looks like a very likely culprit.  They  
> > seem to be saying that all C++ code on Snow Leopard needs to be  
> > compiled with -D_GLIBCXX_FULLY_DYNAMIC_STRING, otherwise it will  
> > likely crash.  So, I'd recommend re-compiling libprotobuf and your  
> > app with this flag.
>
> > But I'm confused.  This seems like a truly massive bug --  
> > essentially, it sounds like Apple has released a C++ compiler that,  
> > by default, is not compatible with their C++ standard library.  Is  
> > it really possible that such a huge problem would make it through  
> > basic testing, let alone be shipped and live several months with  
> > fewer than 10 sites on the entire internet mentioning it?
>
> > No, that seems unlikely to me.  My guess is that the Apple release  
> > of GCC actually sets this flag correctly by default, but you are  
> > actually using some other GCC, perhaps from MacPorts or some such.  
> > Could this be the case?
>
> > On Sat, Oct 31, 2009 at 5:58 PM, Saptarshi Guha  > > wrote:
>
> > On Oct 30, 2009, at 7:14 PM, Kenton Varda wrote:
>
> > > There's not much we can do with this without a reproducible demo.
>
> > Hello,
> > I have placed a link[1] to tgz file, which can be run like
>
> > tar zxvf test.parse.tgz
> > cd testdata
> > make
> > ./testme testdata.bin
>
> > If all works well, it should display an  entry of string keys and
> > string values.
> > It compiles and runs on Leopard 10.5.7 (Macbook), but fails with
>
> > "
> > ./testme testdata.bin
> > Reading in 3239 bytes
> > testme(41471) malloc: *** error for object 0x100222520: pointer being
> > freed was not allocated
> > *** set a breakpoint in malloc_error_break to debug
> > "
> > on Snow Leopard (i can't recall the machine type)
>
> > On another note,  I read 

[protobuf] Re: On SnowLeopard, EXC_CRASH (SIGABRT)

[Saptarshi Guha]

Hello,
Your explanation sounds right. Neither do I have Snow Leopard, so will  
have to ask the user.
Personally, I would never (unless absolutely  forced to) install  
another GCC.  Tried it once, and so many things started failing it was  
miserable.

I'll get back to this thread.

Regards
Saptarshi

On Nov 1, 2009, at 3:15 AM, Kenton Varda wrote:

> Sorry, I don't have access to a Snow Leopard machine to test this on.
>
> However, your second link looks like a very likely culprit.  They  
> seem to be saying that all C++ code on Snow Leopard needs to be  
> compiled with -D_GLIBCXX_FULLY_DYNAMIC_STRING, otherwise it will  
> likely crash.  So, I'd recommend re-compiling libprotobuf and your  
> app with this flag.
>
> But I'm confused.  This seems like a truly massive bug --  
> essentially, it sounds like Apple has released a C++ compiler that,  
> by default, is not compatible with their C++ standard library.  Is  
> it really possible that such a huge problem would make it through  
> basic testing, let alone be shipped and live several months with  
> fewer than 10 sites on the entire internet mentioning it?
>
> No, that seems unlikely to me.  My guess is that the Apple release  
> of GCC actually sets this flag correctly by default, but you are  
> actually using some other GCC, perhaps from MacPorts or some such.   
> Could this be the case?
>
> On Sat, Oct 31, 2009 at 5:58 PM, Saptarshi Guha  > wrote:
>
>
> On Oct 30, 2009, at 7:14 PM, Kenton Varda wrote:
>
> > There's not much we can do with this without a reproducible demo.
> >
>
>
> Hello,
> I have placed a link[1] to tgz file, which can be run like
>
> tar zxvf test.parse.tgz
> cd testdata
> make
> ./testme testdata.bin
>
> If all works well, it should display an  entry of string keys and
> string values.
> It compiles and runs on Leopard 10.5.7 (Macbook), but fails with
>
> "
> ./testme testdata.bin
> Reading in 3239 bytes
> testme(41471) malloc: *** error for object 0x100222520: pointer being
> freed was not allocated
> *** set a breakpoint in malloc_error_break to debug
> "
> on Snow Leopard (i can't recall the machine type)
>
> On another note,  I read that( from an emacs blog) that Snow Leopard
> has "fully dynamic strings" enabled by default
> and there is an issue regarding freeing such strings[2] . I'm not sure
> if this even related.
>
> Thanks
> Saptarshi
>
>
> [1] http://ml.stat.purdue.edu/rpackages/test.parse.tgz
> [2] http://www.newartisans.com/2009/10/a-c-gotcha-on-snow-leopard.html
>
>
>
>
>
>
> > On Fri, Oct 30, 2009 at 4:04 PM, Saptarshi Guha  > > wrote:
> >
> > Hello,
> > I have  a byte array which I'd like to deserialize, it is about 3K
> > bytes.
> > On RHEL 5, 64 bit machine, protobuf 2.2 my deserialization works.
> > On Leopard 10.5.7 on a macbook it also works. (for both 32 bit and  
> 64
> > bit versions)
> >
> >
> > Above gcc: 4.0.1
> >
> > However, someone reported this crash on SnowLeopard (gcc4.2)
> >
> > I'm not sure why this happens. The crash appears to arise within the
> > protobuf calls.
> > Regards
> > Saptarshi
> >
> >
> > Process: R [34034]
> > Path:/Applications/R64.app/Contents/MacOS/R
> > Identifier:  org.R-project.R
> > Version: R 2.10.0 GUI 1.30 Leopard build 64-bit (5511)
> > Code Type:   X86-64 (Native)
> > Parent Process:  launchd [182]
> >
> > Date/Time:   2009-10-28 20:11:54.353 -0700
> > OS Version:  Mac OS X 10.6.1 (10B504)
> > Report Version:  6
> >
> > Interval Since Last Report:  195786 sec
> > Crashes Since Last Report:   2
> > Per-App Interval Since Last Report:  1676 sec
> > Per-App Crashes Since Last Report:   1
> > Anonymous UUID:  0A96FBCF-6045-4A38-
> > A8E5-619A52D23CE5
> >
> > Exception Type:  EXC_CRASH (SIGABRT)
> > Exception Codes: 0x, 0x
> > Crashed Thread:  0  Dispatch queue: com.apple.main-thread
> >
> > Application Specific Information:
> > abort() called
> >
> > Thread 0 Crashed:  Dispatch queue: com.apple.main-thread
> > 0   libSystem.B.dylib   0x7fff836bdff6 __kill  
> + 10
> > 1   libSystem.B.dylib   0x7fff8375f072 abort +  
> 83
> > 2   libSystem.B.dylib   0x7fff83676095 free +  
> 128
> > 3   libstdc++.6.dylib   0x7fff87aa71e8
> > std::string::reserve(unsigned long) + 90
> > 4   libstdc++.6.dylib   0x7fff87aa742b
> > std::string::append(char const*, unsigned long) + 127
> > 5   libprotobuf.4.dylib 0x000116a0989c
> > google::protobuf::io::CodedInputStream::ReadString(std::string*,  
> int)
> > + 236 (coded_stream.h:761)
> > 6   Rhipe.so0x00011430909c
> > STRING
> > 
>  ::MergePartialFromCodedStream 
> (google::protobuf::io::CodedInputStream*)
> > + 396
> > 7   Rhipe.so0x0001143099d8
> > REXP
> > 
>  ::MergePartialFromCodedStream 
> (google::protobuf::io::CodedInputStream*)
> > + 21

[protobuf] Re: On SnowLeopard, EXC_CRASH (SIGABRT)

[Kenton Varda]

Sorry, I don't have access to a Snow Leopard machine to test this on.

However, your second link looks like a very likely culprit.  They seem to be
saying that all C++ code on Snow Leopard needs to be compiled
with -D_GLIBCXX_FULLY_DYNAMIC_STRING, otherwise it will likely crash.  So,
I'd recommend re-compiling libprotobuf and your app with this flag.

But I'm confused.  This seems like a truly massive bug -- essentially, it
sounds like Apple has released a C++ compiler that, by default, is not
compatible with their C++ standard library.  Is it really possible that such
a huge problem would make it through basic testing, let alone be shipped and
live several months with fewer than 10
siteson
the entire internet mentioning it?

No, that seems unlikely to me.  My guess is that the Apple release of GCC
actually sets this flag correctly by default, but you are actually using
some other GCC, perhaps from MacPorts or some such.  Could this be the case?

On Sat, Oct 31, 2009 at 5:58 PM, Saptarshi Guha wrote:

>
>
> On Oct 30, 2009, at 7:14 PM, Kenton Varda wrote:
>
> > There's not much we can do with this without a reproducible demo.
> >
>
>
> Hello,
> I have placed a link[1] to tgz file, which can be run like
>
> tar zxvf test.parse.tgz
> cd testdata
> make
> ./testme testdata.bin
>
> If all works well, it should display an  entry of string keys and
> string values.
> It compiles and runs on Leopard 10.5.7 (Macbook), but fails with
>
> "
> ./testme testdata.bin
> Reading in 3239 bytes
> testme(41471) malloc: *** error for object 0x100222520: pointer being
> freed was not allocated
> *** set a breakpoint in malloc_error_break to debug
> "
> on Snow Leopard (i can't recall the machine type)
>
> On another note,  I read that( from an emacs blog) that Snow Leopard
> has "fully dynamic strings" enabled by default
> and there is an issue regarding freeing such strings[2] . I'm not sure
> if this even related.
>
> Thanks
> Saptarshi
>
>
> [1] http://ml.stat.purdue.edu/rpackages/test.parse.tgz
> [2] http://www.newartisans.com/2009/10/a-c-gotcha-on-snow-leopard.html
>
>
>
>
>
>
> > On Fri, Oct 30, 2009 at 4:04 PM, Saptarshi Guha <
> saptarshi.g...@gmail.com
> > > wrote:
> >
> > Hello,
> > I have  a byte array which I'd like to deserialize, it is about 3K
> > bytes.
> > On RHEL 5, 64 bit machine, protobuf 2.2 my deserialization works.
> > On Leopard 10.5.7 on a macbook it also works. (for both 32 bit and 64
> > bit versions)
> >
> >
> > Above gcc: 4.0.1
> >
> > However, someone reported this crash on SnowLeopard (gcc4.2)
> >
> > I'm not sure why this happens. The crash appears to arise within the
> > protobuf calls.
> > Regards
> > Saptarshi
> >
> >
> > Process: R [34034]
> > Path:/Applications/R64.app/Contents/MacOS/R
> > Identifier:  org.R-project.R
> > Version: R 2.10.0 GUI 1.30 Leopard build 64-bit (5511)
> > Code Type:   X86-64 (Native)
> > Parent Process:  launchd [182]
> >
> > Date/Time:   2009-10-28 20:11:54.353 -0700
> > OS Version:  Mac OS X 10.6.1 (10B504)
> > Report Version:  6
> >
> > Interval Since Last Report:  195786 sec
> > Crashes Since Last Report:   2
> > Per-App Interval Since Last Report:  1676 sec
> > Per-App Crashes Since Last Report:   1
> > Anonymous UUID:  0A96FBCF-6045-4A38-
> > A8E5-619A52D23CE5
> >
> > Exception Type:  EXC_CRASH (SIGABRT)
> > Exception Codes: 0x, 0x
> > Crashed Thread:  0  Dispatch queue: com.apple.main-thread
> >
> > Application Specific Information:
> > abort() called
> >
> > Thread 0 Crashed:  Dispatch queue: com.apple.main-thread
> > 0   libSystem.B.dylib   0x7fff836bdff6 __kill + 10
> > 1   libSystem.B.dylib   0x7fff8375f072 abort + 83
> > 2   libSystem.B.dylib   0x7fff83676095 free + 128
> > 3   libstdc++.6.dylib   0x7fff87aa71e8
> > std::string::reserve(unsigned long) + 90
> > 4   libstdc++.6.dylib   0x7fff87aa742b
> > std::string::append(char const*, unsigned long) + 127
> > 5   libprotobuf.4.dylib 0x000116a0989c
> > google::protobuf::io::CodedInputStream::ReadString(std::string*, int)
> > + 236 (coded_stream.h:761)
> > 6   Rhipe.so0x00011430909c
> > STRING
> > ::MergePartialFromCodedStream(google::protobuf::io::CodedInputStream*)
> > + 396
> > 7   Rhipe.so0x0001143099d8
> > REXP
> > ::MergePartialFromCodedStream(google::protobuf::io::CodedInputStream*)
> > + 2104
> > 8   Rhipe.so0x000114309de8
> > REXP
> > ::MergePartialFromCodedStream(google::protobuf::io::CodedInputStream*)
> > + 3144
> > 9   libprotobuf.4.dylib 0x0001169f893e
> > google::protobuf::MessageLite::ParseFromArray(void const*, int) + 62
> > (mess

[protobuf] Re: On SnowLeopard, EXC_CRASH (SIGABRT)

[Saptarshi Guha]

On Oct 30, 2009, at 7:14 PM, Kenton Varda wrote:

> There's not much we can do with this without a reproducible demo.
>


Hello,
I have placed a link[1] to tgz file, which can be run like

tar zxvf test.parse.tgz
cd testdata
make
./testme testdata.bin

If all works well, it should display an  entry of string keys and  
string values.
It compiles and runs on Leopard 10.5.7 (Macbook), but fails with

"
./testme testdata.bin
Reading in 3239 bytes
testme(41471) malloc: *** error for object 0x100222520: pointer being  
freed was not allocated
*** set a breakpoint in malloc_error_break to debug
"
on Snow Leopard (i can't recall the machine type)

On another note,  I read that( from an emacs blog) that Snow Leopard  
has "fully dynamic strings" enabled by default
and there is an issue regarding freeing such strings[2] . I'm not sure  
if this even related.

Thanks
Saptarshi


[1] http://ml.stat.purdue.edu/rpackages/test.parse.tgz
[2] http://www.newartisans.com/2009/10/a-c-gotcha-on-snow-leopard.html






> On Fri, Oct 30, 2009 at 4:04 PM, Saptarshi Guha  > wrote:
>
> Hello,
> I have  a byte array which I'd like to deserialize, it is about 3K
> bytes.
> On RHEL 5, 64 bit machine, protobuf 2.2 my deserialization works.
> On Leopard 10.5.7 on a macbook it also works. (for both 32 bit and 64
> bit versions)
>
>
> Above gcc: 4.0.1
>
> However, someone reported this crash on SnowLeopard (gcc4.2)
>
> I'm not sure why this happens. The crash appears to arise within the
> protobuf calls.
> Regards
> Saptarshi
>
>
> Process: R [34034]
> Path:/Applications/R64.app/Contents/MacOS/R
> Identifier:  org.R-project.R
> Version: R 2.10.0 GUI 1.30 Leopard build 64-bit (5511)
> Code Type:   X86-64 (Native)
> Parent Process:  launchd [182]
>
> Date/Time:   2009-10-28 20:11:54.353 -0700
> OS Version:  Mac OS X 10.6.1 (10B504)
> Report Version:  6
>
> Interval Since Last Report:  195786 sec
> Crashes Since Last Report:   2
> Per-App Interval Since Last Report:  1676 sec
> Per-App Crashes Since Last Report:   1
> Anonymous UUID:  0A96FBCF-6045-4A38-
> A8E5-619A52D23CE5
>
> Exception Type:  EXC_CRASH (SIGABRT)
> Exception Codes: 0x, 0x
> Crashed Thread:  0  Dispatch queue: com.apple.main-thread
>
> Application Specific Information:
> abort() called
>
> Thread 0 Crashed:  Dispatch queue: com.apple.main-thread
> 0   libSystem.B.dylib   0x7fff836bdff6 __kill + 10
> 1   libSystem.B.dylib   0x7fff8375f072 abort + 83
> 2   libSystem.B.dylib   0x7fff83676095 free + 128
> 3   libstdc++.6.dylib   0x7fff87aa71e8
> std::string::reserve(unsigned long) + 90
> 4   libstdc++.6.dylib   0x7fff87aa742b
> std::string::append(char const*, unsigned long) + 127
> 5   libprotobuf.4.dylib 0x000116a0989c
> google::protobuf::io::CodedInputStream::ReadString(std::string*, int)
> + 236 (coded_stream.h:761)
> 6   Rhipe.so0x00011430909c
> STRING
> ::MergePartialFromCodedStream(google::protobuf::io::CodedInputStream*)
> + 396
> 7   Rhipe.so0x0001143099d8
> REXP
> ::MergePartialFromCodedStream(google::protobuf::io::CodedInputStream*)
> + 2104
> 8   Rhipe.so0x000114309de8
> REXP
> ::MergePartialFromCodedStream(google::protobuf::io::CodedInputStream*)
> + 3144
> 9   libprotobuf.4.dylib 0x0001169f893e
> google::protobuf::MessageLite::ParseFromArray(void const*, int) + 62
> (message_lite.cc:104)
> 10  Rhipe.so0x00011430d5d3
> unserializeUsingPB + 99
>
>
>
>
>
>
>
> Saptarshi Guha | saptarshi.g...@gmail.com | http://www.stat.purdue.edu/~sguha
> The use of anthropomorphic terminology when dealing with computing
> systems
> is a symptom of professional immaturity.
>-- Edsger W. Dijkstra
>
>
> >
>


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To post to this group, send email to protobuf@googlegroups.com
To unsubscribe from this group, send email to 
protobuf+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/protobuf?hl=en
-~--~~~~--~~--~--~---

[protobuf] Re: On SnowLeopard, EXC_CRASH (SIGABRT)

[Kenton Varda]

There's not much we can do with this without a reproducible demo.

On Fri, Oct 30, 2009 at 4:04 PM, Saptarshi Guha wrote:

>
> Hello,
> I have  a byte array which I'd like to deserialize, it is about 3K
> bytes.
> On RHEL 5, 64 bit machine, protobuf 2.2 my deserialization works.
> On Leopard 10.5.7 on a macbook it also works. (for both 32 bit and 64
> bit versions)
>
>
> Above gcc: 4.0.1
>
> However, someone reported this crash on SnowLeopard (gcc4.2)
>
> I'm not sure why this happens. The crash appears to arise within the
> protobuf calls.
> Regards
> Saptarshi
>
>
> Process: R [34034]
> Path:/Applications/R64.app/Contents/MacOS/R
> Identifier:  org.R-project.R
> Version: R 2.10.0 GUI 1.30 Leopard build 64-bit (5511)
> Code Type:   X86-64 (Native)
> Parent Process:  launchd [182]
>
> Date/Time:   2009-10-28 20:11:54.353 -0700
> OS Version:  Mac OS X 10.6.1 (10B504)
> Report Version:  6
>
> Interval Since Last Report:  195786 sec
> Crashes Since Last Report:   2
> Per-App Interval Since Last Report:  1676 sec
> Per-App Crashes Since Last Report:   1
> Anonymous UUID:  0A96FBCF-6045-4A38-
> A8E5-619A52D23CE5
>
> Exception Type:  EXC_CRASH (SIGABRT)
> Exception Codes: 0x, 0x
> Crashed Thread:  0  Dispatch queue: com.apple.main-thread
>
> Application Specific Information:
> abort() called
>
> Thread 0 Crashed:  Dispatch queue: com.apple.main-thread
> 0   libSystem.B.dylib   0x7fff836bdff6 __kill + 10
> 1   libSystem.B.dylib   0x7fff8375f072 abort + 83
> 2   libSystem.B.dylib   0x7fff83676095 free + 128
> 3   libstdc++.6.dylib   0x7fff87aa71e8
> std::string::reserve(unsigned long) + 90
> 4   libstdc++.6.dylib   0x7fff87aa742b
> std::string::append(char const*, unsigned long) + 127
> 5   libprotobuf.4.dylib 0x000116a0989c
> google::protobuf::io::CodedInputStream::ReadString(std::string*, int)
> + 236 (coded_stream.h:761)
> 6   Rhipe.so0x00011430909c
> STRING
> ::MergePartialFromCodedStream(google::protobuf::io::CodedInputStream*)
> + 396
> 7   Rhipe.so0x0001143099d8
> REXP
> ::MergePartialFromCodedStream(google::protobuf::io::CodedInputStream*)
> + 2104
> 8   Rhipe.so0x000114309de8
> REXP
> ::MergePartialFromCodedStream(google::protobuf::io::CodedInputStream*)
> + 3144
> 9   libprotobuf.4.dylib 0x0001169f893e
> google::protobuf::MessageLite::ParseFromArray(void const*, int) + 62
> (message_lite.cc:104)
> 10  Rhipe.so0x00011430d5d3
> unserializeUsingPB + 99
>
>
>
>
>
>
>
> Saptarshi Guha | saptarshi.g...@gmail.com |
> http://www.stat.purdue.edu/~sguha
> The use of anthropomorphic terminology when dealing with computing
> systems
> is a symptom of professional immaturity.
>-- Edsger W. Dijkstra
>
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To post to this group, send email to protobuf@googlegroups.com
To unsubscribe from this group, send email to 
protobuf+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/protobuf?hl=en
-~--~~~~--~~--~--~---