New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

undefined symbol: rtcNewInstance2 #31

Closed
Theverat opened this Issue Jan 2, 2018 · 14 comments

Comments

Projects
2 participants
@Theverat
Member

Theverat commented Jan 2, 2018

Continued from: https://forums.luxcorerender.org/viewtopic.php?f=5&t=19&p=323#p320

Any scene I try crashes when I use TILEPATH engine.
Example: testfile.zip
I exported this simple scene with FILESAVER. When I try to start it with luxcoreui, it closes and the end of the log shows this:

[LuxRays][0.059] Adding DataSet accelerator: EMBREE
[LuxRays][0.059] Total vertex count: 4
[LuxRays][0.059] Total triangle count: 2
./bin/luxcoreui: symbol lookup error: ./bin/luxcoreui: undefined symbol: rtcNewInstance2

Maybe my build is messed up? I'll try a full rebuild.
edit: Did not help.
When started from Blender it crashes with a SIGSEGV when I try to stop the render.

By the way, it would make my life much easier if LuxCore would try to find files with incorrect filepaths in the current directory as a fallback.
(E.g. if "scene.scn" is not at the specified path that was set by FILESAVER, try to find it in the folder where the root render.cfg lies)

@Dade916

This comment has been minimized.

Member

Dade916 commented Jan 3, 2018

At first sight, I would say you have an older version of Embree DLL around so just run a

ldd ./bin/luxcoreui | grep embree

and the output should be something like

[...] libembree.so.2 => /home/david/projects/luxcorerender/embree-2.17.1.x86_64.linux/lib/libembree.so.2 (0x00007fd5f034c000) libtbb.so.2 => /home/david/projects/luxcorerender/embree-2.17.1.x86_64.linux/lib/libtbb.so.2 (0x00007fd5ec195000) libtbbmalloc.so.2 => /home/david/projects/luxcorerender/embree-2.17.1.x86_64.linux/lib/libtbbmalloc.so.2 (0x00007fd5ebf41000) [...]

so you can check if the DLLs are the right one or something else left from the past.

However you should get the error before any luxcoreui output and for any render engine (not just for TILEPATH). So the symbol lookup error doesn't make any sense.

I discover a crash running your scene if I run luxcoreui with a "-D renderengine.type PATHCPU". It was happening because TILEPATH had a check for the right samplers but many other render engined didn't have one for TILEPATHSAMPLER (i.e. PATHCPU used with TILEPATHSAMPLER). I fixed this probelm.

To recap, try latest sources, they should fix your problem. If they don't try the "ldd" check.

@Theverat

This comment has been minimized.

Member

Theverat commented Jan 3, 2018

You're right, the way I started luxcoreui caused it to use some embree in my system instead of the bundled one.

libembree.so.2 => /usr/lib/x86_64-linux-gnu/libembree.so.2 (0x00007f41c4e5c000)

So I put it in BlendLuxCore's bin folder with the rest of the binaries and libs and now the scene works.
So this seems again unrelated to my Blender crash.
I'll debug further...

@Dade916

This comment has been minimized.

Member

Dade916 commented Jan 3, 2018

Blender crash ? Which one ?

@Theverat

This comment has been minimized.

Member

Theverat commented Jan 3, 2018

When I stop a rendering with TILEPATH in Blender, it crashes.
I have the feeling that I'm doing something wrong in Python, like a few weeks ago when I accidentally removed the pyluxcore.Init() call.

@Dade916

This comment has been minimized.

Member

Dade916 commented Jan 4, 2018

It happens here too. By looking at the stack trace:

# Blender 2.79 (sub 0), Commit date: 2017-09-11 10:43, Hash 5bd8ac9abfa
Modules Installed (BlendLuxCore) from '/home/david/projects/luxcorerender/blendluxcore.zip' into '/home/david/.config/blender/2.79/scripts/addons'  # Info
bpy.context.scene.render.engine = 'LUXCORE'  # Property
bpy.context.space_data.system_bookmarks_active = 0  # Property
bpy.context.scene.luxcore.config.use_tiles = True  # Property

# backtrace
/home/david/opt/blender-2.79-linux-glibc219-x86_64/blender(BLI_system_backtrace+0x20) [0x1a6c8e0]
/home/david/opt/blender-2.79-linux-glibc219-x86_64/blender() [0x107a525]
/lib/x86_64-linux-gnu/libc.so.6(+0x36cb0) [0x7fe6c0764cb0]
/home/david/.config/blender/2.79/scripts/addons/BlendLuxCore/bin/pyluxcore.so(_ZN7luxcore6detail17RenderSessionImpl11UpdateStatsEv+0x103a) [0x7fe6944002ea]
/home/david/.config/blender/2.79/scripts/addons/BlendLuxCore/bin/pyluxcore.so(+0x1c1966) [0x7fe6943bc966]
/home/david/projects/luxcorerender/boost_1_56_0-bin/lib/libboost_python.so.1.56.0(_ZNK5boost6python7objects8function4callEP7_objectS4_+0xca) [0x7fe690cb7aaa]
/home/david/projects/luxcorerender/boost_1_56_0-bin/lib/libboost_python.so.1.56.0(+0x28e18) [0x7fe690cb7e18]
/home/david/projects/luxcorerender/boost_1_56_0-bin/lib/libboost_python.so.1.56.0(_ZN5boost6python21handle_exception_implENS_9function0IvEE+0x53) [0x7fe690cc20e3]
/home/david/projects/luxcorerender/boost_1_56_0-bin/lib/libboost_python.so.1.56.0(+0x27723) [0x7fe690cb6723]
/home/david/opt/blender-2.79-linux-glibc219-x86_64/blender(PyObject_Call+0x5c) [0x2e40ebc]
/home/david/opt/blender-2.79-linux-glibc219-x86_64/blender(PyEval_EvalFrameEx+0x3812) [0x2f041f2]
/home/david/opt/blender-2.79-linux-glibc219-x86_64/blender() [0x2f0a4ee]
/home/david/opt/blender-2.79-linux-glibc219-x86_64/blender(PyEval_EvalCodeEx+0x23) [0x2f0a5c3]
/home/david/opt/blender-2.79-linux-glibc219-x86_64/blender() [0x2e6b4c4]
/home/david/opt/blender-2.79-linux-glibc219-x86_64/blender(PyObject_Call+0x5c) [0x2e40ebc]
/home/david/opt/blender-2.79-linux-glibc219-x86_64/blender() [0x1474574]
/home/david/opt/blender-2.79-linux-glibc219-x86_64/blender() [0x19a8841]
/home/david/opt/blender-2.79-linux-glibc219-x86_64/blender(RE_engine_render+0x342) [0x13f3942]
/home/david/opt/blender-2.79-linux-glibc219-x86_64/blender() [0x14062d9]
/home/david/opt/blender-2.79-linux-glibc219-x86_64/blender() [0x1406908]
/home/david/opt/blender-2.79-linux-glibc219-x86_64/blender() [0x1409d6a]
/home/david/opt/blender-2.79-linux-glibc219-x86_64/blender(RE_BlenderFrame+0xbe) [0x140a3be]
/home/david/opt/blender-2.79-linux-glibc219-x86_64/blender() [0x134bf01]
/home/david/opt/blender-2.79-linux-glibc219-x86_64/blender() [0x108aa6a]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x8184) [0x7fe6c1cba184]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d) [0x7fe6c082bffd]

I have the strong feeling RenderSession::UpdateStats() is called on the already closed RenderSession (a multi-thread race problem).

@Dade916

This comment has been minimized.

Member

Dade916 commented Jan 4, 2018

Yes, with the help of some printf, I can confirm that RenderSession::UpdateStats() is called after the RenderSession::Stop().

[LuxCore][28.258] [AutoLinearToneMap] Compiling AutoLinearToneMap_Apply Kernel
[LuxCore][28.258] [AutoLinearToneMap] Kernels compilation time: 3ms
===================RenderSessionImpl::UpdateStats()
===================RenderSessionImpl::UpdateStats()
===================RenderSessionImpl::UpdateStats()
===================RenderSessionImpl::UpdateStats()
===================RenderSessionImpl::UpdateStats()
===================RenderSessionImpl::UpdateStats()
===================RenderSessionImpl::Stop()
===================RenderSessionImpl::UpdateStats()
Writing: /tmp/untitled.crash.txt
Segmentation fault (core dumped)

I will neutralize this problem on my side making UpdateStats() harmless if called outside a Start()/Stop() however you have 2 threads using the same RenderSession in parallel and that can be the source of a lot of problems so you should still check the Python code.

@Dade916 Dade916 self-assigned this Jan 4, 2018

@Dade916 Dade916 added the invalid label Jan 4, 2018

@Dade916 Dade916 added this to To Do in LuxCoreRender v2.0 via automation Jan 4, 2018

@Dade916

This comment has been minimized.

Member

Dade916 commented Jan 4, 2018

The fix is now online and I can confirm Blender doesn't crash anymore.

@Theverat

This comment has been minimized.

Member

Theverat commented Jan 4, 2018

however you have 2 threads using the same RenderSession in parallel and that can be the source of a lot of problems so you should still check the Python code.

This will be hard to track down... I'm not creating any threads in Python, so I guess it is something done by Blender.

@Dade916

This comment has been minimized.

Member

Dade916 commented Jan 4, 2018

Just check if you are doing something else in the code fragment where you are calling RenderSession::UpdateStats(). I assume it is some kind of callback done by Blender.
There may be some more LuxCore function to check and/or to use a Python lock to protect the RenderSession from multiple parallel accesses.

@Theverat

This comment has been minimized.

Member

Theverat commented Jan 4, 2018

Looks like this is the problem: https://github.com/LuxCoreRender/BlendLuxCore/blob/master/engine/__init__.py#L114
I'll just put the UpdateStats() before the Stop()

LuxCoreRender v2.0 automation moved this from To Do to Done Jan 4, 2018

@Dade916

This comment has been minimized.

Member

Dade916 commented Jan 4, 2018

BTW, all halt conditions are now enforced by the core and you can just call RenderSession::IsDone() to check if it is time to stop or not (here https://github.com/LuxCoreRender/BlendLuxCore/blob/0391d941d84a97aa643ef1ad5abf2139de264d2b/engine/__init__.py#L101)

Like in this code:

while (!session->HasDone()) {

@Theverat

This comment has been minimized.

Member

Theverat commented Jan 4, 2018

I've seen the halt condition properties, but can I change those during the render process?
I'd like to have that option (same for periodic film save interval by the way).
For example if you notice that your render won't be done after 10 minutes you can raise the halt time during the render. Or if you notice that a film save every 5 minutes is too expensive, you can raise the time without re-starting the render.

@Dade916

This comment has been minimized.

Member

Dade916 commented Jan 4, 2018

I don't think it is currently possible but it is easy to add the support for editing halt conditions with Parse() method (new issue #33).
I have already created an issue for film saving, rendering resume, etc.: #32

@Dade916

This comment has been minimized.

Member

Dade916 commented Jan 5, 2018

Updated #33

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment