Segmentation Fault in pplxtasks.h at _IsPendingCancel

Dec 16, 2014 at 11:06 AM
Hi All

I have been using the casablanca library for some time now and have found it very useful and powerful.

However, I am now getting a segmentation fault at the same place each time and I am having trouble determining its cause. I am running on Ubuntu 14.04 LTS.

I have created a small main to reproduce the problem and the the specific fault looks like:

Thread [1] 7777 [core: 2] (Suspended : Signal : SIGSEGV:Segmentation fault)
pplx::details::_Task_impl_base::_IsPendingCancel() at pplxtasks.h:1,928 0x42663a    
pplx::task_completion_event<unsigned long>::set() at pplxtasks.h:2,725 0x43f9e5 
web::http::http_request::set_body() at http_msg.h:923 0x427e68  
main() at Hello.cpp:39 0x423515 
The code looks like:

#include <cpprest/basic_types.h>
#include <cpprest/http_client.h>
#include <cpprest/http_msg.h>

int main() {

    web::http::client::http_client client("");

    web::http::http_request request_msg(web::http::methods::POST);

    web::json::value jsonObject = web::json::value::object();

    jsonObject["Id"]          = web::json::value::number(static_cast<double>(23));
    jsonObject["Language"]    = web::json::value::string("en");

    // Segmentation fault occurs at this line

    return 0;
The exact error occurs in pplxtasks.h, line 1928:
        bool _IsPendingCancel()
            return (_M_TaskState == _PendingCancel);
I suspect that this is some sort of system configuration issue rather than anything specific with casablanca.

g++ -v:
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.9.2-0ubuntu1~14.04' --with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.9 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.9.2 (Ubuntu 4.9.2-0ubuntu1~14.04) 
ldd Debug/Hello: =>  (0x00007fff6dbfe000) => /usr/local/lib/ (0x00007f60af5e8000) => /usr/lib/x86_64-linux-gnu/ (0x00007f60af2c0000) => /lib/x86_64-linux-gnu/ (0x00007f60af0a8000) => /lib/x86_64-linux-gnu/ (0x00007f60aece2000) => /lib/x86_64-linux-gnu/ (0x00007f60aeac4000) => /usr/lib/x86_64-linux-gnu/ (0x00007f60ae8bf000) => /usr/lib/x86_64-linux-gnu/ (0x00007f60ae6a9000) => /usr/lib/x86_64-linux-gnu/ (0x00007f60ae3d4000) => /usr/lib/x86_64-linux-gnu/ (0x00007f60ae1d0000) => /lib/x86_64-linux-gnu/ (0x00007f60adf72000) => /lib/x86_64-linux-gnu/ (0x00007f60adb98000)
    /lib64/ (0x00007f60afacd000) => /lib/x86_64-linux-gnu/ (0x00007f60ad891000) => /lib/x86_64-linux-gnu/ (0x00007f60ad689000) => /usr/lib/x86_64-linux-gnu/ (0x00007f60ad30f000) => /usr/lib/x86_64-linux-gnu/ (0x00007f60acf07000) => /lib/x86_64-linux-gnu/ (0x00007f60acd03000) => /usr/lib/x86_64-linux-gnu/ (0x00007f60ab495000)
Could this be due to a bad install of g++ 4.9.2? Is it using the correct version of libstdc++?

Many thanks for your advice.

Jan 2, 2015 at 11:35 PM
Hi James,

Sorry for responding so late on this discussion, somehow it escaped my eyes.

I also would be surprised if the simple code you have above is an actual issue in the C++ Rest SDK. We are doing our testing on g+ 4.8 right now. I updated one of my machines to 4.9 and tried out your code snippet and didn't have any issues. Looking at your settings nothing else is jumping out at me. I'm using 2.4.0 instead fo 2.3.0, but I doubt that is the problem. The callstack doesn't make much sense there are no ppl tasks involved with the set_body function.