[Proton-c C++ 0.16.0] [Solaris Sparc] [GCC 4.9.2] Assuming threads will propage exceptions

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[Proton-c C++ 0.16.0] [Solaris Sparc] [GCC 4.9.2] Assuming threads will propage exceptions

Adel Boutros
Hello,


I hope you missed my mails about Solaris 😉


We are currently testing whether we can compile on Solaris using GCC 4.9.2. We were successful in doing so for Solaris x86 but we have hit a problem in Sparc.


It seems related to certain assumptions made around how threads propagates exceptions:


The failing test is "examples/cpp/example_test.py: test_ssl_bad_name"

In examples/cpp/ssl.cpp [1], it spawns another thread and wait for it to throw an exception.


However, if you check the thread documentation[2], it states the propagation of exceptions is not guaranteed[3].


So I was wondering if the assumption that Proton makes is not a big dangerous and should be changed?


Simpler Example

---------------------
#include <stdexcept>
#include <iostream>
#include <thread>

class example_cert_error : public std::runtime_error
{
    public:
        explicit example_cert_error(const std::string& s) : std::runtime_error(s) {}
};

int main(int argc, char** argv) {
    try {
        std::thread th([](){throw example_cert_error("my error"); });
    } catch (const example_cert_error& ce) {
        std::cout << "Caught: " << ce.what() << std::endl;
    }
    return 0;
}



Solaris X86

---------------
$ g++49 -std=c++11 throw.cpp -o throw
$ ./throw
Caught: my error

Solaris Sparc
-----------------
$ g++49 -std=c++11 throw.cpp -o throw
$ ./throw
terminate called without an active exception
Abort (core dumped)


[1]: https://github.com/apache/qpid-proton/blob/0.16.x/examples/cpp/ssl.cpp#L178

[2]: http://en.cppreference.com/w/cpp/thread/thread

[3]: The top-level function may communicate its return value or an exception to the caller

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Proton-c C++ 0.16.0] [Solaris Sparc] [GCC 4.9.2] Assuming threads will propage exceptions

astitcher
Briefly - Can you try master. This should be fixed in the upcoming
0.18.

Andrew


On Wed, 2017-07-26 at 10:51 +0000, Adel Boutros wrote:

> Hello,
>
>
> I hope you missed my mails about Solaris 😉
>
>
> We are currently testing whether we can compile on Solaris using GCC
> 4.9.2. We were successful in doing so for Solaris x86 but we have hit
> a problem in Sparc.
>
>
> It seems related to certain assumptions made around how threads
> propagates exceptions:
>
>
> The failing test is "examples/cpp/example_test.py: test_ssl_bad_name"
>
> In examples/cpp/ssl.cpp [1], it spawns another thread and wait for it
> to throw an exception.
>
>
> However, if you check the thread documentation[2], it states the
> propagation of exceptions is not guaranteed[3].
>
>
> So I was wondering if the assumption that Proton makes is not a big
> dangerous and should be changed?
>
>
> Simpler Example
>
> ---------------------
> #include <stdexcept>
> #include <iostream>
> #include <thread>
>
> class example_cert_error : public std::runtime_error
> {
>     public:
>         explicit example_cert_error(const std::string& s) :
> std::runtime_error(s) {}
> };
>
> int main(int argc, char** argv) {
>     try {
>         std::thread th([](){throw example_cert_error("my error"); });
>     } catch (const example_cert_error& ce) {
>         std::cout << "Caught: " << ce.what() << std::endl;
>     }
>     return 0;
> }
>
>
>
> Solaris X86
>
> ---------------
> $ g++49 -std=c++11 throw.cpp -o throw
> $ ./throw
> Caught: my error
>
> Solaris Sparc
> -----------------
> $ g++49 -std=c++11 throw.cpp -o throw
> $ ./throw
> terminate called without an active exception
> Abort (core dumped)
>
>
> [1]: https://github.com/apache/qpid-proton/blob/0.16.x/examples/cpp/s
> sl.cpp#L178
>
> [2]: http://en.cppreference.com/w/cpp/thread/thread
>
> [3]: The top-level function may communicate its return value or an
> exception to the caller
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Loading...