disable Cg shaders / trouble on FreeBSD

[Tulkhan]

Hi all,

I'm trying to build Planeshift (MMORPG that uses CS) on a FreeBSD box. 

 I've got CS compiled fine, however, the Nvidia Cg toolkit isn't available on FreeBSD,
and many CS shaders seem to require it. Planeshift exits with CS errors saying that
it couldn't load the glcg shader (even though CS was compiled without Cg support).

 Is there a way to "discourage" CS applications from using the Cg shaders?  I could
live with less fancy graphics.

Cheers,
-tulkhan

[res]

This is not an error in CS. The warning(it shouldn't be an error!) that glshader_cg could not be loaded is normal and due to CS being built without Cg support; however, all shaders are set up to fall back to versions that don't use Cg. The problem is probably something else.

[Tulkhan]

Thank you res, seems you're right.

The messages about the Cg shader do rather look like warnings:

crystalspace.pluginmgr.loadplugin:
  could not load plugin 'crystalspace.graphics3d.shader.glcg'


The actual problem seems to be this:


terminate called after throwing an instance of 'std::bad_alloc'
  what():  St9bad_alloc
Abort trap: 6


Is this a CS error message?

[res]

terminate called after throwing an instance of 'std::bad_alloc'
  what():  St9bad_alloc
Abort trap: 6

Is this a CS error message?

No. Looks more like an out-of-memory error. (Although it could occur from inside CS code.)

-f.r.

[Tulkhan]

Apparently it's an GCC error/exception that gets thrown if new() fails to allocate memory.

Raising the kernel per process data size limit from 512M to 768M makes the exception go away,
but it will still crash.  Surely there's something else going wrong that makes it allocate that much
memory in the first place? Interesting enough, this only happens if I load one of the new Planeshift
maps that use the new lighter2, the other maps do fine.

GDB says:


(gdb) where
#0  0x2849e20b in pthread_testcancel () from /lib/libpthread.so.2
#1  0x2848c73d in sigaction () from /lib/libpthread.so.2
#2  0x28485c95 in pthread_kill () from /lib/libpthread.so.2
#3  0x28485514 in raise () from /lib/libpthread.so.2
#4  0x2867173c in abort () from /lib/libc.so.6
#5  0x2852e7cb in __gnu_cxx::__verbose_terminate_handler ()
   from /usr/lib/libstdc++.so.5
#6  0x28532ba5 in __cxxabiv1::__terminate () from /usr/lib/libstdc++.so.5
#7  0x28532be2 in std::terminate () from /usr/lib/libstdc++.so.5
#8  0x28532b12 in __cxa_throw () from /usr/lib/libstdc++.so.5
#9  0x28579992 in operator new () from /usr/lib/libstdc++.so.5
#10 0x285798bd in operator new[] () from /usr/lib/libstdc++.so.5
#11 0x29d57329 in CS::Plugin::csOpcode::Opcode::AABBQuantizedNoLeafTree::Build
    () from /local/work/cs/lib/crystalspace-1.2/csopcode.so


though I'm unsure whether I'm on the right track here. Would a debugging-
enabled CS build help?

[res]

Raising the kernel per process data size limit from 512M to 768M makes the exception go away,
but it will still crash. 

What crash is that? It may possibly be another issue you're hitting there.

Surely there's something else going wrong that makes it allocate that much
memory in the first place?

CS is a bit of a memory hog sometimes
But I think there's work in PS going on trying to reduce the memory usage.

Interesting enough, this only happens if I load one of the new Planeshift
maps that use the new lighter2, the other maps do fine.

But only a subset of the maps are not lighter2-lit. For example, some of the bigger maps, such as hydlaa plaza, are lit by lighter2.  To truly say whether lighter2 lighting or the sheer size of a level is responsible for the memory usage you'd have to compare an "old" and a lighter2 version of the same level(s).

though I'm unsure whether I'm on the right track here. Would a debugging-
enabled CS build help?

It would be helpful if you want to start "real" debugging and you have to inspect local variables or, function parameters (since they may be removed due optimizations from the compiler or have seemingly bogus values) or want to follow the execution of an algorithm (since the compiler may rearrange bits of code for optimization).

[Tulkhan]

Raising the kernel per process data size limit from 512M to 768M makes the exception go away,
but it will still crash. 

What crash is that? It may possibly be another issue you're hitting there.

With the raised data size limit, I get a nondescript Bus Error.

Surely there's something else going wrong that makes it allocate that much
memory in the first place?

CS is a bit of a memory hog sometimes
But I think there's work in PS going on trying to reduce the memory usage.

I see Increasingly, I get the nagging feeling that there's nothing wrong
and it's just really using that much memory (and I have "only" 1G RAM *sigh*).

But only a subset of the maps are not lighter2-lit. For example, some of the bigger maps, such as hydlaa plaza, are lit by lighter2.  To truly say whether lighter2 lighting or the sheer size of a level is responsible for the memory usage you'd have to compare an "old" and a lighter2 version of the same level(s).

I can run the Linux version (FreeBSD can run Linux binaries), although the new 0.3.020 release
is very unstable for me, which is the reason for me trying to build a FreeBSD native client from SVN),
so I was able to compare the memory usage as reported by top(1):

Hydlaa plaza, lighter2 map from 0.3.020 release: 708M,
old map from 0.3.019 release: 494M. Quite a difference, I'd say

though I'm unsure whether I'm on the right track here. Would a debugging-
enabled CS build help?

It would be helpful if you want to start "real" debugging and you have to inspect local variables or, function parameters (since they may be removed due optimizations from the compiler or have seemingly bogus values) or want to follow the execution of an algorithm (since the compiler may rearrange bits of code for optimization).

Right.  Well, I'll try a debugging build when I've got some free time.  Or just get another
gig RAM

[Scorc]

 Hello!
 I've played with 1.4 branch for some days, and somehow walktest, tutos and other CS apps started to show this message dialog at startup (if I press OK it popups again):

Fatal Error!

crystalspace.plugin.load:  Couldn't load plugin with class 'crystalspace.graphics3d.shader.combiner.glcg'!

 I've compiled CS 1.9 from CVS snapshot, nothing changed. But win32 version in wine still work though
 Since Cg-toolkit isn't available natively on FreeBSD, is there a way to disable calls to this library?
 Thanks!

[Scorc]

Still confused, here is an additional info:

nvidia-driver-195.36.15
nvidia0: <GeForce 8500 GT> on vgapci0

%gcc -v
Using built-in specs.
Target: i386-undermydesk-freebsd
Configured with: FreeBSD/i386 system compiler
Thread model: posix
gcc version 4.2.1 20070719  [FreeBSD]

[Scorc]

With help of irc it was fixed in svn
Although some maps without shaders (where they are supposed to be) look weird, cs dev proposed a workaround: you can use './walktest castle-staticlit'