slo2otl segmentation fault

   6814   7   2
User Avatar
Member
10 posts
Joined: 12月 2006
Offline
Hey there,

I am trying to convert a RenderMan shader to an otl for useing it inside Houdini.
Therefore I execute
slo2otl.py -l surf_snow.otl surf_snow.slo
but I get this error message:
2998: Fatal error: Segmentation fault (sent by pid 1177974)
Traceback from hython 12.1.125 (Compiled on 11/06/12 linux-x86_64-gcc4.4)

I also tried
hython slo2otl.py -l surf_snow.otl surf_snow.slo
and
hython %HFS%\bin\slo2otl.py -l surf_snow.otl surf_snow.slo
both with the same result.

I already checked the houdini_setup_bash file is sourced.
I am running Houdini 12.1.125 on Fedora 17 with the default gcc 4.7 compiler. Is the gcc version causing the issue?

Any hint would be very much appreciated!

grs,
–Markus
User Avatar
Member
320 posts
Joined: 8月 2007
Offline
You can view the python source on slo2otl.py and see that it depends on two different binaries. “sloinfo”, which ships with prman, and “rmands”, which comes with houdini.

I would locate both binaries, and run ldd on them to see if there are any missing libs.

You might also be able to run hython in verbose mode (passing -v), but I'm not sure. (it could be a python issue, instead of the above)
www.alan-warren.com
User Avatar
Member
10 posts
Joined: 12月 2006
Offline
Hey Alan,

that was genius. I would have never came up with that!

There are three libaries that rmands can't find:
libprman-15.2.so => not found
libprman.so => not found
/opt/houdini_tools/prman/prman-15.2-1/lib/libprman-15.2.so => not found
They should probably point to the same lib, but the problem is that I have prman 17.0 installed… Is there an easy way to tell Houdini to use that installation or do I really need to install 15.2?

Thanks a lot!
–Markus
User Avatar
Member
320 posts
Joined: 8月 2007
Offline
You should add $RMANTREE/lib to $LD_LIBRARY_PATH for the shell you're using.

if necessary, make a symbolic link for libprman-15.2.so that points to libprman.so
www.alan-warren.com
User Avatar
Member
10 posts
Joined: 12月 2006
Offline
Sounds reasonable.

I did the above and now rmands finds all the libs:
ldd /opt/hfs12.1.125/bin/rmands
linux-vdso.so.1 => (0x00007fff61771000)
libjemalloc.so.1 => /opt/hfs12.1.125/bin/../dsolib/libjemalloc.so.1 (0x00007f9861e0d000)
libHoudiniPRM.so => /opt/hfs12.1.125/bin/../dsolib/libHoudiniPRM.so (0x00007f986179a000)
libHoudiniUT.so => /opt/hfs12.1.125/bin/../dsolib/libHoudiniUT.so (0x00007f985ffdc000)
libtiff.so.4 => /opt/hfs12.1.125/bin/../dsolib/libtiff.so.4 (0x00007f985fd79000)
libjpeg.so.62 => /opt/hfs12.1.125/bin/../dsolib/libjpeg.so.62 (0x00007f985fb54000)
libOpenCL.so.1 => /opt/hfs12.1.125/bin/../dsolib/libOpenCL.so.1 (0x00007f985f94f000)
libxml2.so.2 => /opt/hfs12.1.125/bin/../dsolib/libxml2.so.2 (0x00007f985f5ff000)
libiconv.so.2 => /opt/hfs12.1.125/bin/../dsolib/libiconv.so.2 (0x00007f985f322000)
libtbb.so.2 => /opt/hfs12.1.125/bin/../dsolib/libtbb.so.2 (0x00007f985f0f2000)
libtbbmalloc.so.2 => /opt/hfs12.1.125/bin/../dsolib/libtbbmalloc.so.2 (0x00007f985eed0000)
libboost_regex-gcc44-mt-1_46_1.so.1.46.1 => /opt/hfs12.1.125/bin/../dsolib/libboost_regex-gcc44-mt-1_46_1.so.1.46.1 (0x00007f985ebea000)
libdl.so.2 => /lib64/libdl.so.2 (0x0000003ccda00000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003ccd200000)
libresolv.so.2 => /lib64/libresolv.so.2 (0x0000003ccee00000)
libdwelf.so => /opt/hfs12.1.125/bin/../dsolib/libdwelf.so (0x00007f985e99b000)
libboost_iostreams-gcc44-mt-1_46_1.so.1.46.1 => /opt/hfs12.1.125/bin/../dsolib/libboost_iostreams-gcc44-mt-1_46_1.so.1.46.1 (0x00007f985e783000)
libz.so.1 => /opt/hfs12.1.125/bin/../dsolib/libz.so.1 (0x00007f985e56a000)
libboost_thread-gcc44-mt-1_46_1.so.1.46.1 => /opt/hfs12.1.125/bin/../dsolib/libboost_thread-gcc44-mt-1_46_1.so.1.46.1 (0x00007f985e351000)
libboost_date_time-gcc44-mt-1_46_1.so.1.46.1 => /opt/hfs12.1.125/bin/../dsolib/libboost_date_time-gcc44-mt-1_46_1.so.1.46.1 (0x00007f985e13e000)
libprman-15.2.so => /opt/pixar/RenderManProServer-17.0/lib/libprman-15.2.so (0x00007f985c9b7000)
libstdc++.so.6 => /lib64/libstdc++.so.6 (0x0000003cd5200000)
libm.so.6 => /lib64/libm.so.6 (0x0000003ccd600000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x0000003cd0600000)
libc.so.6 => /lib64/libc.so.6 (0x0000003ccce00000)
/lib64/ld-linux-x86-64.so.2 (0x0000003ccca00000)
librt.so.1 => /lib64/librt.so.1 (0x0000003ccde00000)
It now lists only one libprman reference instead of three like before, but still the error persists.
Even though I also added the verbose flag to slo2otl.py the output is very limited so I can't really debug what's going wrong.
Any other ideas?

Thanks again,
–Markus
User Avatar
スタッフ
2641 posts
Joined: 7月 2005
Offline
Alanw
You can view the python source on slo2otl.py and see that it depends on two different binaries. “sloinfo”, which ships with prman, and “rmands”, which comes with houdini.

I would locate both binaries, and run ldd on them to see if there are any missing libs.

You might also be able to run hython in verbose mode (passing -v), but I'm not sure. (it could be a python issue, instead of the above)

I would keep away from using rmands. Instead, there's the rmands.py python module which is used by slo2otl.py.

slo2otl.py parses the output of sloinfo and builds but uses the rmands.py module to call out to the “hotl” command to build the OTL for the shader.

The rmands.py module is also used by sdl2otl (for 3delight).

rmands is the old old C++ version which was opaque and had to be linked to a specific version of prman.

If you're getting a core dump when running slo2otl.py, you can run “file core” to tell you which program is dumping core… It would either be one of hython, sloinfo or hotl. That might help track down what's not working. dmesg might also tell you which part is crashing.
User Avatar
Member
10 posts
Joined: 12月 2006
Offline
Hey Mark, thanks for the information!

I tried to create a core dump (I didn't manage to get one so far), while doing that I was still in su and I ran the exact same command again. And it just worked…

Here is the output of my shell:
$ slo2otl.py -l disp_snow.otl disp_snow.slo
9714: Fatal error: Segmentation fault (sent by pid 1177974)
Traceback from hython 12.1.125 (Compiled on 11/06/12 linux-x86_64-gcc4.4)
$ su
Password:
# slo2otl.py -vl disp_snow.otl disp_snow.slo
Processing: disp_snow.slo
$


I checked the environment variables are the same in both cases.
Could it be some kind of permission problem? I do have writing permission in the current folder that I want to create the otl in. But are there any other files the python script tries to execute or change, which might be protected?

To me it looks like we are almost there. ^^

Thanks a lot guys, for your support!!

Cheers,
–Markus
User Avatar
スタッフ
2641 posts
Joined: 7月 2005
Offline
BaiLong
Hey Mark, thanks for the information!

I tried to create a core dump (I didn't manage to get one so far), while doing that I was still in su and I ran the exact same command again. And it just worked…

Here is the output of my shell:
$ slo2otl.py -l disp_snow.otl disp_snow.slo
9714: Fatal error: Segmentation fault (sent by pid 1177974)
Traceback from hython 12.1.125 (Compiled on 11/06/12 linux-x86_64-gcc4.4)
$ su
Password:
# slo2otl.py -vl disp_snow.otl disp_snow.slo
Processing: disp_snow.slo
$


I checked the environment variables are the same in both cases.
Could it be some kind of permission problem? I do have writing permission in the current folder that I want to create the otl in. But are there any other files the python script tries to execute or change, which might be protected?

To me it looks like we are almost there. ^^

Thanks a lot guys, for your support!!

Cheers,
–Markus

In rmands (makeOTL), it calls tempfile.mkdtemp(). So, there's a temporary directory built to store all the contents of the OTL. Then it calls hotl to do the actual OTL creation.

So, perhaps the tempfile module is doing the wrong thing for you?

You might try editing the rmands file and sticking in some print statements to try to track down whether certain code is being run.
  • Quick Links