On SnowLeopard, EXC_CRASH (SIGABRT)

513 views
Skip to first unread message

Saptarshi Guha

unread,
Oct 30, 2009, 7:04:51 PM10/30/09
to Protocol Buffers
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 X 10.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 | saptars...@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

Kenton Varda

unread,
Oct 30, 2009, 7:14:29 PM10/30/09
to Saptarshi Guha, Protocol Buffers
There's not much we can do with this without a reproducible demo.

Saptarshi Guha

unread,
Oct 31, 2009, 8:58:06 PM10/31/09
to Protocol Buffers

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

Kenton Varda

unread,
Nov 1, 2009, 3:15:29 AM11/1/09
to Saptarshi Guha, Protocol Buffers
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?

Saptarshi Guha

unread,
Nov 1, 2009, 9:35:53 AM11/1/09
to Kenton Varda, Protocol Buffers
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

Ryan Rosario

unread,
Nov 11, 2009, 12:13:52 AM11/11/09
to Protocol Buffers
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 Sat, Oct 31, 2009 at 5:58 PM, Saptarshi Guha <saptarshi.g...@gmail.com
> > > 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)
> > > Saptarshi Guha | saptarshi.g...@gmail.com |http://www.stat.purdue.edu/~sguha

Kenton Varda

unread,
Nov 11, 2009, 5:10:15 PM11/11/09
to Ryan Rosario, Protocol Buffers
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.

Kenton Varda

unread,
Dec 18, 2009, 3:25:17 AM12/18/09
to Ryan Rosario, Protocol Buffers
FYI, I've verified that protobuf-2.2.0 works correctly on Snow Leopard with the latest Xcode compiler.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Protocol Buffers" group.
To post to this group, send email to prot...@googlegroups.com
To unsubscribe from this group, send email to protobuf+u...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/protobuf?hl=en
-~----------~----~----~----~------~----~------~--~---



Ryan Rosario

unread,
Dec 18, 2009, 10:39:04 PM12/18/09
to Protocol Buffers
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.
>

> ...
>
> read more »

Kenton Varda

unread,
Dec 19, 2009, 12:33:43 AM12/19/09
to Ryan Rosario, Protocol Buffers
Attached.

--

You received this message because you are subscribed to the Google Groups "Protocol Buffers" group.
To post to this group, send email to prot...@googlegroups.com.
To unsubscribe from this group, send email to protobuf+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/protobuf?hl=en.



config.log

Ryan Rosario

unread,
Dec 20, 2009, 12:38:10 AM12/20/09
to Protocol Buffers
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

> ...
>
> read more »
>
>  config.log
> 52KViewDownload

Reply all
Reply to author
Forward
0 new messages