[PATCH] fix broken tty command on cygwin
Hi
The gdb tty option and command is broken on cygwin. After setting a tty
for the inferior, the first run seems OK, but the second sometimes fails
and the third may cause gdb to hang or enter an infinite loop. The fix
is to close the (redundant) tty fd *before* launching the inferior
process instead of after.
This fix is necessary to support anjuta and other gdb interfaces on
cygwin.
Changelog entry:
2002-12-31 Steven O'Brien <[EMAIL PROTECTED]>
* gdb/win32-nat.c (child_create_inferior): close tty fd before
launching the inferior process.
Patch:
Index: win32-nat.c
===
RCS file: /cvs/src/src/gdb/win32-nat.c,v
retrieving revision 1.66
diff -u -p -r1.66 win32-nat.c
--- win32-nat.c 23 Nov 2002 02:49:45 - 1.66
+++ win32-nat.c 31 Dec 2002 09:47:00 -
@@ -1614,6 +1614,7 @@ child_create_inferior (char *exec_file,
dup2 (tty, 0);
dup2 (tty, 1);
dup2 (tty, 2);
+ close (tty);
}
}
@@ -1629,7 +1630,6 @@ child_create_inferior (char *exec_file,
&pi);
if (tty >= 0)
{
- close (tty);
dup2 (ostdin, 0);
dup2 (ostdout, 1);
dup2 (ostderr, 2);
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
guile-1.5.6-5 mentioned in setup.ini
In the current setup.ini (timestamp 1041225613) guile-1.5.6-5 is marked as [prev] for all three of @guile, @guile-devel and @guile-doc. But it is presumed [curr] as the source for @libguile14. (I found this while fiddling around trying to reduce [curr] + [prev] + [test] to fit on one CD.) It seems odd to me but I can think of reasons why what might be [prev] for one package might be [curr] for others. Please can the correct-ness of this be confirmed by the maintainer? Sorry, and thanks. Fergus -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Req Help: sshd error: Read from socket failed: Connection aborted
Min Kim wrote: > Max, > > You're a genius. I did have Viruscan 7 installed but not the firewall. > Everything works perfectly now with it uninstalled. I guess I'll have > to go with Norton Antivirus. There isn't by chance a workaround for > the McAfee Viruscan problem, is there? I'm afraid not. As data points, I will mention that I run McAfee 4.5.1+SP1 works with no problems, and McAfee 6 has been reported to work as well. PS to Cygwin list: Is it worth documenting this in /usr/doc/Cygwin/openssh-version.README ? Or maybe even a warning in ssh-host-config? Max -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Curses library and Python
John, On Mon, Dec 30, 2002 at 07:26:51PM -0700, John Purser wrote: > Is anyone out there using the Python curses library or do you know of > a good tutorial for it? > [snip] > Any resources for me out there? I recommend posting to [EMAIL PROTECTED] -- I think that you will have better luck there. Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: guile-1.5.6-5 mentioned in setup.ini
<[EMAIL PROTECTED]> writes: > In the current setup.ini (timestamp 1041225613) guile-1.5.6-5 is marked as > [prev] for all three of @guile, @guile-devel and @guile-doc. But it is > presumed [curr] as the source for @libguile14. *guile*-1.6.0-1 (is curr and) should be used for all purposes. > It seems odd to me but I can think of reasons why what might be [prev] for > one package might be [curr] for others. Please can the correct-ness of this > be confirmed by the maintainer? Sorry, and thanks. There's no reason, however, for the latest version of a versioned library package (libguile14-1.5.6-5 in this case) not to be curr. Old or custom packages (that possibly marked curr), may depend on it. Note that libguile12 is *newer* than libguile14 (see the guile-devel list). Greetings, Jan. -- Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] Updated: expect-20021218-1, gdb-20021218-1,tcltk-20021218-1
Chris, On Mon, Dec 30, 2002 at 06:02:02PM -0500, Christopher Faylor wrote: > How have you managed to build cygwin in the past? By leveraging off of the following patch: http://sourceforge.net/tracker/?group_id=5470&atid=305470&func=detail&aid=443669 and installing the required headers. BTW, due to these discussions, I have realized the above patch needs to be enhanced to prevent accidentally picking up the real X, tk headers. > The rationale for the name difference has been made clear before. It > is to make it clear that these libraries are for modified cygwin > versions of tcl/tk. I should have been more clear. I was reacting to the "cyg" not the lack of a period. For example, in 8.0 we had libtcl80.a, in 8.3 now we have libcygtk83.a. This name change is another reason why the above patch needs to be reworked. > I'm not really willing to arbitrarily change the convention now. OK. I just wanted to check before I submitted my patch to the Python patch collector. Thanks, Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Heads up: *possible* bug in cygwin
Christopher Faylor wrote: On Mon, Dec 30, 2002 at 11:18:55PM -0500, Charles Wilson wrote: If somebody with a debuggable cygwin kernel could look into this, I'd appreciate it. I'll try to follow up on my own, but it takes FOREVER to do a 'cvs update' on the cygwin source tree over a 28.8k modem... Sigh. Finally built a debuggable cygwin from current CVS. Here's the stacktrace from the SIGSEGV. Problems "in the bowels" of malloc are invariably caused by memory corruption, like double freeing of a pointer, overrunning of a buffer, ignoring of OOM conditions, etc. Given that the malloc in cygwin (to say nothing of Doug Lea's malloc) goes through a fairly heavy workout every day, I'd suspect the application before I'd suspect cygwin. I would too -- but I can't see where any of the arguments to the functions, or any of the operations within the glib subroutines along the way, do any of that. It all =seems= okay, but I'll probably have to pull out pencil and paper and keep track of all the pointers by hand. Or can I just turn on -DDEBUG when compiling malloc.cc... Plus, glib-2.0.7 is at least as well tested as cygwin (and might be close to as well tested as dlmalloc). It's hard to imagine that a buffer overrun or double-free was overlooked in glib's own testsuite, given that folks on non-cygwin platforms can use stuff like purify and electricfence when they test. And finally, that doesn't explain why the *same code*, *unchanged*, worked on May 1, 2002, but doesn't now. I wish I had the cygwin dll and importlib from then, so I could eliminate that variable... Hmmm...glib does a lot of testing against NULL to determine whether a pointer has been initialized -- but declares these pointers as gpointer foo; not gpointer foo = NULL; Did gcc (pre 3.2) automatically initialize data to 0, while gcc-3.2 does not? Hmmm...waitaminute, I do have gcc2 installed... --Chuck -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] Updated: expect-20021218-1, gdb-20021218-1, tcltk-20021218-1
Jason Tishler wrote: I should have been more clear. I was reacting to the "cyg" not the lack of a period. For example, in 8.0 we had libtcl80.a, in 8.3 now we have libcygtk83.a. This name change is another reason why the above patch needs to be reworked. I'm not really willing to arbitrarily change the convention now. OK. I just wanted to check before I submitted my patch to the Python patch collector. Since the config scripts (/usr/lib/tclConfig.sh, /usr/lib/tkConfig.sh) seem to be accurate now, is there any way you could use them to automatically grab the correct importlibs? It seems that using them is the Right Thing -- if they work. --Chuck -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
[ANNOUNCEMENT] Updated: exim-4.12-1
I've updated the version of exim to 4.12 (exim is a Mail Transfer Agent, like sendmail). 4.12 is the first stable release since the current 4.10. It contains 54 backward compatible changes to exim proper, see ftp://ftp.csx.cam.ac.uk/pub/software/email/exim/ChangeLogs/NewStuff-4.11 There are also five Cygwin specific changes 1) Use setgroups (requires Cygwin 1.3.13 or more recent). 2) Use ioctl to find the network interfaces. 3) On Win95/98/ME, remove the workaround against a Cygwin 1.3.12 bug and modify the workaround against some Microsoft networking bugs to avoid getting stuck by defunct processes. 4) Include the exim icon and version resources in the executable. 5) exim-config now checks for spaces in usernames and its informational output is improved. As a side effect of 1), delivery processes run without supplementary groups. In the unlikely cases where they are needed, set the variable "initgroups" where appropriate in /etc/exim.conf If you have not used exim before, configure it with exim-config after downloading it with setup as explained below. Pierre To update your installation, click on the "Install Cygwin now" link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Then, run setup and answer all of the questions. You'll need to click on "Mail" and select "exim" if this is your first time installing, otherwise your installation should be refreshed automatically. If you have questions or comments, please send them to the Cygwin mailing list at: [EMAIL PROTECTED] . -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] Updated: expect-20021218-1, gdb-20021218-1, tcltk-20021218-1
- Original Message - From: "Jason Tishler" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, December 31, 2002 9:25 AM Subject: Re: [ANNOUNCEMENT] Updated: expect-20021218-1, gdb-20021218-1, tcltk-20021218-1 > Chris, > > On Mon, Dec 30, 2002 at 06:02:02PM -0500, Christopher Faylor wrote: > > How have you managed to build cygwin in the past? > > By leveraging off of the following patch: > > http://sourceforge.net/tracker/?group_id=5470&atid=305470&func=detail&aid=443669 a more detailed description of this 'kludge' here http://www.vso.cape.com/~nhv/files/python/tinker.html > and installing the required headers. Note there is a similar issue with TOGL the TK OpenGL Widget http://togl.sourceforge.net/ which can also be built with Cygwin using a similar 'kludge' http://www.vso.cape.com/~nhv/files/cygwin/togl/ < this is for the previous Cygwin TK release > I can submit a TOGL package and a Python OpenGL package < which depends on TOGL and Tkinter > if and when there is an approved method of working around the TCL / TK header issue I will gladly help with any Cygwin TCL / TK issues in any way I can short of becoming the 'official' maintainer for which I do not feel qualified given their critical role with respect to 'Insight' and 'gdb' Cheers Norman -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: symbols in Microsoft DLL's and Linking w/ them
Since this is a general inquiry without any specifics, I assume you're looking for a general confirmation that linking against MS DLLs is possible. I can attest to that. Generally speaking, when you run into unresolved symbols, you need to find the DLLs/import libraries or static libraries which define them and add them to your link line. If you're implying that the MS DLL that you're linking against doesn't export the symbols that are unresolved, that's probably OK unless you're implying that this is a different DLL and is the one that's supposed to resolve the missing symbols. But these are all details which you didn't send so they're not worth much discussion. Assuming that this turns out to be a Cygwin-related issue and you can't find the answer to your problem with further study, please refer to www.cygwin.com/bugs.html before posting a followup message. This will familiarize you with the information requirements this list has for problem reports and related details. Also, you will more than likely want to post to [EMAIL PROTECTED] rather than [EMAIL PROTECTED] The former is the proper place for this kind of inquiry, again assuming it's Cygwin-related. I've redirected the discussion there (and BCC'd [EMAIL PROTECTED] to maintain a pointer from there). Good luck, Larry Original Message: - From: Robert Bercik [EMAIL PROTECTED] Date: Tue, 31 Dec 2002 07:50:59 -0800 (PST) To: [EMAIL PROTECTED] Subject: symbols in Microsoft DLL's and Linking w/ them Hi, I'm trying to create a cygwin dll that links to a microsoft DLL. However, when I try and link to the DLL, the linkerl complains that the symbols contained in the microsoft DLL are still unresolved. I used the nm command on the DLL and it reported that it did not find any symbols, but when I did a grep command the symbols as an argument, it found them in the DLL. Have any of you had any success with this in the past? I'm really stuck here. Thanks in advance, -Rob - Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now mail2web - Check your email from the web at http://mail2web.com/ . -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: symbols in Microsoft DLL's and Linking w/ them
On Tue, Dec 31, 2002 at 07:50:59AM -0800, Robert Bercik wrote: >I'm trying to create a cygwin dll that links to a microsoft DLL. >However, when I try and link to the DLL, the linkerl complains that the >symbols contained in the microsoft DLL are still unresolved. I used >the nm command on the DLL and it reported that it did not find any >symbols, but when I did a grep command the symbols as an argument, it >found them in the DLL. Have any of you had any success with this in >the past? I'm really stuck here. > >Thanks in advance, Go back and read http://cygwin.com/lists.html. This isn't the mailing list for this kind of request. I've redirected this to cygwin at cygwin dot com. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
appy nw yr
Hello Xperts, Wish U a Very appy New Year karthik bala guru [EMAIL PROTECTED] Missed your favourite TV serial last night? Try the new, Yahoo! TV. visit http://in.tv.yahoo.com -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] Updated: expect-20021218-1, gdb-20021218-1, tcltk-20021218-1
On Tue, Dec 31, 2002 at 11:00:37AM -0500, Norman Vine wrote: >I will gladly help with any Cygwin TCL / TK issues in any way I can >short of becoming the 'official' maintainer for which I do not feel >qualified given their critical role with respect to 'Insight' and 'gdb' And I am? All it requires is communication skills. The insight mailing list is not an unfriendly place. I don't know how many times I have to repeat myself. I've been repeating myself for months now. gdb/insight/tcl/tk issues should be discussed there. They would be absolutely thrilled to have people volunteering to help them with cygwin issues. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Heads up: *possible* bug in cygwin
On Tue, Dec 31, 2002 at 09:43:50AM -0500, Charles Wilson wrote: >Did gcc (pre 3.2) automatically initialize data to 0, while gcc-3.2 does >not? Hmmm...waitaminute, I do have gcc2 installed... If gcc/ld is not initializing static data to zero then there are some pretty serious problems. Neither gcc, nor any other compiler that I am aware of, is supposed to initialize automatic data to zero. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: tar wildcard problem
Thanks for the clarification. I'm a seasoned programmer but have not worked on GNU. If you can give me some pointer perhaps I can help. (Better than trial-and-error all day :). -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Christopher Faylor Sent: Monday, December 30, 2002 3:20 PM To: [EMAIL PROTECTED] Subject: Re: tar wildcard problem On Mon, Dec 30, 2002 at 11:34:37AM -0800, Wai-Yip Tung (wtung) wrote: >I tried everything but non seems to work. This is my tar command: > > tar -T filename.txt -X xfilename.txt -cvWf $TAR_FILE > >And here is my exclude file xfilename.txt: >./*.bak >'*.bak' >"*.bak" >*.bak >file.txt >file.bak Have you tried this on linux? -T does not take files containing wildcards. Apparently -X should take patterns however, and that isn't working. Patches gratefully accepted. cgf >I have a workaround that does work. > > EXCLUDE_OPT=`cat exclude_opt.txt` > tar -T filename.txt -X xfilename.txt $EXCLUDE_OPT -cvWf $TAR_FILE > >This is my exclude_opt.txt file: >--exclude=*.class >--exclude=*.obj >--exclude=*.bak > >But this is really not nice. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] Updated: expect-20021218-1, gdb-20021218-1,tcltk-20021218-1
Chuck, On Tue, Dec 31, 2002 at 09:48:07AM -0500, Charles Wilson wrote: > Jason Tishler wrote: > >OK. I just wanted to check before I submitted my patch to the Python > >patch collector. > > Since the config scripts (/usr/lib/tclConfig.sh, /usr/lib/tkConfig.sh) > seem to be accurate now, is there any way you could use them to > automatically grab the correct importlibs? It seems that using them > is the Right Thing -- if they work. I could, but then Cygwin would be very different from the other Unixes. Or, the other Unixes would need to use this approach too. I don't think that I can "sell" these patches. Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Prioprietary DLL link problem - Can't export...
Hi, I am trying to link to a proprietary dll and I'm so damn close I can almost taste the sweet sweet linkage. But i got a little error. It's says it cannot find some symbols and therefore the export fails? Maybe you guys can help clarify, heres' what gcc says: make files.dll make[1]: Entering directory `/cygdrive/c/source-code/run306' gcc -DCYGWIN -DINLINE_4WS -w -L/usr/local/lib -L. -I. -I/cygdrive/c/Oracle/Ora81 /oci/include -v -shared -o files.dll -Wl,--export-all-symbols files.o handle.o a bort.o attrst.o calendar.o cdate.o datemm.o crm.o endwin.o fire_triggers.o get_h elp.o get_tble.o getf.o getgroup.o getun.o hwin.o init_pan.o logdf.o pager.o put f.o read_pan.o refsh.o remark.o replay.o routines.o simple.o sfattr.o sfclos.o s fcset.o sfdisp.o sfgeta.o sfgeti.o sfgetk.o sfgetp.o sfopen.o sfposr.o sfsetp.o sysinf.o sfsrea.o sfssho.o sfswri.o strings.o swin.o ice_api.o exec_sql.o change _file_group.o -lm -lcurses -lcygipc /cygdrive/c/Oracle/Ora81/oci/lib/msvc/ociw32 .lib /cygdrive/c/cobol32/lib/MFRTS32.LIB Reading specs from /usr/lib/gcc-lib/i686-pc-cygwin/3.2/specs Configured with: /netrel/src/gcc-3.2-3/configure --enable-languages=c,c++,f77,ja va --enable-libgcj --enable-threads=posix --with-system-zlib --enable-nls --with out-included-gettext --enable-interpreter --disable-sjlj-exceptions --disable-ve rsion-specific-runtime-libs --enable-shared --build=i686-pc-linux --host=i686-pc -cygwin --target=i686-pc-cygwin --enable-haifa --prefix=/usr --exec-prefix=/usr --sysconfdir=/etc --libdir=/usr/lib --includedir=/nonexistent/include --libexecd ir=/usr/sbin Thread model: posix gcc version 3.2 20020927 (prerelease) /usr/lib/gcc-lib/i686-pc-cygwin/3.2/collect2.exe --shared -Bdynamic -e __cygwin _dll_entry@12 --dll-search-prefix=cyg -o files.dll /usr/lib/gcc-lib/i686-pc-cygw in/3.2/crtbegin.o -L/usr/local/lib -L. -L/usr/lib/gcc-lib/i686-pc-cygwin/3.2 -L/ usr/lib/gcc-lib/i686-pc-cygwin/3.2/../../.. --export-all-symbols files.o handle. o abort.o attrst.o calendar.o cdate.o datemm.o crm.o endwin.o fire_triggers.o ge t_help.o get_tble.o getf.o getgroup.o getun.o hwin.o init_pan.o logdf.o pager.o putf.o read_pan.o refsh.o remark.o replay.o routines.o simple.o sfattr.o sfclos. o sfcset.o sfdisp.o sfgeta.o sfgeti.o sfgetk.o sfgetp.o sfopen.o sfposr.o sfsetp .o sysinf.o sfsrea.o sfssho.o sfswri.o strings.o swin.o ice_api.o exec_sql.o cha nge_file_group.o -lm -lcurses -lcygipc /cygdrive/c/Oracle/Ora81/oci/lib/msvc/oci w32.lib /cygdrive/c/cobol32/lib/MFRTS32.LIB -lgcc -lcygwin -luser32 -lkernel32 - ladvapi32 -lshell32 -lgcc /usr/lib/gcc-lib/i686-pc-cygwin/3.2/crtend.o Cannot export NULL_IMPORT_DESCRIPTOR: symbol not found Cannot export mfrts32_IMPORT_DESCRIPTOR: symbol not found Cannot export #8962;OCIW32_NULL_THUNK_DATA: symbol not found Cannot export #8962;mfrts32_NULL_THUNK_DATA: symbol not found Info: resolving _stdscr by linking to __imp__stdscr (auto-import) Info: resolving _curscr by linking to __imp__curscr (auto-import) collect2: ld returned 1 exit status make[1]: *** [files.dll] Error 1 make[1]: Leaving directory `/cygdrive/c/source-code/run306' make: *** [default] Error 2 __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
prob with Tcl glob command under Cygwin
I have downloaded the Tcl/Tk 8.3.4 package which was released with patches to compile under the cygwin C compiler for Windows OS, available from http://cygwin.com/ported.html For the most part this works except it seems to work better using the init.tcl file that comes with the Scriptics Tk 8.3.4 binary for Windows However, one big problem is that the glob command does not seem to work. Whether I call it with a wildcard in the file name pattern or a pattern that is just the actual name of a single file, regardless of if it is POSIX style path or Windows style path or just the file name of a file in the current working directory, calling it from a program or the Tclsh command line, no matter what it just returns an error saying there are no files matching the pattern. All other file system commands, shell commands via exec, etc, work okay, just not glob. I wonder if anyone else has had this problem and how it can be fixed. Thanks for any help --- Joseph Rosenzweig -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: prob with Tcl glob command under cygwin
On Tue, Dec 31, 2002 at 04:05:17PM -0500, Joseph wrote: >I have downloaded the Tcl/Tk 8.3.4 package which was released with >patches to compile under the cygwin C compiler for Windows OS, >available from http://cygwin.com/ported.html > >For the most part this works except it seems to work better using the >init.tcl file that comes with the Scriptics Tk 8.3.4 binary for Windows . . . >I wonder if anyone else has had this problem and how it can be fixed. Wouldn't that be a question for the author of the package? cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Quirky Emacs behavior -- any ideas?
Hi Folks,
Does this jog anyone's memory?
New XP SP1 install, new cygwin install (full)
Quirk #1:
When I launch Emacs, I get this scratch buffer popping
up which reads:
** ad-Orig-documentation called with 5 arguments, but
accepts only 1-2
Then, I notice that apropos is broken. For example,
if I type "M-X apropos tab"
I get
Debugger entered--Lisp error:
(wrong-number-of-arguments # 5)
ad-Orig-documentation(Buffer-menu-visit-tags-table t
nil nil nil)
documentation(Buffer-menu-visit-tags-table t)
apropos-command("tab" nil)
* call-interactively(apropos-command)
execute-extended-command(nil)
call-interactively(execute-extended-command)
Quirk #2:
When I exit Emacs (and return to a bash shell) I see
this error
lstat(./kpsewhich) failed ...
./kpsewhich: No such file or directory
I've never seen either of these behaviors before and
can find little in the forum or google.
Does anyone have an idea what may be going on?
Thanks,
Andrew
__
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: Heads up: *possible* bug in cygwin
Christopher Faylor wrote:
On Tue, Dec 31, 2002 at 09:43:50AM -0500, Charles Wilson wrote:
Did gcc (pre 3.2) automatically initialize data to 0, while gcc-3.2 does
not? Hmmm...waitaminute, I do have gcc2 installed...
If gcc/ld is not initializing static data to zero then there are some
pretty serious problems. Neither gcc, nor any other compiler that I
am aware of, is supposed to initialize automatic data to zero.
You're right, as usual. (Plus empirical evidence: no change when
compiling with gcc-2. Still get the SIGSEGV)
You're also right [I think] about the buffer overrun/whatever problem in
glib. I haven't found the specific, offending command yet, but it seems
pretty obvious from the postmortem that that is what has happened.
Single-stepping thru the code shows some interesting things. Basically,
we have a g_string (structure that contains a char* field, a length
field, plus some other fields that are hidden from the public interface.
The whole structure is dynamically allocated, and the char* field
points to additional dynamically allocation storage.
This g_string is initially allocated as a minimum size string, where the
char* points to a minimum size buffer (4 bytes, it appears), but
contains "" (e.g. *char = '\0', len = 0). [as far as glib is concerned,
the char* points to a chunk of memory 4 bytes long. But dlmalloc
actually uses a chunk that is 16 bytes long == 3 32bit words of dlmalloc
overhead, plus the user data]
Then, the testsuite attempts to append a char* that contains approx 20k
characters. This means that glib must realloc a larger buffer for the
g_string's internal storage. It rounds up to the nearest power of two
-- 32768 -- and attempts to realloc the space:
line 220: gstring.c (g_string_maybe_expand)
string->str = g_realloc (string->str, string->alloc);
"string" is the g_string, recast to GRealString* to reveal the
private members of the structure (like 'alloc', which is how
much storage glib originally requested for this buffer, even
though it only needed 1 byte for the 0-length string "".)
in g_realloc, we simply thunk to the system realloc
line 338: gmem.c (g_realloc)
p = (gpointer) realloc (mem, size);
where mem is the string->str argument above, and size is
the string->alloc argument (it equals 32768)
mem, at this point (or string->str, if you like) is a viable pointer to
a previously allocated chunk of memory (4 bytes long) that contains '\0'
and 3 unknown other values. It has not previously been freed.
But now, as I said, we're in the bowels of dlmalloc.
line 146: malloc_wrapper.cc (realloc)
res = dlrealloc (p, size);
again, p (== mem == string->str) is a valid pointer. size is
32768.
line 4078: malloc.cc (dlrealloc == rEALLOc)
newmem = mALLOc(nb - MALLOC_ALIGN_MASK);
we've already determined that the request cannot be satisfied by
expanding the allocation within the current chunk, nor can it be
satisfied by expanding the allocation into the next chunk. So, we fall
back on the "allocate-copy-free" algorithm, and start by allocating a
new chunk of memory.
line 3516: malloc.cc (dlmalloc == mALLOc)
bck->fd = unsorted_chunks(av);
How we got to this line: there have been (other pointers) freed,
so we have to first search the list of recently freed memory for
appropriately sized chunks.
1) this request is not a 'fast bin' size, so skip that codeblock
2) it's not a small request, so skip the smallbin check
3) so, we consolidate all fastbins. That succeeds.
4) We enter a while loop, as described by this comment:
/* Process recently freed or remaindered chunks, taking one only if it
is exact fit, or, if this a small request, the chunk is remainder from
the most recent non-exact fit. Place other traversed chunks in bins.
Note that this step is the only place in any routine where chunks are
placed in bins. */
while ( (victim = unsorted_chunks(av)->bk) != unsorted_chunks(av)) {
bck = victim->bk;
size = chunksize(victim);
...(not a small request, so skip the next codeblock)...
(now we pull "victim" out of the doubly-linked list.)
unsorted_chunks(av)->bk = bck;
bck->fd = unsorted_chunks(av);
And it's here that the error occurs: trying to hook up the forward
pointer in victim's predecessor to point to victim's successor.
The problem is, 'victim' is full of garbage. Supposedly this free'd
chunk of memory is 808,464,432 bytes long. Its predecessor is also
808,464,432 bytes long. And its predecessor and successor are both
located at 0x30303030. Which is bogus, becuase dlmalloc hasn't obtained
that region of memory from the system (and besides, 0x30303030 is
suspiciously like "")
So it looks like glib's test program has clobbered out-of-bounds memory
in a given malloc'ed block -- but only a few bytes, enough to clobber
dlmalloc's bookkeeping but not enough to trigger an actual segfaut. And
then it freed th
Re: Heads up: *possible* bug in cygwin
On Wed, 2003-01-01 at 11:45, Charles Wilson wrote: > [...but I can't reproduce the fault on linux. Even if I link in > dlmalloc. Bleah. ElectricFence on linux couldn't find anything > suspicious either.] You might try valgrind. valgrind is *good*. Happy New Year. Rob -- --- GPG key available at: http://users.bigpond.net.au/robertc/keys.txt. --- signature.asc Description: This is a digitally signed message part
convert utility
Is there a convert utility for graphics conversion in cygwin? I tried looking on website and came up empty. Thanks, Wes -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: convert utility
try http://www.google.com It's a search engine. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Wes Szumera Sent: Tuesday, December 31, 2002 8:42 PM To: [EMAIL PROTECTED] Subject: convert utility Is there a convert utility for graphics conversion in cygwin? I tried looking on website and came up empty. Thanks, Wes -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: convert utility
Robert, Yes, I know what google is. Between www.google.com and groups.google.com, I tend to find most of what I want to get a line on. What caused me a problem in searching, is that convert is a rather common word. From what I was told by an acquainance on a non computer list, imagine that, since my initial post is this is part of imagemagick. Currently downloading it so my question should be resolved assuming I can get it to compile ;) Happy New Year to all, Wes From: "Robert McNulty Junior" <[EMAIL PROTECTED]> To: "Wes Szumera" <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> Subject:RE: convert utility Date sent: Tue, 31 Dec 2002 21:04:02 -0600 > try http://www.google.com > It's a search engine. > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf > Of Wes Szumera > Sent: Tuesday, December 31, 2002 8:42 PM > To: [EMAIL PROTECTED] > Subject: convert utility > > > Is there a convert utility for graphics conversion in cygwin? I tried > looking on website and came up empty. > > Thanks, > > Wes > > -- > Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple > Bug reporting: http://cygwin.com/bugs.html > Documentation: http://cygwin.com/docs.html > FAQ: http://cygwin.com/faq/ > > > > > > -- > Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple > Bug reporting: http://cygwin.com/bugs.html > Documentation: http://cygwin.com/docs.html > FAQ: http://cygwin.com/faq/ > -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
gnu tar opens tgz's with file times in the future
Hello, I'm gnu-tarring files with tar version 1.13.25 on solaris, then untarring with the same version on cygwin. The files are dated 2002-12-31 18:09:xx in the tgz on solaris. When I sftp them to cygwin, the tar programs shows the files to be dated 2003-01-01 03:09.xx. But typing "date" at the cygwin prompt shows the computer clock to be right i.e. Tue Dec. 31 2002. Cygcheck gives: cygutils1.1.3-1 cygwin 1.3.17-1 I'm using Win2K with SP3. Thanks for any pointers. -- Fred Ma, [EMAIL PROTECTED] Carleton University, Dept. of Electronics 1125 Colonel By Drive, Ottawa, Ontario Canada, K1S 5B6 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
SOLVED: gnu tar opens tgz's with file times in the future
Shing-Fat Fred Ma wrote: Hello, I'm gnu-tarring files with tar version 1.13.25 on solaris, then untarring with the same version on cygwin. The files are dated 2002-12-31 18:09:xx in the tgz on solaris. When I sftp them to cygwin, the tar programs shows the files to be dated 2003-01-01 03:09.xx. But typing "date" at the cygwin prompt shows the computer clock to be right i.e. Tue Dec. 31 2002. It was the time zone not set right on the PC. Didn't know gnu tar was made to compensate for time zones.. Fred -- Fred Ma, [EMAIL PROTECTED] Carleton University, Dept. of Electronics 1125 Colonel By Drive, Ottawa, Ontario Canada, K1S 5B6 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
