 |
added commit id -- as the Debian repository will move forward. |
 |
The backtrace indicates that the crash is not happening in boost::python, but in the vfspk3 module instead. It's possible that the folder the VFS module is trying to initialise doesn't exist. Can you check whether the paths you set DR's fs_game/fs_game_base/engine path to actually exist? |
|
|
Ok, I get the crash now in a VM here too. It crashes when calling boost::python::exec_file() on *any* script file, even though I get a different backtrace as you do. The call goes into the Python 2.7 module and crashes with a file not found. I verified the script path and the file does indeed exist. 62 iofclose.c: No such file or directory. -0 0x00007ffff3a3624c in _IO_new_fclose (fp=0x1f38090) at iofclose.c:62 -1 0x00007fffe47ad9ad in ?? () from /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0 -2 0x00007fffe4c1a7e8 in boost::python::exec_file(boost::python::str, boost::python::api::object, boost::python::api::object) () from /usr/lib/x86_64-linux-gnu/libboost_python-py27.so.1.58.0 -3 0x00007fffe53d8d33 in script::ScriptingSystem::executeScriptFile (this=0xe5b110, filename="init.py") at ScriptingSystem.cpp:100 I don't get what's wrong here, as the Python versions of libboost and the one in /usr/lib seem to match, and I don't know what else can go wrong. Even if the script file path was wrong (which it isn't) the Python library shouldn't just crash. It's happening in the main thread as well, so I don't think that it's a multithreading issue. Didn't the same setup (with scripts) work in earlier versions of those distros? |
|
|
I run into this crash when launching a very simple test program in Kubuntu 16.04, and it seems this might be an actual bug in the boost::python libraries (which is surprising given the amount of tests they usually run their code against). #include <boost/python.hpp> #include <iostream> int main() { Py_Initialize(); std::cout << "Python initialised" << std::endl; boost::python::exec_file("/home/greebo/init.py"); } The program executes, and the init.py file is executed as well ("Hello world" is printed), then the program crashes with Python initialised Hello world *** Error in `./a.out': double free or corruption (!prev): 0x0000000001c21620 *** ======= Backtrace: ========= /lib/x86_64-linux-gnu/libc.so.6(+0x77725)[0x7f2f53ec8725] /lib/x86_64-linux-gnu/libc.so.6(+0x7ff4a)[0x7f2f53ed0f4a] /lib/x86_64-linux-gnu/libc.so.6(cfree+0x4c)[0x7f2f53ed4abc] /lib/x86_64-linux-gnu/libc.so.6(fclose+0x103)[0x7f2f53ebe313] /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(+0x1579ad)[0x7f2f54b559ad] /usr/lib/x86_64-linux-gnu/libboost_python-py27.so.1.58.0(_ZN5boost6python9exec_fileENS0_3strENS0_3api6objectES3_+0xe8)[0x7f2f547e87e8] ./a.out[0x400da0] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0)[0x7f2f53e71830] I've found two references: https://bugs.launchpad.net/ubuntu/+source/boost1.58/+bug/1600345 https://github.com/boostorg/python/commit/fe24ab9dd5440562e27422cd38f7de03356bfd16 Maybe this was really introduced (and even fixed) back in 2015, yet the 16.04 (K)ubuntu distro is still using the boost 1.58 package, which is also a bit disappointing. Let's hope they upgrade to a newer boost package soon. |
|
|
(Sorry for not answering earlier and only giving a short life sign now; I did not find time to evaluate your comments until yet; I'll investigage ASAP) |
|
|
Seems so that the boost version at that time was the culprit. The new upload fixed it and I reenabled python support for Debian. So I guess this can be closed too. |
|
|
Just for my own understanding, which new upload are you referring to? Has the boost lib version been upgraded by the Ubuntu maintainers in the meantime? |
|
|
I was talking about the recent Debian upload [1]; not about Ubuntu :) (But Ubuntu is following the Debian package [2] this should not make a difference) [1] https://tracker.debian.org/pkg/darkradiant [2] https://launchpad.net/ubuntu/+source/darkradiant The "old" package was compiled against boost 1.61 [3] , the newer one build against 1.62. This is true for both distributions [4,5]. It seems that with 1.62 the crash is gone. [3] https://buildd.debian.org/status/fetch.php?pkg=darkradiant&arch=amd64&ver=2.0.4-1&stamp=1472068600 [4] https://buildd.debian.org/status/fetch.php?pkg=darkradiant&arch=amd64&ver=2.1.0-1&stamp=1481461516 [5] https://launchpadlibrarian.net/297741594/buildlog_ubuntu-zesty-amd64.darkradiant_2.1.0-1_BUILDING.txt.gz tobi (your Debian maintainer) |
|
|
Ah, well, then I guess some appreciation is in order. :) I somehow managed to be unaware of that fact that there's a darkradiant package in Debian, let alone somebody who is actively working on keeping it up to date. So, thanks! |
|
|
By the way, tobi, if there's anything I should change in the sources in order to make your life as packager easier, please let me know. I saw that you changed stuff in debian/copyright etc. - is that something I should be pushing to upstream? |
|
|
Thanks for asking! Regarding the debian directory: If you want, you can sync back the changes to the debian/ directory, but it won't make a difference for the packaging (@Debian we usually recommend that upstream do not ship a debian directories, but our packaging tool will ignore the directory e.g if I import a new version*). However, the debian directory in the github repository is a quite old packaging style, so it wouldn't hurt to update them; though you need to see if you want all the changes, e.g I did drop the i20n package. Another wish: I'm currently carrying a patch to make darkradiant builds reproducible, (http://reproducible.debian.net/). I did not yet bother to submit it to you, as it is qwritten uite Debian specific. Though, maybe you want to take a look and eliminate all __DATE__ and __TIME__s? https://anonscm.debian.org/git/pkg-games/darkradiant.git/tree/debian/patches/01-reproducible-build.patch. * BTW, there is a wiki page for upstreams, which might be a interesting read: https://wiki.debian.org/UpstreamGuide; But you're doing fine here, as far as I can see.. -- tobi |
|
|
Ok, I just tried to merge changes from your repo (https://anonscm.debian.org/git/pkg-games/darkradiant.git) to mine, but it produced tons of conflicts. Is the repo at debian.org a clone or have the files been imported by copy? What's the best approach to make the __DATE__ stuff compatible with the repro builds? I'd like to have some sort of timestamp in the app since that's the only thing I can get from some users in terms of info. I usually don't bump versions for pre-release binaries handed out for testers. Is it possible to define a build timestamp for Linux builds at the time the ./configure script is run? Or is that even worse? As far as the Debian folder goes - I'd be perfectly fine with giving you write access to the repo at github such that you can work in the upstream repo directly without applying the same things over and over again each time you look into packaging. Since you as a packager are doing work that would otherwise be left for me to do, I'm willing to make your life easier here. |
|
|
Should we move this discussion off the bug tracker? You can mail me at tobi __at__ debian.org or can register at the forum.. Let me know what you prefer :) |
|
|
Well, agreed. Probably best if you get yourself an account on the forums, then. There's the DarkRadiant forum here: http://forums.thedarkmod.com/forum/51-darkradiant-feedback-and-development/ |
|
|
Done, see here: http://forums.thedarkmod.com/topic/18592-debian-packaging/ |
- Anonymous
