+++ Olly Betts [2013-08-30 06:04 +0100]:
> On Fri, Aug 30, 2013 at 04:43:06AM +0100, Wookey wrote:
> > +++ Wookey [2013-08-29 05:01 +0100]:
> > > When doing the build the samples processing gets as far as the
> > > 'survex' folder and things go wrong:
> > >
> > >
> > > therion 5.3.11
> > > initialization file: /etc/therion.ini
> > > reading ... done
> > > configuration file: thconfig.1
> > > reading ... done
> > > reading source files ... done
> > > preprocessing database ...
> > > therion: error -- file import -- cave1.th [11] -- unable to open file
> > >
> >
> > aha. the issue is not that cave1.th is unable to be openned. It's that
> > line 11 of cave1.th is:
> > import cave.3d -surveys use
> > and _that_ is what's failing.
> >
>
> A version the img code which pre-dates v8 of the format can't possibly
> successfully read it, and will return an error. You should be able to
> tell this has happened by looking at what img_error() returns (in this
> case it should be IMG_TOO_NEW).
> 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?
And yes, it's been a while since I did any C :-)
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?]
> > 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.
> > 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
GNU gdb (GDB) 7.4.1-debian
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/wookey/packages/therion/therion-5.3.11/therion...(no
debugging
symbols found)...done.
(gdb) run
Starting program: /home/wookey/packages/therion/therion-5.3.11/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 ...
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 ()
No symbol table info available.
#2 0x00000000004dc626 in thimport::import_file_img() ()
No symbol table info available.
#3 0x00000000004dd468 in thimport::import_file() ()
No symbol table info available.
#4 0x0000000000418298 in thdatabase::preprocess() ()
No symbol table info available.
#5 0x000000000040742b in main ()
No symbol table info available.
Does that help.
> > BTW building therion now gives an awful lot of:
> > thdb1d.h: In constructor ???thdb1ds::thdb1ds(const char*, thsurvey*)???:
> > thdb1d.h:176:19: warning: passing NULL to non-pointer argument 1 of
> > ???std::list<_Tp, _Alloc>::list(std::list<_Tp, _Alloc>::size_type, const
> > value_type&, const allocator_type&) [with _Tp = thdata*; _Alloc =
> > std::allocator<thdata*>; std::list<_Tp, _Alloc>::size_type = long
> > unsigned int; std::list<_Tp, _Alloc>::value_type = thdata*;
> > std::list<_Tp, _Alloc>::allocator_type = std::allocator<thdata*>]???
> > [-Wconversion-null]
> > whinges.
>
> The "data(NULL)" on line 172 of thdb1d.h should just be "data()" (or
> removed entirely - a std::list will be default initialised implicitly
> anyway). Currently the NULL presumably is getting converted to 0
> (and that's giving the warning) so it probably is currently creating a
> list of initial size 0 anyway.
OK. Cheers. That cleaned up a lot of noise. And I got rid of some "deprecated
conversion from string constant to âchar*â" in the
.xpm files to clean up some more. The build is now 'acceptably noisy but would
benefit for a bit more tidyup.
There are still quite a few
warning: variable âZâ set but not used [-Wunused-but-set-variable]
quite a few:
lxImgIO.cxx:106:20: warning: deprecated conversion from string constant to
âchar*â [-Wwrite-strings]
one:
thepsparse.cxx:806:35: warning: âfntmatr.MP_transform::transf[5]â may be
used uninitialized in this function [-Wmaybe-uninitialized]
and some:
extern/poly2tri/sweep/advancing_front.h: In constructor
âp2t::Node::Node(p2t::Point&)â:
extern/poly2tri/sweep/advancing_front.h:49:10: warning: âp2t::Node::valueâ
will be initialized after [-Wreorder]
extern/poly2tri/sweep/advancing_front.h:46:9: warning: âp2t::Node*
p2t::Node::nextâ [-Wreorder]
extern/poly2tri/sweep/advancing_front.h:51:3: warning: when initialized here
[-Wreorder]
and two:
extern/poly2tri/sweep/sweep_context.cc:75:36: warning: comparison between
signed and unsigned integer expressions [-Wsign-compare]
Wookey
--
Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/
