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 cave1.th definitely exists. why would 'source cave1.th' fail? ownership and permissions are OK running therion thconfig.1 again produces the above output. similarly in the survex/use dir: 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 source foo.th has just worked fine in q-marks and pocket-topo and morphing/sample1 etc. I am perplexed. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/
+++ 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
cave1.th definitely exists. why would 'source cave1.th' fail?
source foo.th has just worked fine in q-marks and pocket-topo and morphing/sample1 etc. I am perplexed.
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. There is a cave.3d in the directory with sensible permissions. I suspect the issue is a new version of survex, so that file is in version 8 format. I suspect something in thimport.cxx (shouldn't therion be using the survex img.c/img.h files rather than implementing it's own parser?) Ah. I see it has a copy of img.h, but it's it's own copy in 'extern', not the actual copy from survex (I guess as survex doesn't actually provide a survex-dev package with these headers in, therion can't avoid having an internal copy). It seems that line 4 of a v8 file has a date like: @1377747129 whearas v6 and v7 had: Sun,2011.02.27 02:37:02 GMT (confirmed by checing the 3dformat.htm and 3dformat-old.htm files in the survex docs) Not sure if that's actually what was breaking. Updating to the current img.* caused: extern/img.o: In function img_write_item': img.c:(.text+0x3f38): undefined reference to max' which needed this putting back to fix: /* In C++ code, #include<algorithm> and use std::max and std::min instead. */ #ifndef __cplusplus /* Return max/min of two numbers. */ /* May be defined already (e.g. by Borland C in stdlib.h) */ /* NB Bad news if X or Y has side-effects... */ # ifndef max # define max(X, Y) ((X) > (Y) ? (X) : (Y)) # endif # ifndef min # define min(X, Y) ((X) < (Y) ? (X) : (Y)) # endif #endif 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? 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. My curent sources are here if someone wants to start from there: http://wookware.org/software/therion/therion-5.3.11-wook.tar.gz 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. I have no idea how to fix this apaprt from disabling the warning. C++ gurus welcome to improve the code. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/
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
cave1.th definitely exists. why would 'source cave1.th' fail?
source foo.th has just worked fine in q-marks and pocket-topo and morphing/sample1 etc. I am perplexed.
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.
There is a cave.3d in the directory with sensible permissions. I suspect the issue is a new version of survex, so that file is in version 8 format.
I suspect something in thimport.cxx (shouldn't therion be using the survex img.c/img.h files rather than implementing it's own parser?) Ah. I see it has a copy of img.h, but it's it's own copy in 'extern', not the actual copy from survex (I guess as survex doesn't actually provide a survex-dev package with these headers in, therion can't avoid having an internal copy).
It's intended that you copy those two files to use them.
It seems that line 4 of a v8 file has a date like: @1377747129 whearas v6 and v7 had: Sun,2011.02.27 02:37:02 GMT (confirmed by checing the 3dformat.htm and 3dformat-old.htm files in the survex docs)
Dates are now stored in a format that's sanely machine readable.
Not sure if that's actually what was breaking.
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().
Updating to the current img.* caused: extern/img.o: In function img_write_item': img.c:(.text+0x3f38): undefined reference to max' which needed this putting back to fix: /* In C++ code, #include<algorithm> and use std::max and std::min instead. */ #ifndef __cplusplus /* Return max/min of two numbers. */ /* May be defined already (e.g. by Borland C in stdlib.h) */ /* NB Bad news if X or Y has side-effects... */ # ifndef max # define max(X, Y) ((X) > (Y) ? (X) : (Y)) # endif # ifndef min # define min(X, Y) ((X) < (Y) ? (X) : (Y)) # endif #endif
Oops, I'll restore that in the next Survex release (coming soon).
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.
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.
My curent sources are here if someone wants to start from there: http://wookware.org/software/therion/therion-5.3.11-wook.tar.gz
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. Cheers, Olly
+++ 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@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/
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
+++ Olly Betts [2013-09-02 03:07 +0100]:
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))
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?
With a bit of help from Ol pointing out where I was hacking way after I should have gone to bed, this is all sorted now.
That lets it build, but now processing samples/survex/thconfig.1 causes a segfault:
Can someone who groks C++ take a look at this and see what's needed to make it work with survex 1.2.7
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.
I've updated the patches to use this and everything builds and processes nicely now.
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.
That's all lovely except this bit:
--- therion-5.3.11/thepsparse.cxx Sun May 30 10:11:10 2010 +++ therion-5.3.11/thepsparse.cxx Mon Sep 2 13:57:29 2013 @@ -146,6 +146,12 @@ closed=false; fillstroke = -1; transformation.clear(); + transf[0] = 0; + transf[1] = 0; + transf[2] = 0; + transf[3] = 0; + transf[4] = 0; + transf[5] = 0; }
which causes: thepsparse.cxx:149:3: error: ‘transf’ was not declared in this scope I tried changing it to + transformation.transf[0] = 0; + transformation.transf[1] = 0; + transformation.transf[2] = 0; + transformation.transf[3] = 0; + transformation.transf[4] = 0; + transformation.transf[5] = 0; Which stops the whinge but doesn't stop this error: thepsparse.cxx:812:35: warning: ‘fntmatr.MP_transform::transf[5]’ may be used uninitialized in this function [-Wmaybe-uninitialized] I took a stab in the C++ dark and ched the patch to this: Index: therion-5.3.11/thepsparse.cxx =================================================================== --- therion-5.3.11.orig/thepsparse.cxx 2013-09-05 01:12:43.630272317 +0100 +++ therion-5.3.11/thepsparse.cxx 2013-09-05 01:40:29.410532475 +0100 @@ -117,6 +117,12 @@ void MP_transform::clear () { command = MP_notransf; + transf[0] = 0; + transf[1] = 0; + transf[2] = 0; + transf[3] = 0; + transf[4] = 0; + transf[5] = 0; } MP_transform::MP_transform () { (i.e set them to zero in the MP_transform clear member) and that seemed to do the trick, and is presumably what Ol meant to type in the first place. So we have a warning-free build! Now the only issue remaining is that every therion run has this at the end: compilation time: 2 sec /home/wookey/packages/therion/therion-5.3.11/therion: warning -- trying to run: p(U+001A)(U+0001)/tmp/th1544 sh: 1: p(U+001A)(U+0001) not found /home/wookey/packages/therion/therion-5.3.11/therion: warning -- error deleting temporary directory -- /tmp/th1544 (The odd chars are shown as little square boxes, not the above unicode representation I've used - i.e. it's the actual odd chars) This looks like garbage getting into the string which should remove the therion tmpdir. I think this has been broken in the Debian packages from some time (because I've been collecting thNNNN tmpdirs for ages), but then I've been using 5.3.11 for some time on this machine... I presume the relevant code is: void thtmpdir::remove() in thtmpdir.cxx some debug suggests that if (strlen(thini.tmp_remove_script.get_buffer()) > 0) { thbuffer tmpfname; tmpfname = thini.tmp_remove_script.get_buffer(); tmpfname += " "; tmpfname += this->name; std::cout<<"trying to run special rmcommand:"<<tmpfname.get_buffer()<<std::endl; system(tmpfname.get_buffer()); is being run and thini.tmp_remove_script.get_buffer() has garbage in it. Where does this come from? (my thconfig.ini file has: # tmp-remove "" in it. Uncommenting that and giving it a value makes no difference to the above behaviour. tmp_remove_script only seems to get set in thinit.cxx, either to "" or reading in the file. So I don't know why it's coming out to be p and a couple of control chars. Could a different therion.ini files be being used (from the one in /etc/therion.ini)? commenting out the enum entry: static const thstok thtt_initcmd[] = { ... {"tmp-path",TTIC_TMP_PATH}, // {"tmp-remove",TTIC_TMP_REMOVE_SCRIPT}, {"units",TTIC_UNITS}, means it now tries to run trying to run special rmcommand:p/tmp/th5702 sh: 1: p not found (i.e the control chars are gone) Simply removing all the code for if (strlen(thini.tmp_remove_script.get_buffer()) > 0) { in thtmpdir.cxx, thtmpdir::remove() makes it behave properly, which seems the best plan for now. Anyone got any idea what's going on here? Oh yes another little clue might be that zero-length files are created in samples/xelevation/ samples/map-offset/ samples/u-symbols/ with control chars for names, i.e. samples/xelevation/(U+0002) samples/map-offset/(U+0002) samples/u-symbols/(U+0001) Maybe that's a different issue, but we clearly have a problem with spurious control chars. Current code is at: http://wookware.org/software/therion/therion-5.3.11-wook3.tar.gz I plan to upload this to debian after a couple of checks so we at least have something newer than 5.3.10 and basically working in the archive. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/
participants (2)
-
Olly Betts -
Wookey