Ah, progress it seems!
I’m building a Windows version now (I’m afraid that I’d deleted the previouis versions)–I’ll post again once I have a result to report, I intend!
Ah, progress it seems!
I’m building a Windows version now (I’m afraid that I’d deleted the previouis versions)–I’ll post again once I have a result to report, I intend!
All right, my report:
Changing the value of “per_platform” wherever it appears in that xml file does indeed get me past the relevant error, but the program still doesn’t run (and I did restore that “Test” module, so it shouldn’t be hitting that issue). The log file looks very like that which I had previously when building without “-s”, including the odd white-space at the start of the file.
Here’s the new log, white-space omitted:
Setting working directory: C:\Users\user\AppData\Local\Panda3D\start Command line: "C:\Program Files (x86)\LevelPrototype\panda3d\cmu_1.9\p3dpythonw.exe" "C:\Program Files (x86)\LevelPrototype/panda3d/cmu_1.9/panda3d.cmu_1.9.win_i386.mf" "000000D0" "000000DC" "0" notify: onpluginload notify: onauth notify: ondownloadbegin notify: ondownloadcomplete notify: onready Created splash window 00060912 Loaded image: C:\Program Files (x86)\LevelPrototype/images/download.png notify: onpythonstop finish_instance: 00CF1D08 Assigning 00CF1D08->log_pathname = C:\Users\user\AppData\Local/Panda3D/log/LevelPrototype.log
So, while the per-platform issue does seem to be a stumbling block, it looks as though it’s not the only one…
Again, it looks as though it’s starting correctly, and then somehow deciding that it’s done.
Yes, that looks like it’s exiting normally. This is the runtime log file; there should be either another log file or, if you ran it from the command line, command-line output from the application itself. Could you post that as well?
One frequent cause of this type of issue is that the run() call is hidden under a name == “main” check, which does not hold in the runtime environment. Please make doubly sure that you have no such check.
I take it that you mean “p3dcore.log”? If so, the relevant log from a recent Linux build (one in which I had set all instances of “per_platform” in the xml file to 0, as suggested, I believe) follows; I don’t recall noticing the file on Windows, but may have just missed it–I can get that version for your tomorrow I believe, if you want it.
Interestingly, I just realised that neither the runtime log nor this one seems to include that driver error that we were seeing previously–I don’t know whether that’s because it’s not getting that far, or because the runtime-distributable being used here has some change that fixes the issue.
One line towards the end strikes me: “application shares main object”–is that a potential issue?
I don’t use such checks–it’s something that I never learned (I honestly don’t even know what it’s intended purpose is). Here’s a rough outline of how my “main” file (“GameCore.py”, to which I linked you in PM) is structured, including the “run” command:
from pandac.PandaModules import loadPrcFile, loadPrcFileData loadPrcFile("Adventuring/game.prc") # - Panda-related importations, including DirectObject and DirectStart import os, sys, math, random, types # - My own importations: external modules like KeyMapper, followed by game-specific modules. # This is used by GameSaver @staticmethod def isSubclass(name, classToCheck): if name == "NoneType" or name == "function" or name == "instancemethod": return False return issubclass(eval(name), classToCheck) # This class controls the flow of the game, as well as handling events class GameFramework(DirectObject): # - Class code here... # Let the game begin! gameFramework = GameFramework() run()
(I realise that rdb is likely not around as of the time of my posting this, but I’d rather leave it here early than risk forgetting later.)
I have a bit more information, perhaps.
I decided to have a shot at using the latest (as of earlier today, my time) SDK version of Panda from GitHub–which, as has been pointed out, shouldn’t have an effect, but seemed worth trying, and I mention it here just in case it’s relevant–and as a result attempted another build.
This time I noticed something in the output of packp3d_dev. It occurs early, and flashes by very quickly indeed, so I may well have missed it previously; I ended up catching it by redirecting the console output to a text file. Here is the text in question:
There are some missing modules: ['Adventuring.footsteps', 'BinsAndTags', 'Combat', 'Common', 'CommonValues', 'Conversation', 'Cutscene', 'GameObject', 'Inventory', 'Level', 'Menus', 'NPC', 'Navigation', 'OptionsMenu', 'Player', 'Town', 'Translation', 'panda3d.bullet', 'panda3d.core']
“Adventuring.footsteps” is understandable–that’s the result of something being accidentally left in, I believe–but all of the others (presumably including “panda3d.core”) are important–it seems somewhat odd that it’s not finding them.
More oddly, I would expect all of my own modules there to start with “Adventuring.”, as in the case of “footsteps”; a quick search of my code using “BinsAndTags” as an example found only importations with the “Adventuring.” prefix, like so: “from Adventuring.BinsAndTags import *”.
I have seen posts mentioning that the inclusion of “panda3d.core” in such messages is the result of a bug–but I believe that I’ve also seen at least one such indicate that said bug was fixed and would be corrected in the next release–since I’m using a dev. version, would I not perhaps have that fix?
As to my own modules, all of those mentioned should be within the directory given to packp3d–or rather, a subdirectory of that directory. To be specific, I build from a directory (simply named “P3D”) outside of my game’s directory, and point packp3d to the appropriate directory via the “-d” parameter. The hierarchy looks something like this:
My Game Projects | |----- P3D (from which I build) | |----- LevelPrototype (the game directory) | | | |----- Adventuring (in which the above-mentioned modules should be found)
I note that it isn’t complaining about modules placed within the “LevelPrototype” directory, but within their own folders instead of the “Adventuring” folder, such as GameSaver or KeyMapper.
Possibly arguing in part against this is that I attempted a minimal test–albeit asking it for the same dependencies: Bullet, MorePy, and OpenAL–it too crashed shortly after opening a black window–but then I’ve had problems with the runtime on this computer (albeit not properly tested), I think, and the fact that it managed a black window (even if it didn’t show anything else) does seem to indicate that Panda is being found, despite there being a similar message in the output of packp3d_dev during building, albeit only including “panda3d.core” this time, I believe.
So, I think that it’s time to bump this thread, especially given that ninth has reported a similar-seeming issue here.
Has this been looked-into any further?
This is actually the first time I’ve noticed the crash ninth reported - and I’ve been using the Windows 7 x64 build for quite a while. I’ll look into that first.
I’d like to re-open this, as I’m still not managing to produce an installable build.
I’m still using the versions of packp3d_dev and pdeploy_dev that I was using when I first opened this thread, I believe. I do thus still have the “per-platform” issue, but that’s easily corrected while testing, and I gather that this should be fixed in the versions of packp3d and pdeploy released for 1.9.
I’ve performed a few more experiments using a very simple test-program (all under Ubuntu 13.10), summarised below:
What I’ve been doing:
panda3d packp3d_dev.p3d -o CompilationTest.p3d -d ../CompilationTest/ -r morepy -e dat -n ogg and panda3d pdeploy_dev.p3d -P linux_amd64 -a ian.eborn -A "Ian Eborn" -s -N "CompilationTest" -v 2 CompilationTest.p3d installer
My results thus far:
Finally, I have a question:
Looking at the directory created on installation of my test-program, I don’t see any files that seem to be specific to that program–no “CompilationTest” -.p3d, -.so, or -.mf, for example–which prompts me to wonder whether the problem might not be that my program simply isn’t being included in the installation, and the execution thus having nothing to do after loading Panda and just exiting.
However, I could simply be missing the relevant files. So where should I be looking, and what should I be looking for?
A bit more information, perhaps: I created two builds of the same simple test-program, one using Panda 1.8 and the other using 1.9. Both were Linux-64 builds, and built under Ubuntu 13.10. I then ran both (after fixing the per-platform issue in the 1.9 version’s “contents.xml”) and compared their log files.
To start with, the version built using 1.8 ran successfully, while the version built using 1.9 didn’t.
The log files differ somewhat, naturally–it looks as though 1.9 might produce a bit more output than 1.8, for one thing.
Otherwise, two differences stand out to me:
[/b]Towards the beginning, there’s a section that appears to be concerned with checking the status of the various packages (morepy and Panda itself, in this case). The 1.9 version appears to have quite a bit more output here than the 1.8 version (including the warnings about “per_platform disagreement” that I believe have already been mentioned in this thread). However, I’m finding it difficult to tease apart the differences, and don’t know which, if any, are important.
Here’s the relevant section of the log file from the 1.9 version, with a bit of context before and after:
send_notify(onauth) No longer current: panda3d read contents.xml, max_age = 5, expires in 0 s Migrating panda3d from platform "" to platform "linux_amd64" _per_platform for panda3d = 0 Warning! per_platform disagreement for panda3d! report_package_info_ready: panda3d panda3d: asked for seq 2, we have seq expiring contents.xml for https://runtime-dev.panda3d.org/ morepy: asked for seq 2, we have seq expiring contents.xml for https://runtime-dev.panda3d.org/ _per_platform for morepy = 0 Warning! per_platform disagreement for morepy! report_package_info_ready: morepy panda3d: asked for seq 4, we have seq expiring contents.xml for https://runtime.panda3d.org/ _per_platform for panda3d = 0 Warning! per_platform disagreement for panda3d! report_package_info_ready: panda3d panda3d: asked for seq 2, we have seq expiring contents.xml for https://runtime-dev.panda3d.org/ morepy: asked for seq 2, we have seq expiring contents.xml for https://runtime-dev.panda3d.org/ Beginning install of 0 packages, total 0 bytes required (43494343 previously downloaded). send_notify(ondownloadbegin) send_notify(ondownloadcomplete)
Towards the end of the logs, when–if I read this correctly–the application is being started:
notify: ondownloadcomplete notify: onready application shares main object notify: onpythonload P3DSplashWindow::set_visible(0) notify: onwindowopen notify: onpythonstop
notify: ondownloadcomplete notify: onready Reading splash file image: /usr/lib/compilationtest/images/download.png notify: onpythonstop
where do I get packp3d dev and pdeploy dev?
I believe that I got them from http://runtime-dev.panda3d.org/–however, I don’t see them listed there at the moment; perhaps they’ve been removed.
… Has anyone looked into this recently?
I don’t mean to be a pest by bumping this as I have been, but this issue is somewhat stalling the development of my project, and seems to me like a matter of concern in general–after all, if it’s happening on my machine, it’s possible that there will be other machines on something similar occurs.
Development is stalling because, while I can continue to work, I’m at a stage at which I very much want feedback on my game, which means distributing it to others. (Indeed, I have a test-scenario pretty much ready, I believe.) Specifically, I feel that I’m close to moving on to developing content–actual puzzles, levels, story and so on–but want to test my gameplay and deal with any serious issues before I do so. More generally, having next to no access to external feedback feels like a handicap to me.
I could distribute the .p3d file, I suppose, but outside of the Panda3D community that means asking people to separately download and install the run-time, which I fear may result in fewer people trying the prototype, and thus less feedback. (I’ll confess that I don’t think that I’ve tried the web-player option; it’s not an approach that I tend to favour, personally.) On the other hand, if the installers work for others then I could just build, upload, and hope–but I’m not at all comfortable with distributing builds that I haven’t tested, especially as I have a history of missing small things between development version and distributable build.
Perhaps more worryingly, if this isn’t addressed then this problem might remain until the game’s completion, potentially leaving me with not only the problem of testing my builds, but also that of having an issue present in my game that could cause it to simply fail for some users, with no apparent means of fixing it.
(In case anyone is wondering why I don’t simply develop for Panda 1.8, my project doesn’t work under that version, as it lacks features in its integration of Bullet that my project employs (including the use of bitmasks in filtering at least certain types of collision), if I recall correctly.)
Since I don’t know what’s relevant and what’s not, I’m currently resorting to dumping what results I’m managing to come up with here in the hopes that somewhere amongst them is a clue as to what’s going on.
Speaking of which, another experiment:
This time I compared the log files produced by the .p3d- and installed- versions of the 1.9 build. From what I see, the .p3d version outputs its log to “p3dcore.log”, while the installed version outputs to “.log”, where “” is the name of the game. They do seem to be comparable, but if I’m missing any logging please let me know.
As before, the .p3d version runs, but the installed version does not.
Oddly, while the log files do seem to be comparable, they also differ to a surprising degree, both in content (which is somewhat expected, given that one represents a successful run and the other an unsuccessful run) and in formatting (which seems a little more odd).
Some points that stood out to me:
All right, I think that I may have chased down the problem, at least in part–but I don’t know what to do about it.
First of all, I note that this doesn’t just affect packp3d and pdeploy–it seems to be more general than that, causing any attempt to run a .p3d file through the newly-built runtime distributable to fail. I’m guessing that I was previously able to run .p3d files as a result of having installed a version of the runtime distributable that didn’t have this issue.
I’ve been tinkering–primarily by adding simple debugging output lines, but occasional commenting-out of lines–with the source code for the runtime/runtime-distributable (I’m honestly not sure of which is running the relevant code, so I’ve been rebuilding both; I imagine that it’s the distributable, however), and seem to have found a likely candidate.
It is, however, entirely possible that I’ve found an issue that I myself introduced somehow.
The proximal cause of the issue seems to be “rt_terminate” being called in “p3dSession.cxx”, thus prompting a halt.
This appears to be a response to a broken XML message being sent to “read_xml” in “binaryXml.cxx”. Specifically, that method is finding the “xnode” returned from “read_xml_node” to be NULL; this appears to be caused by the very first read in “read_xml_node” producing a “gcount” value different to “sizeof(value_length)”–specifically, “gcount” appears to be coming out as 0, which, from what I’ve gathered, indicates that no characters were read.
Now, “read_xml” is called from a few places, but, based on some experimentation, I think that the offending party is “rt_thread_run” in “p3dSession.cxx”. As far as I see, this appears to be happening on the first attempted reading. This would seem to imply a problem with “_pipe_read”, and thus “r_from”–but I fear that I don’t know the system well enough to be confident of what to make of that.
Hmm, if it really is a bug in the binary XML reader, then you could switch over to the regular XML reader by changing “#define DO_BINARY_XML 1” at the top of binaryXml.cxx to “#undef DO_BINARY_XML”.
I would guess that it’s more likely to be some failure condition due to a broken pipe because of an error triggered elsewhere. Is there nothing interesting in the associated log files at all?
It would really help if you just gave me the .p3d files so I could try running it for myself.
All right, I’ve just tried that, and it doesn’t prevent the issue–it just moves the failed read to the “non-binary” code in “read_xml”, which then reports it has unexpectedly reached the end of the file. This seems to conform with the “binary” version reporting a “gcount” of 0: it looks as though it’s receiving no data.
No, I don’t think that the bug is in the reader; rather, think that either a bad XML command is being sent from somewhere, a command is being corrupted or lost along the way, or somehow the pipes are misaligned, causing a command to be lost. I just don’t know what that command is intended to be, or where it’s being sent from.
I’ve posted everything that I’ve noticed in the logs, I’m afraid. It’s entirely possible that I’ve missed something, of course.
Is there anything in particular that I should look for? It may be that there’s something that I’m passing over, not realising that it’s important.
 But see the edit at the end of the post. [/edit]
At the moment simply running “panda3d packp3d1.9.p3d”, where both panda3d and packp3d1.9.p3d are being built by me from the source code, packp3d1.9.p3d having been copied over to another directory and the command executed from there. (I do realise that packp3d requires arguments, but execution doesn’t seem to be getting far enough for that to be an issue.)
I just tried another experiment: I created an empty file and renamed its extension to “.p3d”, then tried to run that. This time, panda managed to very briefly open a splash/error window, and printed “failed to execute”–which indicates that it’s at least getting somewhere in that case. However, this appears to occur earlier than the spawning of the python run thread, which is where my problem seems to be occurring, so I don’t think that it’s terribly relevant.
Actually. hang on: looking again through the output produced when building the runtime-distributable, I see quite a few “missing modules” and “unknown modules”, some of which seem to be xml-related. Could some of those be relevant?
I’m a little dubious, I’ll admit: I recall similar errors being considered to be unconcerning previously, but more saliently, when executing panda3d as described above I do seem to be seeing other pairs of pipes working before we reach the one that’s failing, with XML commands being sent and received, which seems to indicate that the basic functionality works.
Amusingly, one of the “missing modules” is apparently named “idonotexist”–at least it’s truthful!
Additionally, looking again at “p3dcore.log”, I noticed the following few lines:
Downloading file:///home/ian/PandaRepository/trunk/built_thaumaturge/stage/panda3d/thaumaturge_1.9/linux_amd64/panda3d.thaumaturge_1.9.linux_amd64.xml: 0M, 0xc424b0 Downloaded file:///home/ian/PandaRepository/trunk/built_thaumaturge/stage/panda3d/thaumaturge_1.9/linux_amd64/panda3d.thaumaturge_1.9.linux_amd64.xml: 100%, 0xc424b0, success = 1 File is incorrect: panda3d.thaumaturge_1.9.linux_amd64.mf report_package_info_ready: panda3d
Note the “File is incorrect” line–could that be relevant?
No, we don’t use Python modules for writing XML, so that can’t be related. You’d be seeing other errors if that was the case.
“File is incorrect” means that the extract on disk didn’t exist or was invalid. This isn’t necessarily an error. It just means it has to (re-)extract the file.
Could we take a step back for a moment? I’m finding it really difficult to analyze what’s going on here since this thread seems to be about a hundred different things. Let’s take it one step at a time, please.
The problem, if I’m understanding correctly, is that a .p3d file does not run with the runtime, correct? Please tell me the following:
Good idea. The reason, I think, that this thread has become so muddled is that this issue has proven rather difficult to pin down.
To answer your questions:
Indeed–although, for the sake of clarity, note that I don’t mean a specific .p3d file, but rather .p3d files in general–or at least, those generated either as part of this distributable or previously by packp3d, presumably using a related distributable.
In general, yes, I believe so–I may have forgotten to do so a few times, but in most of my tests I’ve been deleting all but the “log” folder from /.panda3d/.
–distributor thaumaturge --host file:///home/ian/PandaRepository/trunk/built_thaumaturge/stage
panda3d -V: 1.0.4c
panda3d -U: file:///home/ian/PandaRepository/trunk/built_thaumaturge/stage
panda3d -P: linux_amd64
For the next two questions, I’ll note that I’ve removed most of my debugging output, which was pretty messy, but left in a cleaned-up version of the output that I added to indicate the failed XML read. If you’d like any additional debugging output, just let me know. (I do see that I missed a few bits of debugging output–the line that ends with “<<< Adding packages”, for example.)
Oddly, I got two differing sets of output on two consecutive runs–the log file seemed to suggest that some of the old debugging output was still present somewhere. In both cases I cleared out /.panda3d/ before running, I believe. The following is from the second run, which doesn’t seem to have the old output, but does have the new.
(I’m presuming that I can substitute my “packp3d1.9.p3d” from my distributable build for “packp3d.p3d” above. If not, which packp3d.p3d should I use? A copy from Panda 1.8?)
:downloader: [0x24402f0] begin GET [ file:///home/ian/PandaRepository/trunk/built_thaumaturge/stage/contents.xml?1431706098 ] :downloader: [0x24414e0] begin GET [ file:///home/ian/PandaRepository/trunk/built_thaumaturge/stage/coreapi/linux_amd64/p3d_plugin.so ] :downloader: [0x2455840] begin GET [ file:///home/ian/PandaRepository/trunk/built_thaumaturge/stage/images/images.xml ] :downloader: [0x2455840] begin GET [ file:///home/ian/PandaRepository/trunk/built_thaumaturge/stage/panda3d/thaumaturge_1.9/linux_amd64/panda3d.thaumaturge_1.9.linux_amd64.xml ] :downloader: [0x2452530] begin GET [ file:///home/ian/PandaRepository/trunk/built_thaumaturge/stage/images/images.mf.pz ] :downloader: [0x244d1a0] begin GET [ file:///home/ian/PandaRepository/trunk/built_thaumaturge/stage/egg/thaumaturge_1.9/linux_amd64/egg.thaumaturge_1.9.linux_amd64.xml ] :downloader: [0x244d1a0] begin GET [ file:///home/ian/PandaRepository/trunk/built_thaumaturge/stage/panda3d/thaumaturge_1.9/linux_amd64/panda3d.thaumaturge_1.9.linux_amd64.mf.pz ] Installing Panda3D :downloader: [0x244d1a0] begin GET [ file:///home/ian/PandaRepository/trunk/built_thaumaturge/stage/egg/thaumaturge_1.9/linux_amd64/egg.thaumaturge_1.9.linux_amd64.mf.pz ] Installing Panda3D egg loader Install complete. :HostInfo: Downloading contents file [ file:///home/ian/PandaRepository/trunk/built_thaumaturge/stage/contents.xml?1431706111 ] :downloader: [0x12c43d8] begin GET [ file:///home/ian/PandaRepository/trunk/built_thaumaturge/stage/contents.xml?1431706111 ] :HostInfo(warning): Successfully downloaded file:///home/ian/PandaRepository/trunk/built_thaumaturge/stage/contents.xml?1431706111 :PackageInfo: panda3d downloading file:///home/ian/PandaRepository/trunk/built_thaumaturge/stage/panda3d/thaumaturge_1.9/linux_amd64/panda3d.thaumaturge_1.9.linux_amd64.xml :downloader: [0x12c4958] begin GET [ file:///home/ian/PandaRepository/trunk/built_thaumaturge/stage/panda3d/thaumaturge_1.9/linux_amd64/panda3d.thaumaturge_1.9.linux_amd64.xml ] :PackageInfo: Removing linux_amd64/libXext.so.6 :PackageInfo: Removing linux_amd64/libpandaphysics.so :PackageInfo: Removing linux_amd64/libXrender.so.1 :PackageInfo: Removing linux_amd64/_ssl.x86_64-linux-gnu.so :PackageInfo: Removing linux_amd64/libXxf86dga.so.1 :PackageInfo: Removing linux_amd64/panda3d.thaumaturge_1.9.linux_amd64.xml :PackageInfo: Removing linux_amd64/libCgGL.so :PackageInfo: Removing linux_amd64/libpandagl.so :PackageInfo: Removing linux_amd64/libogg.so.0 :PackageInfo: Removing linux_amd64/_vfsimporter.so :PackageInfo: Removing linux_amd64/libp3dtoolconfig.so :PackageInfo: Removing linux_amd64/libtinfo.so.5 :PackageInfo: Removing linux_amd64/libpanda.so :PackageInfo: Removing linux_amd64/libp3direct.so :PackageInfo: Removing linux_amd64/libfreetype.so.6 :PackageInfo: Removing linux_amd64/libcrypto.so.1.0.0 :PackageInfo: Removing linux_amd64/libz.so.1 :PackageInfo: Removing linux_amd64/libpython2.7.so.1.0 :PackageInfo: Removing linux_amd64/libp3dpython.so :PackageInfo: Removing linux_amd64/libpandafx.so :PackageInfo: Removing linux_amd64/libreadline.so.6 :PackageInfo: Removing linux_amd64/libp3tinydisplay.so :PackageInfo: Removing linux_amd64/p3dpython :PackageInfo: Removing linux_amd64/resource.x86_64-linux-gnu.so :PackageInfo: Removing linux_amd64/libvorbis.so.0 :PackageInfo: Removing linux_amd64/readline.x86_64-linux-gnu.so :PackageInfo: Removing linux_amd64/libXfixes.so.3 :PackageInfo: Removing linux_amd64/libpandaexpress.so :PackageInfo: Removing linux_amd64/libssl.so.1.0.0 :PackageInfo: Removing linux_amd64/panda3d.thaumaturge_1.9.linux_amd64.mf :PackageInfo: Removing linux_amd64/Config.prc :PackageInfo: Removing linux_amd64/libp3dtool.so :PackageInfo: Removing linux_amd64/libstdc++.so.6 :PackageInfo: Removing linux_amd64/_hashlib.x86_64-linux-gnu.so :PackageInfo: Removing linux_amd64/libvorbisfile.so.3 :PackageInfo: Removing linux_amd64/libpng12.so.0 :PackageInfo: Removing linux_amd64/libCg.so :PackageInfo: Removing linux_amd64/usage.xml :PackageInfo: Removing linux_amd64/datetime.x86_64-linux-gnu.so :PackageInfo: Removing linux_amd64/libXcursor.so.1 :PackageInfo: Removing linux_amd64/libXrandr.so.2 :PackageInfo: Removing linux_amd64/libutil.so.1 :PackageInfo: Removing linux_amd64/panda3d/physics.so :PackageInfo: Removing linux_amd64/panda3d/fx.so :PackageInfo: Removing linux_amd64/panda3d/core.so :PackageInfo: Removing linux_amd64/panda3d/direct.so :PackageInfo: panda3d downloading file:///home/ian/PandaRepository/trunk/built_thaumaturge/stage/panda3d/thaumaturge_1.9/linux_amd64/panda3d.thaumaturge_1.9.linux_amd64.mf.pz :downloader: [0x12c4ad8] begin GET [ file:///home/ian/PandaRepository/trunk/built_thaumaturge/stage/panda3d/thaumaturge_1.9/linux_amd64/panda3d.thaumaturge_1.9.linux_amd64.mf.pz ] :PackageInfo: Uncompressing /home/ian/.panda3d/hosts/b2a93ccb73f723420c491b3644b690a8/panda3d/thaumaturge_1.9/panda3d.thaumaturge_1.9.linux_amd64.mf.pz to /home/ian/.panda3d/hosts/b2a93ccb73f723420c491b3644b690a8/panda3d/thaumaturge_1.9/panda3d.thaumaturge_1.9.linux_amd64.mf :PackageInfo: Unpacking /home/ian/.panda3d/hosts/b2a93ccb73f723420c491b3644b690a8/panda3d/thaumaturge_1.9/panda3d.thaumaturge_1.9.linux_amd64.mf
The only log file that appears in /.panda3d/log is “p3dcore.log”. The contents follow:
That helps a lot! This part is really important:
signalled by 11, core = 128
11 means a SIGSEGV (segmentation fault) happened in the child process, and 128 means a core file was dumped.
The error message preceding it it saying it stopped “successfully”, although technically true (it did crash successfully, after all), is kind of misleading.
Now, look for a file named “core” (probably placed in the current directory) and run “gdb /home/ian/.panda3d/path/to/p3dpython core”, wait for it to load, and hit “bt” to get a traceback.
You may need to recompile the rtdist with “–optimize 3” or even lower to get meaningful debug info, as the default level 4 strips away a lot of debugging info.
Hmm… I’m not finding it.
A bit of quick searching suggests that Ubuntu (and some other Linux distributions) may by default prevent core dumps; I intend to look into this further tomorrow (it’s somewhat late here, and I’m tired).
Otherwise, just to check that I’m looking for the right thing: Would it just be named “core”, with no extension? Could it have some other name?
I’ll hopefully perform a clean build and a clean installation of that build tomorrow. Even if we don’t get a “core” file, there might be more output to look at.
It would just be named “core”. You can enable core dumps with “ulimit -c unlimited”.