This is now resolved. There were no significant differences in our config logs. I renamed / usr/local (containing my advisor's 64 bit OpenMP distributions of everything) and built libprotobuf as well as other stuff (rprotobuf and RHIPE) and it works fine.
I wish I knew what the problem was, but I am glad this finally works. Thanks, Ryan On Dec 18, 9:33 pm, Kenton Varda <ken...@google.com> wrote: > Attached. > > > > On Fri, Dec 18, 2009 at 7:39 PM, Ryan Rosario <uclamath...@gmail.com> wrote: > > 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 <ken...@google.com> 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 <ken...@google.com> 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 <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 > > ... > > read more » > > config.log > 52KViewDownload -- You received this message because you are subscribed to the Google Groups "Protocol Buffers" group. To post to this group, send email to proto...@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.
