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.


Reply via email to