Thank you very much for all the responses. I figured it wasn't an multithreading problem, since it also didn't run if only called once in a single OS-Thread.
Hartmut's Idea with the stack-sizes fixed it. Using -Ihpx.stacks.small_size=0x20000 wasn't enough, but using an bigger size of -Ihpx.stacks.small_size=0x200000 it works. Thanks again for the fast help. Best, Jan On 21.01.2016 22:11, Lars Viklund wrote: > On 21/01/2016 18:10, Hartmut Kaiser wrote: >> Jan, >> >>> I'm still working on my parallel rendering project and can't find a >>> solution for an error for over a month now. >>> Whenever i call my rendering routine through an action (component- or >>> plain action), i get a Segfault at glLinkProgram(). >>> If i call it in hpx_main() as a normal method or through std::async, it >>> works fine, so my method is not faulty (correct image, no glErrors). >>> >>> I want to call it in a component action to render 16 images on 16 >>> components of a 16-core node/locality simultaneously, but the simplified >>> version of just calling it once on a 1-core locality in a plain action >>> in the hpx_main() gives the same segmentation fault. >>> >>> I know this most likely is an error on the interaction of OpenGL and >>> asynchronous actions in general, but maybe someone on this list has an >>> idea or has used OpenGL with HPX. >> Is OpenGL thread-safe in the first place? If you run an OpenGL function from >> inside an action and use more than one core, you might end up calling into >> OpenGL concurrently, not sure if that's a problem. > OpenGL contexts may be made current on any OS thread, but a given > context may only be current on a single OS thread at a time. > > As HPX actions may be dispatched on different OS threads over time, you > need to be very careful about which OS thread your context is current > on. > > In general when doing concurrency and 3D APIs, you tend to prepare as > much work as possible in threads without invoking API functions, and > chew through the deferred work in a dedicated OS thread that has control > over the context. > > While there's shared contexts and shared resources in OpenGL, they have > a bit of a performance penalty and are not quite the fast-path when it > comes to driver implementations. Some resources like FBOs and VAOs > cannot be shared at all. > > As a side note on multiple contexts and function pointers for > extensions, it's technically illegal to share function pointers between > different contexts, but if you only have one context, you don't need to > care about that. If you do, you may need to use GLEW-MX or similar > extension wrangler. > >> Another issue could be that you run out of stack-space. HPX threads have a >> very limited stack-size by default which is easily overflown. Try running >> your app with -Ihpx.stacks.small_size=0x20000 to increase the default >> stack-sizes used. > _______________________________________________ > hpx-users mailing list > [email protected] > https://mail.cct.lsu.edu/mailman/listinfo/hpx-users _______________________________________________ hpx-users mailing list [email protected] https://mail.cct.lsu.edu/mailman/listinfo/hpx-users
