ActiveSate tcl 8.5 strange behavior Ubuntu 8.4
in [TCL]
|
Prev: Bug in sqlite3?
Next: TLS -cadir and 8.4
From: tom.rmadilo on 27 Apr 2010 14:20 On Apr 25, 2:04 pm, Anton Prokofiev <a.d.prokof...(a)googlemail.com> wrote: > Hello, All! > I've found a strange behavior of ActiveState tcl 8.5.: > When I start tclsh8.5 it create file in current directory with crazy > name ???@???@8 > > And it did not remove it when I exit with "exit" command. > > Any Ideas what could it be? I wonder what would happen if you made the file unreadable/etc. and start up tclsh8.5 again.
From: Anton Prokofiev on 27 Apr 2010 16:36 On Apr 26, 6:50 pm, "Larry W. Virden" <lvir...(a)gmail.com> wrote: > On Apr 25, 5:04 pm, Anton Prokofiev <a.d.prokof...(a)googlemail.com> > wrote: > > > When I start tclsh8.5 it create file in current directory with crazy > > name ???@???@8 > > > And it did not remove it when I exit with "exit" command. > > > Any Ideas what could it be? > > Peculiar. I don't know what kind of a file Linux ActiveTcl 8.5 would > try to create when starting. > > My first thought was that perhaps it was something associated with the > interactive history facility - but when I look in the generic/ > tclhistory.c file, I don't see an open being invoked. > > Does it happen _immediately_ after starting tclsh8.5 ? Do you have a > $HOME/.tclshrc file that might be performing some function that > creates the file? 1. Yes it happend just after start of tclsh, (I or tkcon that use it) 2. I do not have .tclshrc file in my home folder, only .teaport/%2fopt %2fActiveTcl-8.5.linux-glibc2.8-ix86
From: Larry W. Virden on 28 Apr 2010 08:18 On Apr 27, 4:50 pm, Anton Prokofiev <a.d.prokof...(a)googlemail.com> wrote: > > if I would use dir command file name will look like: > \001\220\345\001@\270\333\026@8 > > I've changed file owner to root and set access permissions for others > to none. > No differences for tkcon. > > When i use ls from tkcon I get error message: > could not read "/home/a2/1/3/ å @¸Û @8": no such file or directory > It crated in the folder from wich tcl started. Ah - the file is being created by tkcon, then. When I start a tkcon on Solaris, a $HOME/.tkcon_history file is created. tkcon uses that file to hold a history of actions taken. So the file isn't created by tcl, per se. I notice you say, above "No differences for tkcon" but then you say when you use ls, you get an error message. What is output when you type puts $tcl_platform(platform) while inside tkcon? Right now, the code used to select the history file name expects either macintosh, windows, or unix as the value there. > > This is printout of env info command > > env info What you see at this point is the results of running the Linux "info" command, which is unrelated to tcl.
From: Alexandre Ferrieux on 28 Apr 2010 08:43 On Apr 28, 2:18 pm, "Larry W. Virden" <lvir...(a)gmail.com> wrote: > On Apr 27, 4:50 pm, Anton Prokofiev <a.d.prokof...(a)googlemail.com> > wrote: > > > > > if I would use dir command file name will look like: > > \001\220\345\001@\270\333\026@8 > > > I've changed file owner to root and set access permissions for others > > to none. > > No differences for tkcon. > > > When i use ls from tkcon I get error message: > > could not read "/home/a2/1/3/ å @¸Û @8": no such file or directory > > It crated in the folder from wich tcl started. > > Ah - the file is being created by tkcon, then. When I start a tkcon on > Solaris, a $HOME/.tkcon_history file is created. tkcon uses that file > to hold a history of actions taken. > > So the file isn't created by tcl, per se. Sorry, but this is only superficially related. Look at the aforementioned clt thread and AT tracker entries: the strace posted by the original requester shows that the strangely-named file is created within the scope of execve("/bin/sh", ["/bin/sh", "/lib64/libc-2.7.so"], [/* 41 vars */] <unfinished ...> which is a popular trick to let libc identify itself. So, whatever goes wrong there is entirely libc's business (bug), and the most reasonable way out IMHO is Don't Do That, or at least don't do that at runtime: even if the exec-libc trick is used at _install_ time to make decisions about a package's .so, and has that ugly side effect, at least it won't happen at every run of tclsh. Bottom line: stay tuned, Jeff has just promised a fix :) Though I admit a workaround would be cool in the meantime... for that I'd appreciate someone with a 64-bit distrib with libc-2.7 to try several things outside of Tcl: - sh /lib64/libc-2.7.so - look at the .so itself to see if a shell-interpretation of ">BIZARRE_CHARACTERS" could account for the creation of a file named BIZARRE_CHARACTERS -Alex
From: Alexandre Ferrieux on 28 Apr 2010 09:21
On Apr 28, 2:43 pm, Alexandre Ferrieux <alexandre.ferri...(a)gmail.com> wrote: > > - look at the .so itself to see if a shell-interpretation of > ">BIZARRE_CHARACTERS" could account for the creation of a file named > BIZARRE_CHARACTERS OK nevermind, looking again at the strace I now see the smoking gun :) 567 15:55:17.463401 execve("/lib64/libc-2.7.so", ["/lib64/ libc-2.7.so"], [/* 41 vars */]) = -1 ENOEXEC (Exec format error) 567 15:55:17.524935 execve("/bin/sh", ["/bin/sh", "/lib64/ libc-2.7.so"], [/* 41 vars */] <unfinished ...> [snip] 567 15:55:17.526982 read(10, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0> \0\1\0\0\0\340\342"..., 8192) = 8192 567 15:55:17.527263 open(" àâ @°Û @8", O_WRONLY|O_CREAT|O_TRUNC| O_LARGEFILE, 0666) = 3 Here we see that /bin/sh, which is invoked with /lib64/libc-2.7.so after the failure of the direct execve() of the lib (why does it fail ???), rightfully parses its beginnings as a command line: \177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\340\342 parsed as (something like) \177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0 > \0\1\0\0\0\340\342 you'll recognize the sequence \340\342 as the characters "àâ" in the filename above ! So, everything is clear: (1) we exec lib.so (2) for some reason the exec fails (32-64 compat issue ?) (3) the OS then defaults to passing the file to /bin/sh (4) in script syntax the beginning contains a ">" redirection which creates the bizarrely named file (5) it is empty, because the characters before the ">" are not a true command's name either This could be fixed by attacking (1) or (2), though (1) is the only safe way... -Alex |