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<http://www.google.com/search?hl=en&q="snow+leopard"+(D_GLIBCXX_FULLY_DYNAMIC_STRING+OR+_GLIBCXX_FULLY_DYNAMIC_STRING)>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.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: 0x0000000000000000, 0x0000000000000000
> > 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                   0x00007fff836bdff6 __kill + 10
> > 1   libSystem.B.dylib                   0x00007fff8375f072 abort + 83
> > 2   libSystem.B.dylib                   0x00007fff83676095 free + 128
> > 3   libstdc++.6.dylib                   0x00007fff87aa71e8
> > std::string::reserve(unsigned long) + 90
> > 4   libstdc++.6.dylib                   0x00007fff87aa742b
> > std::string::append(char const*, unsigned long) + 127
> > 5   libprotobuf.4.dylib                 0x0000000116a0989c
> > google::protobuf::io::CodedInputStream::ReadString(std::string*, int)
> > + 236 (coded_stream.h:761)
> > 6   Rhipe.so                            0x000000011430909c
> > STRING
> > ::MergePartialFromCodedStream(google::protobuf::io::CodedInputStream*)
> > + 396
> > 7   Rhipe.so                            0x00000001143099d8
> > REXP
> > ::MergePartialFromCodedStream(google::protobuf::io::CodedInputStream*)
> > + 2104
> > 8   Rhipe.so                            0x0000000114309de8
> > REXP
> > ::MergePartialFromCodedStream(google::protobuf::io::CodedInputStream*)
> > + 3144
> > 9   libprotobuf.4.dylib                 0x00000001169f893e
> > google::protobuf::MessageLite::ParseFromArray(void const*, int) + 62
> > (message_lite.cc:104)
> > 10  Rhipe.so                            0x000000011430d5d3
> > 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
-~----------~----~----~----~------~----~------~--~---

Reply via email to