Sorry if some of you are offended by doulbe posting (this question is on the mailing list too), but I thought of trying my luck here as well.

Does anybody out here has 64bit Houdini running on Debian or Ubuntu? I get a segfault when trying to make a path at object level (sop level idem). Apart from this path object bug, there doesn't seem to be any other issue. I noticed that the crash occurs only when moving the mouse. You can set a start point but moving the mouse after that segmentation faults. Grrr. I'm so close. The REALLY weird thing is that when using a .hip file that was started on a 32 bit version, the path object works just fine. A new hip file doesn't.
Among the things I've tried to resolve this: delete all the non-default otl's, rename my $HOME/houdini8.0 directory, create new desktop,… I tried all this with the latest 64 bit build: 8.0.517, but also with the earliest 64bit build: 8.0.410 and all builds in between.

I also tried to revert back to a 32 bit version (8.0.523), but then houdini doesn't seem to recognize my nfs mounts anymore. Could ASSUME_KERNEL have something to do with that?

System information:
AMD 64x2 (dual core)
kernel 2.6.12-10-amd64-k8-smp
Nvidia Geforce 6600 GT PCI Express
Nvidia drivers 1.0-8178

At first I thought the path object bug was related to openGL graphics, but I'm ruling that out now since I have the same problem on a machine with AGP 8x Geforce 5200.

Can somebody help me pin down this little bugger?

Thanks.

Dries.

Not being able to easily repro the crash, I'm unclear as to exactly what causes what. Is this when you add points to the path? And what does “sop level idem” mean?

From what you're describing, it sounds like a Houdini bug, and obviously related to the 64 bit compile. There's apparently lots of odd accuracy issues that crop up when maintaining a 32 and 64 bit compile.

My first suggestion would be to not use the 64 bit build - all it's going to get you is better support for really huge files. However, the “failing to recognize the nfs mounts” throws me. What does that mean? I'm running a 32 bit compile on a 64 bit SUSE, and Houdini uses the NFS mounts all the time. It's an OS level thing - an app just asks for the location, the system returns it. Can you describe in more detail?

Cheers,

J.C.

Hey John,

The bug occurs when I start a paht object in the viewport at object level. When I click for the first point and then move the mouse to set a second point, Houdini segfaults. At Sop level, the same thing happens with a curve SOP. (sorry, that was very badly posted).

I'm also convinced that it is related to the 64 bit version. (although, the path object works fine on an existing .hip file which was first made up with a 32 bit version Houdini)

Okay, so when moving back to 32 bit, houdini doesn't recognize my nfs mounted filesystem anymore, meaning: in any dialog window, I can't navigate to a share. I can navigate through all the local files, but not a share. My home directory is on a share, so all my personal settings are not loaded. It's actually a share from an apple server, but it works just fine in the rest of linux. (I'm trying now to see whether a share that is in fact an export from the local filesystem will work. And for the record, the shares are automounted.



The other path of my thoughts goes down to the LD_LIBRARY_PATH variable. In ubuntu, by default, there is no LD_LIBRARY_PATH set but the file /etc/ld.so.conf looks like this:

$cat /etc/ld.so.conf
/lib32
/usr/lib32
/usr/X11R6/lib32


When sourcing houdini_setup_bash, the LD_LIBRARY_PATH gets set to /production/software/linux/houdini/dsolibusr/liblib and those last 2 entries are 64 bit libraries. Would it get confused?
Will the system setting get overruled by the environmental variable?


Hmm, continuing the search…

Thinking about it: the LD_LIBRARY_PATH is set only just before the houdini binary gets called. I'll try to set it systemwide. Maybe subprocessed are not aware…

DriesD
Sorry if some of you are offended by doulbe posting (this question is on the mailing list too), but I thought of trying my luck here as well.

I also tried to revert back to a 32 bit version (8.0.523), but then houdini doesn't seem to recognize my nfs mounts anymore. Could ASSUME_KERNEL have something to do with that?

System information:
AMD 64x2 (dual core)
kernel 2.6.12-10-amd64-k8-smp
Nvidia Geforce 6600 GT PCI Express
Nvidia drivers 1.0-8178

At first I thought the path object bug was related to openGL graphics, but I'm ruling that out now since I have the same problem on a machine with AGP 8x Geforce 5200.

Can somebody help me pin down this little bugger?

Thanks.

Dries.

Hi Dries,

I'm running Debian Unstable on a Dual Opteron (not Dual Core though).

System Info:
/proc/cpuinfo: AMD Opteron™ Processor 248
uname -a: 2.6.12-1-amd64-k8-smp
(II) NVIDIA(0): NVIDIA GPU detected as: Quadro FX 4000
(–) NVIDIA(0): VideoBIOS: 05.40.02.21.04
(II) NVIDIA(0): Detected AGP rate: 8X
(II) NVIDIA X Driver 1.0-7174 Tue Mar 22 06:47:49 PST 2005
(II) NVIDIA Unified Driver for all NVIDIA GPUs

I have no ASSUME_KERNEL set. I can't reproduce your bug. Unless it's something peculiar in the way you're creating the path object… I've tried it with another developer looking over my shoulder just to be sure.

I've tried several versions of Houdini up to and including 8.0.517

Sorry.

So with your old .hip file that was started in 32-bit, you can create new path objects without problems? Are there any embedded HDAs in it? If you load a different .hip file that was started on 64-bit, can you create a new path object?

This all seems very weird, however, we haven't exactly ruled out video driver problems. Is possible for you to try a 71.74 driver? Unfortunately, everyone seems reluctant to change video drivers because there's always problems with doing so.

When it crashes, what does your /tmp/crashlog_<user> say?

Mark, are you running the 64bit version of houdini? Are u using the 64-bit nvidia drivers?

Edward, I double checked digital assets, but no embedded ones. The path object is defined by $HFS/houdini/houdini/otls/OPlibObjects.otl
I uninstalled all my self made digital assets.

I'll try the 71.74 drivers now. I'll report back.

Hm. The 7174 drivers are no different. I think I can rule out it being a driver problem now? Also, I'm using gnome, in which the LD_LIBRARY_PATH gets overriden. When am I supposed to source the houdini_setup_bash script? What does your LD_LIBRARY_PATH variable say under ubuntu gnome?

DriesD
Hm. The 7174 drivers are no different. I think I can rule out it being a driver problem now? Also, I'm using gnome, in which the LD_LIBRARY_PATH gets overriden. When am I supposed to source the houdini_setup_bash script? What does your LD_LIBRARY_PATH variable say under ubuntu gnome?

I'm running Debian unstable, not Ubuntu. I'm running about as pure-64 as you can get. I can't run open-office, flash etc.

I am running Gnome, but with the xfwm4 window manager instead of metacity.

LD_LIBRARY_PATH=/tmp/hfs/houdini-8.0.517-linux_x86_64_deb_sid/dsolibusr/liblib

If I run /lib/libc.so.6:
GNU C Library stable release version 2.3.5, by Roland McGrath et al.
…
Compiled by GNU CC version 4.0.2 20050821 (prerelease) (Debian 4.0.1-6).
Compiled on a Linux 2.6.13 system on 2005-08-31.

It might be something to do with the dual-core chips and the graphics driver. There seem to be some comments on the nvidia forums about dual core chips. Some people recommend upgrading the video bios. Though, personally, that would scare me a bit.

On Windows at least, I know that the 8X.XX drivers are royally broken on multi-core machines. They recently released a new driver which may have the bugs fixed. However, I just checked their latest release notes and they give a method of turning off multi-threading on their driver which means that there are still known problems with it.

Another little suggestion to throw into the mix - when you've got weird-ass problems like this, you need to simplify, simplify. It's highly disturbing, this business with the NFS mounts. While you're debugging, lose all the stuff about your $HOME files being NFS mounts. It just adds to the potential problem points. Keep everything local, clean, new account, no existing preferences, no custom assets. Easiest way is to make a new account with the home directory local, and stick with that for debugging.

Cheers,

J.C.

Okay, Still no luck today. What I've tried: install houdini locally. Create local user. No environmental variables set except for default PATH. Source houdini_setup_bash just before launching houdini. Both 64bit and 32bit houdini initiate correctly. But:
- with the 64bit version: I can navigate nfs shares, but the path object crashes houdini when starting to draw in viewport.
- with the 32bit version: the path object works as expected, but I can't navigate to remote nfs shares. I can navigate to shares over nfs, shared from the local host however. Needs further investigation.

No difference with xfwm4 window manager.

The shares I can't read in the 32bit version are from an apple file server, and I see two entries in the automount directory: /net/god/Volumes/G-Raid/production (that file exists twice). Although the 64 bit version and other gnome-aps don't have a problem with that, it is odd at least.

Also, the 64bit houdini doesn't crash with the path object if I load a hip file that was originated in 32bit houdini and create a new path.

Mystery prevails. However, I'm probably getting 2 unrelated problems: the 64bit could be distro dependant, the 32bit problem could be due to inappropriate share.

I'm sure everybody was thinking I needed to go to a mental institution. But…

I found this article http://manage.talk.bmc.quintagroup.com/bmcblogs/blogs/blog-carl/steve-carl/apple-10.4.3-update [manage.talk.bmc.quintagroup.com]

Looks like apple nfs export is not compatible with 32bit nfs client. Thas was the reason houdini didn't see my share in 32bit mode.

As for the 64bit, that one seems harder to crack, as this still could be a distro or nvidia or PCI express or peculiar 64bit problem.

I thank you all for putting up with me, but I hope this thread will be of use to somebody in a similar situation (as I'm all for apple getting into our industry).

I wish I could get houdini running in 64bit, but I'll do some more research later.

Did you ever post your /tmp/crashlog_$USER file? There's likely not anything useful in there but just in case …

Well, I can't check right at this instance, but I did earlier and there was only one line wich had “crash” and the houdini version number in it. Is there any way I can switch on debugging mode or so to get more info?

D.

Ah right. No, that doesn't help. It just means that it went into a really bad state since it couldn't even get a log out. The strangest thing is that we can't seem to reproduce.

Well, to ease my mind, I tell myself I was pushing my luck with officially unsupported 64bit houdini, unsupported distro, new dual core and PCI express nvidia graphics. However, if I can help to run some tests, I would be happy to, so houdini could get wider adoption.