Re: Core Dump with c++ 4.1.1
Folks, sorry for the delayed response to this thread. We are currently investigating this issue and assuming the problem to be in our setup and not protocol-buffer libs (using protobuf 2.1.0 for time being). For clarification we are using G++ 4.1.1 thanks, Sushil On Fri, Aug 14, 2009 at 2:19 PM, Kenton Varda ken...@google.com wrote: I assume that when you say C++ 4.1.1, what you mean is G++ 4.1.1, i.e. GCC 4.1.1's C++ compiler? Or do you mean some other compiler? C++ itself does not have version numbers. I have tested protocol buffers on many different versions of GCC, including both the 3.x and 4.x range. It seems very unlikely that 4.1.1 in particular doesn't work. Can you run the tests? I.e. do make check in the top-level protobuf directory. If the tests pass, then the problem is certainly something with the way you are installing the libraries. Maybe you installed them to the wrong location, and then when you build the examples you are actually building them against the old version? The crash looks like something that would happen if you mixed compiler versions. There's not much more I can say with only one line of a stack trace. If you can't figure it out, it might help if you provided the whole stack. On Fri, Aug 14, 2009 at 8:52 AM, Sushil Shelly skshe...@gmail.com wrote: Kenton and Team, We recently moved to using c++ 4.1.1 and are getting a segmentation fault as shown below. We are simply building the tutorial code and then run 'add_person' (This same test runs fine when built with C++ 3.4.0). Partial core dump is shown below!! - Core was generated by `add_person'. Program terminated with signal 11, Segmentation fault. #0 0x0809dbc7 in std::_Rb_treestd::string, std::pairstd::string const, std::pairvoid const*, int , std::_Select1ststd::pairstd::string const, std::pairvoid const*, int , std::lessstd::string, std::allocatorstd::pairstd::string const, std::pairvoid const*, int ::insert_unique (this=0x4, _...@0xbfbed9c8) - This is fairly urgent for us and is a show-stopper - could you please comment. thanks, Sushil. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Core Dump with c++ 4.1.1
Yea we do a make clean and rebuild to get new libraries, Is there any one actually using C++ 4.1.1? On Fri, Aug 14, 2009 at 11:59 AM, Monty Taylor mord...@inaugust.com wrote: Sushil Shelly wrote: Kenton and Team, We recently moved to using c++ 4.1.1 and are getting a segmentation fault as shown below. We are simply building the tutorial code and then run 'add_person' (This same test runs fine when built with C++ 3.4.0). Did you re-build protobuf after upgrading to 4.1.1? C++ doesn't guarantee binary compatibility in this particular case - so if your library was built with the old compiler version and the test program with the new, it may be an issue. Partial core dump is shown below!! - Core was generated by `add_person'. Program terminated with signal 11, Segmentation fault. #0 0x0809dbc7 in std::_Rb_treestd::string, std::pairstd::string const, std::pairvoid const*, int , std::_Select1ststd::pairstd::string const, std::pairvoid const*, int , std::lessstd::string, std::allocatorstd::pairstd::string const, std::pairvoid const*, int ::insert_unique (this=0x4, _...@0xbfbed9c8) - This is fairly urgent for us and is a show-stopper - could you please comment.. thanks, Sushil. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
upgrade to latest release
Kenton, I need to upgrade a linux installation of protocol buffers. I have 2.0.3 and need to move up to use 2.1.0 - is there a set procedure to do this? thanks Sushil --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: upgrade to latest release
thanks for the heads up, upgrading to 2.1.0 noticed that the c++ example now requires -lpthread, once I compile my application it will need to know about pthread also. is there a set of release notes that i need to be aware of, and also are there any patches against 2.1.0 that I may need, if so how do i find out what they are? will make uninstall take out all flavors of protocol buffer libraries (I used make install on top of a prior install and would like to remove the older version) thanks On Wed, Jul 29, 2009 at 2:22 PM, Kenton Varda ken...@google.com wrote: On Wed, Jul 29, 2009 at 4:14 AM, Sushil Shelly skshe...@gmail.com wrote: I need to upgrade a linux installation of protocol buffers. I have 2.0.3 and need to move up to use 2.1.0 - is there a set procedure to do this? You can just install it normally. You may also want to recompile any apps based on it, but this is not strictly necessary. Although different versions of libprotobuf.so are not binary-compatible (C++ sadly makes compatibility too difficult to achieve), we use libtool's version numbering to make sure that binary-incompatible versions of libprotobuf do not overwrite each other. So, any binaries you compiled against the old version will continue to use the old version at runtime. If you want to uninstall the old version, then run make uninstall from the same directory where you you ran make install to install it. BTW, 2.2.0 will be out in the next week or two. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
possible bug?
I have a simple enumeration in my dot-proto as follows
message Bar {
required string name = 1;
required string device = 2;
}
enum msg State {
IDLE = 0;
BUSY = 1;
}
message Foo {
required State state = 1;
required Bar bar = 2;
}
now i set the required fields by using the helper methods provided by the
object;
the state is set to IDLE in the message.
On Receiving () - I de-serialize but nothing shows up in the msg, its as if
the required field was not set.
Then in another test case I set the state to Busy and send - nothing else
has changed,
this time I get the message and I am able to see all information.
Is this a known issue?
enum msg State {
DO_NOT_USE = 0;
IDLE = 1;
BUSY = 2;
}
IS THE WORK AROUND I AM USING
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
