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. 0x00007fff869b8ff6 in __kill () (gdb) backtrace #0 0x00007fff869b8ff6 in __kill () #1 0x00007fff86a5a072 in abort () #2 0x00007fff86971095 in free () #3 0x0000000100008399 in __tcf_1 () at basic_string.h:238 #4 0x00007fff8697d274 in __cxa_finalize () #5 0x00007fff8697d18c in exit () #6 0x000000010000187f in start () at atomicity.h:50 10.6, custom configuration, GCC 4.5 #0 0x00007fff836bdff6 in __kill () #1 0x00007fff8375f072 in abort () #2 0x00007fff83676095 in free () #3 0x00007fff87aa71e8 in std::string::reserve () #4 0x00007fff87aa742b in std::string::append () #5 0x000000010002fd3c in google::protobuf::io::CodedInputStream::ReadString () #6 0x000000010000346c in google::protobuf::internal::WireFormatLite::ReadString () at /usr/ local/include/google/protobuf/wire_format_lite_inl.h:142 #7 0x000000010000346c in STRING::MergePartialFromCodedStream (this=0x1004014b0, input=0x7fff5fbfeed0) at wire_format_lite_inl.h:939 #8 0x0000000100004e58 in ReadMessageNoVirtual<STRING> [inlined] () at /usr/local/include/google/protobuf/wire_format_lite_inl.h:200 #9 0x0000000100004e58 in REXP::MergePartialFromCodedStream (this=0x1004012c0, input=0x7fff5fbfeed0) at wire_format_lite_inl.h:397 #10 0x00000001000052b8 in ReadMessageNoVirtual<REXP> [inlined] () at / usr/local/include/google/protobuf/wire_format_lite_inl.h:200 #11 0x00000001000052b8 in REXP::MergePartialFromCodedStream (this=0x7fff5fbfef70, input=0x7fff5fbfeed0) at wire_format_lite_inl.h: 438 #12 0x000000010001736e in google::protobuf::MessageLite::ParseFromArray () #13 0x00000001000081ca in main (argc=<value temporarily unavailable, due to optimizations>, argv=<value temporarily unavailable, due to optimizations>) at testparse.cc:25 On Nov 1, 6:35 am, Saptarshi Guha <saptarshi.g...@gmail.com> 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.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 X10.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 -~----------~----~----~----~------~----~------~--~---
