Crash to poweroff with pview

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,

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.


Ah, so this can not be a bug in either my exporter or Panda? Whew, what a relief.
I’m getting this error when changing my load-display to tinydisplay:

:display: Unable to load: /usr/local/panda/lib/ undefined symbol: XAllocSizeHints

nm’ing gives this:

$ nm /usr/local/panda/lib/ | grep XAllocSizeHints
                 U XAllocSizeHints
/usr/local/panda/lib/ undefined symbol: XAllocSizeHints

Hmm, this symbol is defined in 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. :frowning:

I knew that OpenCV was giving problems, but I must have missed the problem with PNG. What’s the trouble?


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>

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.)


Try moving the lines:

#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>

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>

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, 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.


Ah, thats great. What shall we do about 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.


Yeah, I tried putting the hack in config_pnmimagetypes.cxx, did no good.
I also tried putting it in contextSwitch.h, and it still didn’t work! :frowning:

EDIT: I just had an idea. Let me put an #error in setjmp.h, and lets see what kind of traceback the compiler gives.

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.


OK, I think I’ve got it. It required a few more places. I checked in some fixes.

Try updating and see if that builds for you.


Actually, upon closer inspection, it did work. It just got a little further but threw the same error but at a different place.

EDIT: Oh, just noticed your other post. Let me try again.

David, you’re the best! It works! :slight_smile:

Thanks alot!