Which LLVM version where you using? The lp_bld_init.c behavior varies tremendously with LLVM version.
>From Mathias' reply it looks like we should call llvm_start_multithreading >somewhere regardless. Jose ----- Original Message ----- > Thanks for this update! > I just looked into this issue again - in a usecase were multiple > threads are running and each thread creates a context, renders in > that context for some time and then destroys this context. No legacy > OpenGL features were used. > In this scenario one nearly always can reproduce a crash. From > analyzing the callstacks of the crashes one could see that there > were only two cases that can trigger such a crash > 1. the first call to glDrawArrays() within a thread (always only the > first one) > 2. the final call that cleans up the context (wglDeleteContext in > this case on Windows) > When locking those two calls the application seemed to become thread > safe. When just locking one of those two calls the crash still > occurs. So it seems the problematic part is when LLVM eather creates > the code - or LLVM does the cleanup. > Is the user of llvmpipe expected to initialize LLVM for multithreaded > support here ( llvm_start_multithreading ) - or should this not be > necessary and this issue is more likely a result that still some > LLVM contexts are shared? > Below i have attached a typical callstack one can see when a heap > corruption occurs - may be this gives some attional insight: > opengl32.dll!malloc(unsigned __int64 size) Line 163 + 0x43 bytes C > opengl32.dll!operator new(unsigned __int64 size) Line 59 + 0x8 bytes > C++ > opengl32.dll!llvm::APInt::sext() + 0x17b bytes C++ > opengl32.dll!llvm::ConstantRange::signExtend() + 0x8c bytes C++ > opengl32.dll!llvm::ConstantRange::sextOrTrunc() + 0x25 bytes C++ > opengl32.dll!llvm::ScalarEvolution::getSignedRange() + 0x10fb bytes > C++ > opengl32.dll!llvm::ScalarEvolution::isKnownNonNegative() + 0x13 bytes > C++ > opengl32.dll!llvm::ScalarEvolution::getSignExtendExpr() + 0x17e bytes > C++ > opengl32.dll!llvm::ScalarEvolution::getAnyExtendExpr() + 0x17c bytes > C++ > opengl32.dll!`anonymous namespace'::LSRInstance::GenerateTruncates() > + 0x1df bytes C++ > opengl32.dll!`anonymous > namespace'::LSRInstance::GenerateAllReuseFormulae() + 0x6ce bytes > C++ > opengl32.dll!`anonymous namespace'::LSRInstance::LSRInstance() + > 0x316 bytes C++ > opengl32.dll!`anonymous namespace'::LoopStrengthReduce::runOnLoop() + > 0x4a bytes C++opengl32.dll!llvm::LPPassManager::runOnFunction() + > 0x492 bytes C++ > opengl32.dll!llvm::FPPassManager::runOnFunction() + 0x314 bytes C++ > opengl32.dll!llvm::FunctionPassManagerImpl::run() + 0x70 bytes C++ > opengl32.dll!llvm::FunctionPassManager::run() + 0xd2 bytes C++ > opengl32.dll!llvm::JIT::runJITOnFunctionUnlocked() + 0x20 bytes C++ > opengl32.dll!llvm::JIT::getPointerToFunction() + 0x287 bytes C++ > opengl32.dll!generate_variant(llvmpipe_context * lp, > lp_fragment_shader * shader, const lp_fragment_shader_variant_key * > key) Line 2199 + 0x13 bytes C > opengl32.dll!llvmpipe_update_fs(llvmpipe_context * lp) Line 2647 + > 0x27 bytes C > opengl32.dll!llvmpipe_update_derived(llvmpipe_context * llvmpipe) > Line 159 C > opengl32.dll!llvmpipe_draw_vbo(pipe_context * pipe, const > pipe_draw_info * info) Line 69 C > opengl32.dll!st_draw_vbo(gl_context * ctx, const _mesa_prim * prims, > unsigned int nr_prims, const _mesa_index_buffer * ib, unsigned char > index_bounds_valid, unsigned int min_index, unsigned int max_index, > gl_transform_feedback_object * tfb_vertcount) Line 274 + 0x2a bytes > C > opengl32.dll!vbo_draw_arrays(gl_context * ctx, unsigned int mode, int > start, int count, unsigned int numInstances, unsigned int > baseInstance) Line 627 C > opengl32.dll!vbo_exec_DrawArrays(unsigned int mode, int start, int > count) Line 653 C > Von: Jose Fonseca <[email protected]> > An: [email protected] > Cc: [email protected] > Betreff: Re: [Mesa-dev] thread safe llvmpipe > Datum: Sun, 13 Jan 2013 02:22:03 +0100 > That work has been merged (w/ LLVM 3.1 and MC-JIT support), however > it's quite likely that's there are still race conditions, as nobody > has been pursuing llvmpipe thread-safety so far. > Jose > > Last year end of march i remember there was a discusssion about the > > thread safety in llvmpipe. > > > It seems that llvmpipe was not thread safe since the underlying > > LLVM > > contexts were shared, but there was a branch mentioned that fixes > > this issue and that was planned to be merged to the mainline in the > > future. > > > When working with the latest mesa version i currently still notice > > that llvmpipe is currently not thread safe - so i assume that this > > changes that bring separated LLVM context handling have not been > > submitted to the main line so far. > > > Any new information available concerning this topic? > > > _______________________________________________ > > > mesa-dev mailing list > > > [email protected] > > > http://lists.freedesktop.org/mailman/listinfo/mesa-dev > _______________________________________________ mesa-dev mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/mesa-dev
