I didn’t exactly know where to put it, so I put it here. Please move it if you know a better place for this thread.
Sometimes, when pviewing a collada file of mine (then I usually immediately press C followed by L), I can see my model in a flash, and then my computer instantly powers off (with a loud click, but I think thats my HDD). Not always though, in most cases it just works. I tried various models but sometimes it just crashes.
When I power my computer back on, I get nothing – no overheat warning, no kernel dump, no traceback. I’m clueless. Can anybody give me some hints here?
Btw. am running the head of the CVS tree. I don’t think its related to my exporter, since I actually can view the model for a small millisecond,
Thanks in advance,
pro-rsoft
PS. I can grab a video camera and make a recording of what happens, if someone wants to see.
PPS. This is a brand new laptop so I doubt that it’s old age or too old GPU or so.
If the machine powers all the way off, it sounds like a hardware fault to me. But, it could also be a driver crash. Either of these is a common problem with a brand new computer.
Since you’re running on the CVS head, try running tinydisplay instead of pandagl. If it still crashes there, it proves it’s not a driver crash.
Hmm, this symbol is defined in libX11.so. So, it looks like your Linux distro requires an explicit linkage with X11, while mine for some reason does not. I just added the appropriate ppremake rules to dtool and panda to link tinydisplay with X11, so next time you pick and build up the latest CVS trunk, see if it works.
Just did a clean checkout, and tinydisplay worked fine, thanks.
TinyGL seems to give some weird artifacts here, but other than that it works great!
I’ll see if I get the crash again – if not, I’ll just blame nvidia for providing bad drivers.
PS. PNG and OpenCV are both still broken at CVS, so I had to compile without them. I can live without OpenCV, but it’s kind of a pain not to be able to use png textures.
Sorry for the late reply, I had to rebuild panda with HAVE_PNG to get the error again.
I stripped out the unrelated warnings:
g++ -ftemplate-depth-30 -c -o Opt3-Linux/pnmimagetypes_pnmimagetypes_composite1.o -I. -I/home/pro-rsoft/Projects/panda3d/panda -I../express -I../linmath -I../pandabase -I../pipeline -I../pnmimage -I../putil -I/usr/local/panda/include -I/usr/include/python2.5 -g -O2 -fPIC pnmimagetypes_composite1.cxx
In file included from /usr/include/png.h:387,
from pnmFileTypeJPG.h:35,
from config_pnmimagetypes.cxx:22,
from pnmimagetypes_composite1.cxx:1:
/usr/include/pngconf.h:317: error: expected constructor, destructor, or type conversion before ‘.’ token
/usr/include/pngconf.h:318: error: ‘__dont__’ does not name a type
make[1]: *** [Opt3-Linux/pnmimagetypes_pnmimagetypes_composite1.o] Error 1
make[1]: Leaving directory `/home/pro-rsoft/Projects/panda3d/panda/src/pnmimagetypes'
make: *** [pnmimagetypes] Error 2
Conflicting lines at pngconf.h:
# ifdef _SETJMP_H
/* If you encounter a compiler error here, see the explanation
* near the end of INSTALL.
*/
__png.h__ already includes setjmp.h;
__dont__ include it again.;
# endif
This means setjmp.h was included before png.h was included. Png doesn’t like that for some reason. Since panda’s JPG reader needs setjmp.h, but wants to make sure png.h gets included first, pnmFileTypeJPG.h has this workaround:
#ifdef HAVE_PNG
// If we are going to be including png.h (in the unrelated file
// pnmFileTypePNG.h), be sure to include it before including setjmp.h.
// Ugly hack due to png weirdness with setjmp.
#include <png.h>
#endif
Though, Panda3D also includes setjmp.h somewhere else, at a place where it doesn’t add this workaround first. It might also be including some other header file which on its turn includes setjmp.h.
I haven’t been able to locate the other Panda3D file that includes setjmp.h (so I could add this workaround to that file as well), but maybe you are aware of any recent changes to files that used setjmp.h? (It worked well before. That might however be related to system updates on my machine or so.)
#ifdef HAVE_PNG
// If we are going to be including png.h (in the unrelated file
// pnmFileTypePNG.h), be sure to include it before including setjmp.h.
// Ugly hack due to png weirdness with setjmp.
#include <png.h>
#endif
in pnmFileTypeJPG.h up to just below the line:
#include "pandabase.h"
This will be the minimal set of includes. If that’s still not high enough, we’ll have to play games with Sources.pp to make png compile separately.
Nop, just tried it but that doesn’t do any good.
Although the pnmFileTypeJPG.h is not the problem. It was just to name an example of a file that works around the png ugliness fairly well.
The problem is actually there’s some far-far-away panda file somewhere that also needs setjmp.h, but doesnt actually include this ugly workaround. Most likely, a file that has recently been changed. Maybe texture.h or so? (a wild guess)
Well, it can’t be that far away. See the include stack in the compilation error?
In file included from /usr/include/png.h:387,
from pnmFileTypeJPG.h:35,
from config_pnmimagetypes.cxx:22,
from pnmimagetypes_composite1.cxx:1:
So the actual error is discovered when compiling pnmFileTypeJPG.h. It must have been one of the includes that got picked up in one of the other .cxx files in this directory, one of the ones included by pnmimagetypes_composite1.cxx.
OK, try this, then. In config_pnmimagetypes.cxx, before any of the other includes at all, insert the lines:
#include "pandabase.h"
#ifdef HAVE_PNG
// If we are going to be including png.h (in the unrelated file
// pnmFileTypePNG.h), be sure to include it before including setjmp.h.
// Ugly hack due to png weirdness with setjmp.
#include <png.h>
#endif
This is really, really before anything else gets included. (We do need to include pandabase.h, though, to pick up the HAVE_PNG definition.)
I found the other reference to <setjmp.h>. It’s in panda/src/pipeline/contextSwitch.h, which gets picked up when you’re compiling with SIMPLE_THREADS.
But I’m not sure that putting a reference to <png.h> in that file is a great idea. That might introduce an early dependency on libpng.so, which could play havoc with the link commands.
Boy, I wonder what png.h is doing that requires it to muck about inside setjmp? How very unfriendly of it.
This is what the INSTALL file of libpng says about it:
The suggestion it makes to comment out the lines in pngconf.h doesn’t seem like an option, we can’t make panda edit system header files. Maybe, we can #undef _SETJMP_H or so before we include png.h, but that would be even uglier.
EDIT: Whoops, no, that gives redefinition errors of the stuff in that file, of course.
Looking at contextSwitch.h, it will only occur on non 32-bits intel systems and if the user doesnt have HAVE_UCONTEXT_H defined. No idea what that is though.
The “cexcept interface” referred to is just a very thin wrapper around setjmp. It’s not at all clear how using this is supposed to solve this compilation problem, since it still needs to include setjmp.h.
In any case, we use setjmp for a different purpose than exception handling–we use it to implement context switching for the implementation of SIMPLE_THREADS. (It’s only used if the OS doesn’t provide ucontext.h, which is a better mechanism actually designed for context switching.)
From some other comments in libpng, I think their unfriendly hack is designed to work around problems on some systems with multiple different versions of setjmp.h installed in different places. Well, whatever. I think we need to work around this with more hacks like we already have.
Did you try my suggestion about config_pnmimagetypes.cxx? If that works, great; if it doesn’t work, then I guess we’ll have to resort to putting a reference to png.h within contextSwitch.h. Chances are actually pretty good that it won’t cause any problems there.
What the? It’s actually a python header thats including setjmp.h first…
In file included from /usr/include/python2.5/pyfpe.h:130,
from /usr/include/python2.5/Python.h:151,
from ../pipeline/thread.h:28,
from ../pipeline/pipelineCyclerTrivialImpl.h:22,
from ../pipeline/pipelineCyclerBase.h:39,
from ../pipeline/pipelineCycler.h:19,
from ../pipeline/cycleDataReader.h:21,
from animInterface.h:22,
from animInterface.cxx:15,
from putil_composite1.cxx:1:
/usr/include/setjmp.h:25:2: error: #error "blahblah"
Well, OK, but that’s just in putil, which has nothing to do with png. The only one we care about is the one that eventually includes png.h.
Why didn’t the config_pnmimagetypes.cxx attempt work? Try the #error trick with that workaround in place, while you compile only the pnmimagetypes directory. We need to figure out who’s including setjmp.h before png.h. Putting the workaround at the top of config_pnmimagetypes.cxx should have worked, because there’s no file that gets included before that one, in that directory.
