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 <[email protected]> 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 <[email protected]> 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 <[email protected]>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. > >> 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 <[email protected]> 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 < > >> [email protected] > >> > > > 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 < > >> [email protected] > >> > > > > 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 | [email protected] | > >>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 > > ... > > read more » -- You received this message because you are subscribed to the Google Groups "Protocol Buffers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/protobuf?hl=en.
