On Fri, Aug 30, 2013 at 05:47:30PM +0100, Wookey wrote:
+++ Olly Betts [2013-08-30 06:04 +0100]:
The error given by therion here would be less confusing if it at least reported the filename that img failed to open, and ideally if it also reported the reason as given by img_error().
Indeed. I've already patched therion to report the filename. I'll have a go at getting it to report the error code too. It would indeed have been much less confusing.
OK. so I tried this and added this code: + img_errcode imgerr; ... - ththrow(("unable to open file")) + imgerr = img_error(); + ththrow(("unable to open file %s, error code: %u", this->fname, imgerr))
And I get ../../therion: error -- file import -- cave1.th [11] -- unable to open file /home/wookey/packages/therion/therion-5.3.11/samples/survex/cave.3d, error code: 9152480
so clearly this error code enum isn't the simple number 0-7 I was expecting.
img.c has #ifdef IMG_HOSTED static enum { IMG_NONE = 0, IMG_FILENOTFOUND = /*Couldn't open data file `%s'*/24, IMG_OUTOFMEMORY = /*Out of memory %.0s*/38, IMG_DIRECTORY = /*Filename `%s' refers to directory*/44, IMG_CANTOPENOUT = /*Failed to open output file `%s'*/47, IMG_BADFORMAT = /*Bad 3d image file `%s'*/106, IMG_READERROR = /*Error reading from file `%s'*/109, IMG_WRITEERROR = /*Error writing to file `%s'*/110, IMG_TOONEW = /*File `%s' has a newer format than this program can understand*/114 } img_errno = IMG_NONE; #else static img_errcode img_errno = IMG_NONE; #endif
So I'm not sure what's going on here. Are those numbers getting translated to strings, and I should call some function to do that before trying to print the result? If so what function? Does this machinerey only happen inside survex, not when using img.c/h externally? i.e am I HOSTED or not? Is this stuff written down anywhere?
You're not HOSTED. I don't understand why you're getting 9152480 though. If I try patching this myself I get 8 (which is IMG_TOONEW), though that's with the latest img.c from survex git, so maybe it's something that's already fixed?
So, net result so far is that I don't know what error code I'm actually getting.
Oops, I'll restore that in the next Survex release (coming soon).
[offtopic: You got my debian patches from during expo I assume?]
Yes, but I haven't done anything with them yet as I was busy caving at the time.
That lets it build, but now processing samples/survex/thconfig.1 causes a segfault: ../../therion thconfig.1 therion 5.3.11 cavern - Survex 1.2.7 initialization file: /etc/therion.ini reading ... done configuration file: thconfig.1 reading ... done reading source files ... done preprocessing database ... Segmentation fault
Which I guess isn't very surprising.
So I could go back to survex 1.2.6 and build therion. That would presumably build OK, but I supsect I'd hit problems with and v8 .3d files in data?
You can tell cavern to output older 3d versions with --3d-version=7 though older versions may not support newer features fully.
That info needs to go in the cavern manpage. It's not there currently.
OK. It's documented in cavern --help at least.
Can someone who groks C++ take a look at this and see what's needed to make it work with survex 1.2.7, as that's out now. We'll need to fix it at some point.
If you run the command under gdb, it should show where the segfault is happening:
gdb --args ../../therion thconfig.1
And then in gdb "run" and once it fails "bt full" should give a backtrace with local variables shown.
Cheers for the tutorial runes there.
I get the following: wookey@kh:~/packages/therion/therion-5.3.11/samples/survex$ gdb --args ../../therion thconfig.1 [...] Program received signal SIGSEGV, Segmentation fault. 0x00007ffff732fa59 in free () from /lib/x86_64-linux-gnu/libc.so.6 (gdb) bt full #0 0x00007ffff732fa59 in free () from /lib/x86_64-linux-gnu/libc.so.6 No symbol table info available. #1 0x000000000044d173 in img_close ()
That narrowed it down somewhat, but lack of debug symbols isn't helping here. Building it myself, I see the problem, and it's fixed in the latest version of img.c in survex git.
The build is now 'acceptably noisy but would benefit for a bit more tidyup.
The attached patch fixes all the rest which I see with GCC 4.7.2. I'm slightly dubious about this part - the patch shouldn't change the current behaviour, but that's a lot of code which doesn't actually do anything so I wonder if it's really doing what was intended: --- therion-5.3.11/extern/poly2tri/common/shapes.cc Thu Jan 19 21:42:59 2012 +++ therion-5.3.11/extern/poly2tri/common/shapes.cc Mon Sep 2 13:05:42 2013 @@ -86,11 +86,6 @@ Point* Triangle::OppositePoint(Triangle& t, Point& p) { Point *cw = t.PointCW(p); - double x = cw->x; - double y = cw->y; - x = p.x; - y = p.y; - Point* ham = PointCW(*cw); return PointCW(*cw); } Cheers, Olly