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 at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: therion-5.3.11-warning-fixes.patch
Type: text/x-diff
Size: 15648 bytes
Desc: not available
URL:
<http://mailman.speleo.sk/pipermail/therion/attachments/20130902/c37310f1/attachment.patch>
