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 <uclamath...@gmail.com> 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 <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 -~----------~----~----~----~------~----~------~--~---
