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
I'll get back to this thread.
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.
> I have placed a link to tgz file, which can be run like
> tar zxvf test.parse.tgz
> cd testdata
> ./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 . I'm not sure
> if this even related.
>  http://ml.stat.purdue.edu/rpackages/test.parse.tgz
>  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
> > 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 
> > 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 
> > 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 +
> > 2 libSystem.B.dylib 0x00007fff83676095 free +
> > 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*,
> > + 236 (coded_stream.h:761)
> > 6 Rhipe.so 0x000000011430909c
> > STRING
> > + 396
> > 7 Rhipe.so 0x00000001143099d8
> > REXP
> > + 2104
> > 8 Rhipe.so 0x0000000114309de8
> > REXP
> > + 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 email@example.com
To unsubscribe from this group, send email to
For more options, visit this group at