It definitely DOES seem like the compiler is mis-reading something... Can you do a 'step' into that getPayload function as well? I see a few spots that this could POTENTIALLY happen. My only thought is that perhaps the compiler isn't doing a conversion correctly. The only place that I see that could cause this is the switch statement inside OCRepresentation::getPayload.
If you can find which line from 374 to 388 is causing this, it would be a big help. In that case, the solution could likely be to add an explicit cast on the line that is causing the issue for the variable 'val'. You might end up doing: static_cast<bool>(val) for example (if it was in AttributeType::Boolean). Alternatively, if you're getting it on the integer line (374?), the solution might be to change the static_cast to int32_t? I just had a coworker on Ubuntu 12.04 try it, and he was unable to make the problem happen with 4.6.3, so I wonder if our closing on this is to just say 4.6.4 is bad? PS: How are you trying all these compilers? It would be great if I could switch compilers pretty easy, so I was wondering if you have some secret? On Tue, 2015-08-11 at 05:26 +0000, ??? wrote: > Hi Keane. > > > > I found the point where is occurred an error from the code when > IoTivity is built using 4.6.4. > > This point is in OCRepresentation.cpp:147 and this line was called > when server sends response about GET request. > > > > I don't know why it is occurred an error. > > But, I just guess that there is dependency with gcc version. this is > pure surmise on my part. > > > > Please share your opinion to me about this issue. > > > > 0: > In entity handler wrapper: > > In Server CPP entity handler: > requestFlag : Request > requestType : GET > [Switching to Thread 0xb5924b40 (LWP 15473)] > > Breakpoint 1, OC::MessageContainer::getPayload (this=0xb59233c4) at > resource/src/OCRepresentation.cpp:142 > 142 OCRepPayload* root = nullptr; > (gdb) n > 143 for(const auto& r : representations()) > (gdb) n > 145 if(!root) > (gdb) n > 147 root = r.getPayload(); > (gdb) n > terminate called after throwing an instance of > 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::bad_get> > >' > what(): boost::bad_get: failed value get using boost::get > > > > > > > > ???( HyunJun Kim ) > Engineer > > IoT Solution Lab. | Web & Convergence Team. > Software R&D Center > Digital Media & Communications Business > SAMSUNG ELECTRONICS CO,. LTD. > > Mobile +82-10-5096-0151 > E-Mail HyunJun2.Kim at samsung.com | kiness at gmail.com > > > > > > > > ------- Original Message ------- > > Sender : Keane, Erich<erich.keane at intel.com> > > Date : 2015-08-11 01:38 (GMT+09:00) > > Title : Re: [dev] Is there any guideline for GCC version? > > > > I've been unable to get this to happen, though I'm on a 4.9 compiler. > > I think we had a few others try to validate it here with the 4.6.* > branch compilers, but I am not sure what could have caused that. > > The 'bad-get' issues are because we are trying to unpack data from a > 'variant', and are attempting to extract it as a different data type > than is in the variant. If you could debug and see what the 'which' > is > on the variant, as well as what we are attempting to pull it out as, > it > would go a long way to debugging it. > > Thanks, > Erich > > > On Mon, 2015-08-10 at 14:37 +0000, Lankswert, Patrick wrote: > > Jay, > > > > Did you find the root cause of the exception under gcc 4.6.4? > > > > There are multiple issues here that I am concerned about. First, is > there an issue in the code that the compiler is uncovering. If so, we > should fix the code. If this is a bug in the compiler, which is rare, > we should avoid that version of the compiler and make a strong and > detailed statement in the release notes. If there is a problem in the > boost libraries, we need to move and stay with the most stable and > widely supported version. > > > > In all cases, you are absolutely right, we should be clear to cover > our understanding of the recommended and supported gcc versions. > Unfortunately, we cannot be exhaustive in our validation of builds > based on all of the gcc version, it takes too much time. > > > > The high cost of validation and cross platform support is why > changing the versions of the compiler and tool chain requires > commitment from the majority of the community. > > > > BTW, it is good to see you on the boards. > > > > Pat > > > > > -----Original Message----- > > > From: iotivity-dev-bounces at lists.iotivity.org > [mailto:iotivity-dev- > > > bounces at lists.iotivity.org] On Behalf Of ??? > > > Sent: Monday, August 10, 2015 6:21 AM > > > To: iotivity-dev at lists.iotivity.org > > > Subject: [dev] Is there any guideline for GCC version? > > > > > > Hi all, > > > > > > I have a question on the GCC version for building the IoTivity. > > > I found that the "simpleServer/Client" built with gcc 4.6.4 > crashes with this > > > message .... > > > > > > ================================================================= > > > terminate called after throwing an instance of > > > 'boost::exception_detail::clone_impl> > or >' > > > what(): boost::bad_get: failed value get using boost::get > > > ================================================================= > > > > > > However, ths simpleServer/Client does not crash if I build them > with gcc version > > > 4.6.3. > > > > > > The guideline for the linux build in the IoTivity Web site > mentioned only gcc 4.6.1 > > > not the others. > > > I just want to ask whether there's a guideline for vaild GCC > version for building > > > the Iotivity Stack. > > > > > > I think this is very important issue for the IoTivity Users. :) > > > > > > Thank you. > > > Jay. > > > > > > > > > > > > > > > Jung-hyun Oh. > > > SW R&D Center | SAMSUNG ELECTRONICS CO.,LTD > > > +82-10-9890-6731 | Beyond your imagination, Always > > > _______________________________________________ > > > iotivity-dev mailing list > > > iotivity-dev at lists.iotivity.org > > > https://lists.iotivity.org/mailman/listinfo/iotivity-dev > > _______________________________________________ > > iotivity-dev mailing list > > iotivity-dev at lists.iotivity.org > > https://lists.iotivity.org/mailman/listinfo/iotivity-dev > > _______________________________________________ > iotivity-dev mailing list > iotivity-dev at lists.iotivity.org > https://lists.iotivity.org/mailman/listinfo/iotivity-dev > > > >
