Unregistered TypeHandle problem on Mac

Hi guys,

I’m this close to getting makepanda work on Mac, but suddenly something strange comes in between:
(in the genpycode step)

Importing code library: libpanda
Attempt to reference unregistered TypeHandle!
Registered TypeHandles are:
  1 Filename
  2 PandaSystem
  3 TypedObject
    5 TypedReferenceCount : TypedObject, ReferenceCount
      6 VirtualFile : TypedReferenceCount
        7 HTTPChannel : VirtualFile
        36 VirtualFileComposite : VirtualFile
        40 VirtualFileSimple : VirtualFile
    32 Datagram : TypedObject
    37 VirtualFileMount : TypedObject
      38 VirtualFileMountMultifile : VirtualFileMount
      39 VirtualFileMountSystem : VirtualFileMount
    41 TypedWritable : TypedObject
      42 PandaNode : TypedWritable
  4 ReferenceCount
    5 TypedReferenceCount : TypedObject, ReferenceCount
      6 VirtualFile : TypedReferenceCount
        7 HTTPChannel : VirtualFile
        36 VirtualFileComposite : VirtualFile
        40 VirtualFileSimple : VirtualFile
    34 NodeReferenceCount : ReferenceCount
  8 long
  9 int
  10 uint
  11 short
  12 ushort
  13 char
  14 uchar
  15 bool
  16 double
  17 float
  18 string
  19 int*
  20 short*
  21 char*
  22 bool*
  23 double*
  24 float*
  25 void*
  26 pvector
  27 ov_set
  28 pdeque
  29 plist
  30 pmap
  31 pset
  33 Namable
  35 TextEncoder
Assertion failed: (pnode != (TypeRegistryNode *)NULL), function record_derivation, file dtool/src/dtoolbase/typeRegistry.cxx, line 173.

I’ve been looking for weeks on how to solve this, unfortunately without any change. I can’t remember changing anything that important so I have no idea where to look. Maybe you guys can help me out on this one?

Thanks in advance,

This means that someone referenced a TypeHandle before init_type() had been called on that TypeHandle. It’s hard for the Panda runtime to tell which was the offending TypeHandle, but you might be able to figure it out by looking at the stack trace in gdb.


Thanks, I’m getting this:
(Does this mean MouseRecorder has a non-registered typeHandle or so?)

#0  0x95e0db9e in __kill ()
#1  0x95e0db91 in kill$UNIX2003 ()
#2  0x95e84ec2 in raise ()
#3  0x95e9447f in abort ()
#4  0x95e86063 in __assert_rtn ()
#5  0x007483fa in TypeRegistry::record_derivation ()
#6  0x017ff9c6 in register_type ()
#7  0x01803fab in PandaNode::init_type ()
#8  0x01804107 in MouseRecorder::init_type ()
#9  0x017fecf7 in ConfigureGetConfig_config_recorder::config_func ()
#10 0x03c73864 in __static_initialization_and_destruction_0 ()
#11 0x8fe12e76 in __dyld__ZN16ImageLoaderMachO18doModInitFunctionsERKN11ImageLoader11LinkContextE ()
#12 0x8fe0e723 in __dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextEj ()
#13 0x8fe0e6b5 in __dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextEj ()
#14 0x8fe0e809 in __dyld__ZN11ImageLoader15runInitializersERKNS_11LinkContextE ()
#15 0x8fe02202 in __dyld__ZN4dyld15runInitializersEP11ImageLoader ()
#16 0x8fe0bb1d in __dyld_dlopen ()
#17 0x95da84e2 in dlopen ()
#18 0x001aeb5a in _PyImport_GetDynLoadFunc ()
#19 0x001a1774 in _PyImport_LoadDynamicModule ()
#20 0x0019de7e in _PyImport_IsScript ()
#21 0x0018d806 in PyEval_EvalFrameEx ()
#22 0x0018d9e8 in PyEval_EvalFrameEx ()
#23 0x0018f45b in PyEval_EvalCodeEx ()
#24 0x0018da85 in PyEval_EvalFrameEx ()
#25 0x0018d9e8 in PyEval_EvalFrameEx ()
#26 0x0018f45b in PyEval_EvalCodeEx ()
#27 0x0018f548 in PyEval_EvalCode ()
#28 0x0019f4e5 in PyImport_ExecCodeModuleEx ()
#29 0x0019fa0c in PyImport_ExecCodeModuleEx ()
#30 0x001a0891 in PyImport_ReloadModule ()
#31 0x001a0a80 in PyImport_ReloadModule ()
#32 0x001a1070 in PyImport_ReloadModule ()
#33 0x001a11ea in PyImport_ImportModuleLevel ()
#34 0x0018442d in PyAST_FromNode ()
#35 0x0011fd3d in PyObject_Call ()
#36 0x00188b15 in PyEval_CallObjectWithKeywords ()
#37 0x0018cc21 in PyEval_EvalFrameEx ()
#38 0x0018f45b in PyEval_EvalCodeEx ()
#39 0x0018f548 in PyEval_EvalCode ()
#40 0x001a69ec in PyErr_Display ()
#41 0x001a724b in PyRun_StringFlags ()
#42 0x001a8ce6 in PyRun_SimpleStringFlags ()
#43 0x001b3931 in Py_Main ()
#44 0x00001fca in main ()

OK, that’s really weird. That seems to mean that PandaNode::init_type() failed (it was the last init_type() in the stack trace), which would mean that one of the types whose get_class_type() method was called in PandaNode::init_type() hadn’t yet been initialized.

But there’s only TypedWritable and ReferenceCount, and both of those are initialized just before.

It might be something hiding in CData::init_type() or Down::init_type() or Up::init_type(), and these are harder to trace because they’re template classes, but another thing makes me thing it’s actually PandaNode itself: in the list of already-registered TypeHandles that gets printed, it shows both TypedWritable and ReferenceCount, but doesn’t list PandaNode–which means that register_type() hadn’t yet been successfully called on PandaNode, which seems to imply that the crash happened in there.

Could it be some crazy race condition? Are you compiling with threads enabled, for instance? Seems a stretch.

You might need to debug this by adding print statements into PandaNode::init_type(). For instance, print out the values of TypedWritable::get_class_type() and ReferenceCount::get_class_type() just before they are passed into register_type(), and make sure they’re not TypeHandle::none.

Then track it down further, for instance inside register_type(). The error message at the bottom means that someone passed a TypeHandle::none into record_derivation(), so you need to figure out where that none came from and how it got there.


Thanks for your reply. I’ll investigate it further (when I have time) and will see if I can isolate it.
I’m compiling with makepanda which (currently) does not enable HAVE_THREADS, so threading should be disabled.
It’s still odd though, because I can’t remember I changed much, it worked fine before. All I can remember I did was checkout a new copy of cvs, adding some code to executionEnvironment.cxx, and add instructions to make a .so except for just a .dylib.
Oh, by the way. pview works fine.
Anyways, I’ll spam the code with debug messages and see if I can narrow it down.

It could be some build state error–before you spend too much time researching it, make sure you’ve completely scrubbed all your old builds and have generated a new, clean build from scratch.


I tried that several times, even with a clean CVS checkout. I just finished another build (after removing all panda libs I somewhere had) but with same problem…

This is giving me headaches, I’ll try again later.

PS. PandaNode actually was already in the list:

42 PandaNode : TypedWritable

and it still confuses me why pview works fine while genpycode does not…

Wait, I found something very odd.
I just removed all my .so files from my built dir (leaving me with just .dylib files), and changed the extension in extensions_native.py to .dylib, and genpycode just worked. How strange?
If I recall correctly I used the exact same build command that ppremake uses to build an .so bundle out of a .dylib. But still I can not see how this could possibly be related?
The only difference is that ppremake uses a different genPyCode setup than makepanda does, I believe.

Hmm, well, I can see how this could be related. If the same symbol names appear in the .so as in the .dylib, then importing both of them could cause symbol names to be duplicated in your namespace, which might conceivably mean that TypedWritable::init_type() might call one symbol, while TypedWritable::get_class_type() might call the other one (which hasn’t yet been initialized). Stranger things have happened in the past.

It’s even more likely when you’re talking about template classes, which is what we’re looking at now that you’ve pointed out that PandaNode was in the list.

I’d look very closely at the build commands and make sure you haven’t missed something small.


Ah, that makes sense. Thanks. Upon a quick look I didn’t see anything suspiciously different, but I’ll look further into this, now I know where to look.

Ahhgr, I am stucker than stuck on this.
I got everything to work fine, except for this. I’ve tried all different kinds of combinations with the build command, googled for hours to see whether someone else might have a related problem, compared it to ppremake, but can’t seem to find a solution. The only possible problem I can think of is that in ppremake, somehow either the .so or .dylib is out of the library path so it gets not loaded. But if that would be the problem I wouldn’t have a clue how to fix that.
How come can’t we just use .dylibs?

I dunno. If you can make it work with just .dylibs, that would be fine.


Hmm, I guess that would work, but then the extension_native_helpers.py will have to be using the .dylib for makepanda, but the .so when using ppremake – Should I let makepanda replace the var in that file on compile time or so? Sounds like a hacky solution though.

No, we should use the same solution on both build systems.

I don’t know why ppremake builds both .dylib and .so files now; the person who devised this part of build system is no longer available. I assumed it was necessary for OSX for some reason. If you can prove otherwise, great; we can make similar modifications to the ppremake scripts to build Panda in the same way.


Okay, I’ll set up a build environment for ppremake on OSX and will try to modify it so it will work with just .dylibs.

It seems to work fine if I just remove this line from Config.OSX.pp:

#define BUNDLE_EXT .so

Removing that line just tells ppremake not to build any .so bundles at all. I really don’t know why it had that in the first place.

Hmm, this went fast. First time for me a ppremake build on OSX really went seamless.
It worked great with the BUNDLE_EXT line removed and the .so changed to .dylib in extension_native_helpers.py. No further complications at all or so.
It even worked with my executionEnvironment.cxx patch (after adding an include line to <mach-o/dyld.h>).

Should I commit these changes?

PS. Oh, when doing this, you also need to use DYLD_LIBRARY_PATH instead of LD_LIBRARY_PATH.

Hmm, sounds promising. Let’s try committing it, and we’ll keep an eye out for problems over here.


Okay, I committed the changes. ([1] [2] [3]).

Please let me know if you run into any problems.