ugly truetype fonts
(this must be a FAQ, only I can't find an answer). so: I went into the /windows/fonts directory. I've created a fonts.dir file there (tried ttmkfdir and mkfontdir/mkfontscale, same difference). did xset +fp /windows/fonts/; xset fp rehash. ugliness ensued. note: I'm not talking about Gnome or KDE, since those modern things render their fonts without using the X server. I'm talking about Emacs, mostly. the X server over at my Debian box shows the same fonts in the same apps just fine. I tried looking there to find the important difference, but despaired at the sight of defoma... any suggestions? regards, --m -- By filing this bug report, you have challenged the honor of my family. Prepare to die! -- Klingon Programmer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: xWin/Startx Messages re-direction
If this can help, I have solved running startx from bash (Cygwin.bat) in this way startx 2/dev/null Cheers, Angelo. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
winsup/cygwin ChangeLog dll_init.cc
CVSROOT:/cvs/uberbaum Module name:winsup Changes by: [EMAIL PROTECTED] 2006-05-27 18:50:05 Modified files: cygwin : ChangeLog dll_init.cc Log message: * dll_init.cc (dll_dllcrt0): Call _my_tls.init_exception_handler if we've finished initializing (Thanks to Gary Zablackis for noticing this problem). Just use cygwin_finished_initializing rather than defining a separate variable. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/ChangeLog.diff?cvsroot=uberbaumr1=1.3519r2=1.3520 http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/dll_init.cc.diff?cvsroot=uberbaumr1=1.49r2=1.50
winsup/cygwin dll_init.cc
CVSROOT:/cvs/uberbaum Module name:winsup Changes by: [EMAIL PROTECTED] 2006-05-27 18:53:36 Modified files: cygwin : dll_init.cc Log message: add missing comment Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/dll_init.cc.diff?cvsroot=uberbaumr1=1.50r2=1.51
winsup/cygwin ChangeLog thread.cc
CVSROOT:/cvs/uberbaum Module name:winsup Changes by: [EMAIL PROTECTED] 2006-05-27 19:00:36 Modified files: cygwin : ChangeLog thread.cc Log message: * thread.cc (verifyable_object_isvalid): Check for NULL specifically. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/ChangeLog.diff?cvsroot=uberbaumr1=1.3520r2=1.3521 http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/thread.cc.diff?cvsroot=uberbaumr1=1.198r2=1.199
winsup/cygwin ChangeLog dll_init.cc
CVSROOT:/cvs/uberbaum Module name:winsup Changes by: [EMAIL PROTECTED] 2006-05-27 22:55:58 Modified files: cygwin : ChangeLog dll_init.cc Log message: * dll_init.cc (dll_dllcrt0): Previous change didn't work very well with fork. Semi-revert it but change name of variable to something that makes better sense. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/ChangeLog.diff?cvsroot=uberbaumr1=1.3521r2=1.3522 http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/dll_init.cc.diff?cvsroot=uberbaumr1=1.51r2=1.52
Re: Patch for silent crash with Cygwin1.dll v 1.5.19-4
On Thu, Apr 13, 2006 at 12:24:56PM -0400, Christopher Faylor wrote: On Thu, Apr 13, 2006 at 05:48:22AM -0700, Gary Zablackis wrote: The exception handler is supposed to be initialized in _cygtls::init_thread which is called from initialize_main_tls. Why is that not happening? It does happen. However, later on when the program calls dlopen () (which will happen, e.g., when a python program imports a dll), LoadLibrary () gets called. LoadLibrary () then installs its own exception handler. The MS exception handler does NOT pass control back to the Cygwin exception handler (it is not obligated to). You haven't proved that the cygwin exception handler is actually installed at the time when you are reporting problems. Repeating that it does happen is not a proof. What is causing our problem is that when LoadLibrary () loads a dll, the following sequence of events occurs (NOTE: I have left out some of the intervening calls in the following sequence): [EMAIL PROTECTED] () calls dll_dllcrt0 () which calls dll::init() which calls per_module::run_ctors () which calls pthread::once () which calls pthread_key_create () which calls verifyably_object_isvalid () which has the code: myfault efault; if (efault.faulted ()) return INVALID_OBJECT; ... if ((*object)-magic != magic) return INVALID_OBJECT; return VALID_OBJECT; This last bit generates an exception which gets handled by the MS exception handler which decides the error must be fatal to the loading of the dll and sends us back to dlopen (). There *really* is no reason to repeat this. It has been explained many times. One thing missing from the above, however, is something which shows that the cygwin exception handler is actually installed at the point when this all occurs. I took some time today to see if my assumption was true and, yes, it is possible that this function will be called before cygwin has completed its installation, meaning that it is not safe to use _my_tls. I've also verified that, as you say, when this function is called, there are a bunch of other exception handlers installed before Cygwin's. So, I've installed a variation of your patch in CVS. Maybe this will fix all of the problems people are reporting with DLLs. cgf
Re: sh script works, zsh script doesn't
There is nothing wrong with this mail list, although it may not conform to your personal preference. This list does not dictate to the sender where replies will go. It leaves that up to the sender. If posters want email to go to the list rather than to them, it's simply a matter of setting the Reply-To field to point to the list. For those that want to make sure that they always reply to the list, simply use Reply-All. It's that simple and gives everyone full control over how their email is directed. IMO, that's far better than a heavy-handed rule enforced by the list administrator, but then that's my personal preference, which matters not either. ;-) Larry Hall http://www.rfk.com You are the first one, so far, that I've responded to that actually set the reply to go back to the list. As a result, replies are going back to the sender only. I am on several mail lists and this is the only one that defaults to the sender, not the list, hence the ease in forgetting to change the reply as to where it is going. You are right, our mileage is varying :-) MB -- e-mail: [EMAIL PROTECTED]/~\ The ASCII \ / Ribbon Campaign [So it's true, scythe matters. Willow 5/12/03] X Against Visit - URL: http://vidiot.com/ / \ HTML Email -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Source C-code for shell (bash) that processes an asterisk as a special symbol
Igor Peshansky [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] On Thu, 25 May 2006, Alex Vinokur wrote: We have mini-shell that doesn't process an asterisk '*' as a special symbol. Is there any free source C-code on Cygwin that implements that processing? If I understand your question correctly, there are at least 4 different sources for shells, plus various other programs (e.g., make). What you're looking for is called wildcard processing. Is there any free source C-code on Cygwin that implements wildcard processing? Beware of licensing issues, though. [snip] -- Alex Vinokur email: alex DOT vinokur AT gmail DOT com http://mathforum.org/library/view/10978.html http://sourceforge.net/users/alexvn -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Cygwin: texi2dvi stumbles over texinfo.tex
Hi Karl, Christopher,
* Karl Berry wrote on Sat, May 27, 2006 at 01:21:16AM CEST:
[Excluding cygwin, I doubt they care about this part.]
Oh yes they will care especially about this part. ;-)
$ texindex ./main.au ./main.cp ./main.pg ./main.sb
Segmentation fault (core dumped)
Regrettably, with both the texindex in the released 4.8, and the
texindex from current CVS, I get no seg fault on GNU/Linux (x86).
That's because the bug isn't in GNU texinfo-4.8, but in the Cygwin
package texinfo-4.8-2.
* Christopher Faylor wrote on Fri, May 26, 2006 at 07:28:13AM CEST:
That's apparently a call to mktemp, although I can't tell what's causing
the problem.
Setting the CYGWIN environment variable to error_start:gdb might help
with finding what the argument to mktemp is.
Thanks for those hints. It turns out to be mktemp.
Running under gdb (or with CYGWIN set accordingly) doesn't help much if
you don't have source and debugging symbols are not compiled in. So I
learned that Cygwin allows to install source packages, rebuilt
texinfo-4.8-2, and also built the pristine texinfo-4.8 from gnu.org.
The latter worked fine, the former crashes. The diff between both is
shown at the end of this message.
The obvious bug is
+ tempbase = mktemp (txidxXX);
as mktemp changes the string it gets a pointer to, but here it gets a
pointer to potentially read-only memory. And recent GCCs do put this in
the read-only section of the binary. This can be rewritten to work like
this:
{
static char s[] = txidxXX;
tempbase = mktemp (s);
}
but since the original code works fine on Cygwin, I don't see why the
change shouldn't just be dropped (in case you haven't noticed: texinfo
comes with a mkstemp replacement function, and the configure script will
cause to use that if the system doesn't have one; but also Cygwin
apparently *has* mkstemp -- at least the configure test for it succeeds
-- even though there seems to be no manpage for it).
While at it, here's a chance to reconcile the remaining differences
between the upstream and the Cygwin version:
- CVS texinfo has the findprog function in texi2dvi fixed right (i.e.,
by using $IFS for splitting), but the script needs to initialize IFS
to spacetabnewline at the beginning -- see here for why:
http://lists.gnu.org/archive/html/automake-patches/2006-05/msg8.html
- I don't know about the NULL_DEVICE and the path_sep setting changes
-- you need to hash that out yourself. (For path_sep, you could take
a look at Autoconf's internal _AS_PATH_SEPARATOR_PREPARE macro.
What's wrong with reusing its result, stored in PATH_SEPARATOR?)
Cheers,
Ralf
--- texinfo-4.8/lib/system.h2004-04-26 14:56:57.0 +0100
+++ texinfo-4.8-2/lib/system.h 2006-04-30 03:38:39.00100 +0100
@@ -219,6 +219,8 @@
# ifdef __CYGWIN__
# define DEFAULT_TMPDIR /tmp/
# define PATH_SEP :
+# undef NULL_DEVICE
+# define NULL_DEVICE /dev/null
# else /* O_BINARY !__CYGWIN__ */
# define DEFAULT_TMPDIR c:/
# define PATH_SEP ;
--- texinfo-4.8/util/texi2dvi 2004-12-31 19:03:05.0 +0100
+++ texinfo-4.8-2/util/texi2dvi 2005-04-12 02:47:12.00100 +0100
@@ -1,4 +1,4 @@
-#! /bin/sh
+#! /bin/bash
# texi2dvi --- produce DVI (or PDF) files from Texinfo (or LaTeX) sources.
# $Id: texi2dvi,v 1.34 2004/12/01 18:35:36 karl Exp $
#
@@ -101,13 +101,7 @@
orig_pwd=`pwd`
-# Systems which define $COMSPEC or $ComSpec use semicolons to separate
-# directories in TEXINPUTS.
-if test -n $COMSPEC$ComSpec; then
- path_sep=;
-else
- path_sep=:
-fi
+path_sep=:
# Pacify verbose cds.
CDPATH=${ZSH_VERSION+.}$path_sep
@@ -118,14 +112,8 @@
# return true if program $1 is somewhere in PATH, else false.
#
findprog () {
- foundprog=false
- for dir in `echo $PATH | tr $path_sep `; do
-if test -x $dir/$1; then # does anyone still need test -f?
- foundprog=true
- break
-fi
- done
- $foundprog
+ /usr/bin/which $1 /dev/null 21
+ return $?
}
# Report an error and exit with failure.
--- texinfo-4.8/util/texindex.c 2004-04-11 18:56:47.0 +0100
+++ texinfo-4.8-2/util/texindex.c 2005-10-07 15:43:50.00100 +0100
@@ -99,6 +99,9 @@
/* Directory to use for temporary files. On Unix, it ends with a slash. */
char *tempdir;
+/* Basename for temp files inside of tempdir. */
+char *tempbase;
+
/* Number of last temporary file. */
int tempcount;
@@ -190,6 +193,11 @@
decode_command (argc, argv);
+ /* XXX mkstemp not appropriate, as we need to have somewhat predictable
+ * names. But race condition was fixed, see maketempname.
+ */
+ tempbase = mktemp (txidxXX);
+
/* Process input files completely, one by one. */
for (i = 0; i num_infiles; i++)
@@ -389,21 +397,21 @@
static char *
maketempname (int count)
{
- static char *tempbase = NULL;
char tempsuffix[10];
-
- if (!tempbase)
-{
- int fd;
- tempbase = concat (tempdir, txidxXX);
-
- fd =
Re: Source C-code for shell (bash) that processes an asterisk as a special symbol
Is there any free source C-code on Cygwin that implements wildcard processing? Yes - POSIX requires, and cygwin1.dll provides, glob(). http://www.opengroup.org/onlinepubs/009695399/functions/glob.html -- Eric Blake -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Cygwin G++ bug? - Python Extension module #including iostream dies before initialization
Max Bowsher wrote: Hi, I compiled a C++ Python Extension, and found that it caused the Python interpreter process to silently die (with a *zero* exitcode!) when it attempted to load the extension module. I traced the problem to the line: static ios_base::Init __ioinit; in iostream. It seems that when the module is dlopen()-ed, something involved in this static initializer terminates the process. [snip] Thanks for the simple test case! I was just preparing to try to do this today. This appears related to the signal handling problem that GDB experiences and documented at length. One starting point for this discussion is the thread here: http://www.cygwin.com/ml/cygwin/2006-05/msg00691.html GDB is inserting a signal handler ahead of Cygwin that catches signals used to detect valid/invalid objects and GDB is then failing when it classifies those signals as SIGSEGV. It happens with the iostream usage because of a static initializer that uses a mutex for safety. The fix involved a small change to cygwin along with a small change to GDB so that the exception used to detect a bad pointer by cygwin would not be caught by GDB as a SIGSEGV. The fix side of Cygwin is not yet released (but it is in snapshots) and the fix side of GDB is checked in but can't be released until Cygwin dll is released. Perhaps Python is doing something similar and needs to implement the same change implemented in GDB to the signal handling? Could someone provide a pointer to the GDB change? (Yes, I looked into the change logs for GDB around Feb but nothing stood out as relevant). *http://tinyurl.com/fqpb9 * Would the Python maintainer then consider whether these changes are relevant to Python? Until this is solved, all DLLs that are used by Python and use C++ with iostreams will fail silently in this way. Normally, I keep a snapshot of an older Cygwin release to protect against this kind of regression. Unfortunately, in my exuberance lately I find that my oldest snapshot still exhibits this problem. I have yet to find a way to reliably down rev from the release itself. I tried simply choosing Prev for all packages but unfortunately in my haste didn't note what error message occurred when trying that. Thanks - Jim -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Cygwin G++ bug? - Python Extension module #including iostream dies before initialization
Jim Kleckner wrote: Could someone provide a pointer to the GDB change? The changelog is here: *http://tinyurl.com/rnhjw win32_nat.c is listed here: **http://tinyurl.com/rnhjw The key change diffs appear to be here: **http://tinyurl.com/z5vze * -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Cygwin G++ bug? - Python Extension module #including iostream dies before initialization
Jim Kleckner wrote: This appears related to the signal handling problem that GDB experiences and documented at length. One starting point for this discussion is the thread here: http://www.cygwin.com/ml/cygwin/2006-05/msg00691.html I don't see any way that these two issues are related. GDB is inserting a signal handler ahead of Cygwin that catches signals used to detect valid/invalid objects and GDB is then failing when it classifies those signals as SIGSEGV. It happens with the iostream usage because of a static initializer that uses a mutex for safety. The fix involved a small change to cygwin along with a small change to GDB so that the exception used to detect a bad pointer by cygwin would not be caught by GDB as a SIGSEGV. The fix side of Cygwin is not yet released (but it is in snapshots) and the fix side of GDB is checked in but can't be released until Cygwin dll is released. That is not really true. GDB does not install anything resembling a signal handler. In fact, none of this has anything to do with posix style signals per se, because this happens at a much lower level, at the Windows SEH level. Signals are an artificial construct that are emulated by Cygwin, and don't actually exist on Windows. The way it works is that GDB uses the native windows debug API. Using this API whenever an exception occurs the inferior is halted and control returns to the debugger. The debugger then has the choice of handling the fault (e.g. notifying the user and allowing them to take action) or doing nothing and passing it through to whatever existing handler is in place in the inferior. The only change that was made to GDB was that it was made aware of the memory space that cygwin1.dll is loaded into, and so that it knows to always pass-thru any faults occuring in that space. GDB is still alerted on every one of them, because that is how the Windows debug API works, it just knows to pass-thru any that occur in the cygwin DLL, so that the installed cygwin handler takes care of it. As you can see, this all is contingent upon a program like GDB using the Windows debug API. Without that, the entire issue is irrelevant, so I can't see how this possibly would apply to Python. Could someone provide a pointer to the GDB change? (Yes, I looked into the change logs for GDB around Feb but nothing stood out as relevant). *http://tinyurl.com/fqpb9 * That is the toplevel ChangeLog for the 'src' directory. The only files in that directory are common build infrastructure shared by binutils, gcc, cygwin, newlib, and a bunch of other random stuff. I.e. that is not the place to be looking for such a change. As I mentioned in http://cygwin.com/ml/cygwin/2006-04/msg00936.html the GDB side of the fix was posted in http://sourceware.org/ml/gdb-patches/2006-02/msg00352.html. Until this is solved, all DLLs that are used by Python and use C++ with iostreams will fail silently in this way. I don't know why this Python failure is occuring, but I can't see any way that it is related to the GDB issue, other than the fact that users trying to debug the Python failure might see the GDB failure and think there was some kind of connection when there isn't any. Normally, I keep a snapshot of an older Cygwin release to protect against this kind of regression. Unfortunately, You should google for the Cygwin time machine. But do note that using an older Cygwin DLL with newer packages is a very tricky thing due to API changes; the DLL is only designed to be backwards compatible, not forwards compatible. In the limiting case all binaries on the system must be the same age or older as the Cygwin DLL, and this is not a condition that is guaranteed by simply selecting Prev for everything because the version considered Prev is at the mercy to each package maintainer and follows no overall rules. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
[ANNOUNCEMENT] Updated: texinfo-4.8-3
I've made a new version of 'texinfo' available for installation. This version incorporates a patch from Fedora which should fix the problem mentioned here: http://cygwin.com/ml/cygwin/2006-05/msg00759.html For a brief description of this package, and a listing of the files it contains, see http://cygwin.com/packages/texinfo . 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 keep clicking Next. If you have questions or comments, please send them to the Cygwin mailing list. *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, please use the automated form at: http://cygwin.com/lists.html#subscribe-unsubscribe If this does not work, then look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: [EMAIL PROTECTED] If you need more information on unsubscribing, start reading here: http://sources.redhat.com/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Source C-code for shell (bash) that processes an asterisk as a special symbol
On Fri, May 26, 2006 at 12:39:38PM +0300, Alex Vinokur wrote: Igor Peshansky [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] On Thu, 25 May 2006, Alex Vinokur wrote: We have mini-shell that doesn't process an asterisk '*' as a special symbol. Is there any free source C-code on Cygwin that implements that processing? If I understand your question correctly, there are at least 4 different sources for shells, plus various other programs (e.g., make). What you're looking for is called wildcard processing. Is there any free source C-code on Cygwin that implements wildcard processing? Just the same function that exist on linux: glob(). cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: sh script works, zsh script doesn't
On Sat, May 27, 2006 at 01:25:24AM -0400, Larry Hall (Cygwin) wrote: On 05/26/2006, Vidiot wrote: [Can the listmaster fix the mail list so that it sends the reply back to the list and not to the poster? I sent the e-mail before remembering that this mail list gets it wrong, at least AFAIAC.] There is nothing wrong with this mail list, although it may not conform to your personal preference. This list does not dictate to the sender where replies will go. It leaves that up to the sender. If posters want email to go to the list rather than to them, it's simply a matter of setting the Reply-To field to point to the list. For those that want to make sure that they always reply to the list, simply use Reply-All. It's that simple and gives everyone full control over how their email is directed. IMO, that's far better than a heavy-handed rule enforced by the list administrator, but then that's my personal preference, which matters not either. ;-) All mailing lists on sourceware.org also have a standard Mail-Followup-To setting. Another way to look at this is that this project and this mailing list have been around for many years so it's likely that this subject has been discussed many times and a simple please change the list to fit my needs request doesn't make much sense in this context. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: sh script works, zsh script doesn't
On Sat, May 27, 2006 at 01:57:36AM -0500, Vidiot wrote: There is nothing wrong with this mail list, although it may not conform to your personal preference. This list does not dictate to the sender where replies will go. It leaves that up to the sender. If posters want email to go to the list rather than to them, it's simply a matter of setting the Reply-To field to point to the list. For those that want to make sure that they always reply to the list, simply use Reply-All. It's that simple and gives everyone full control over how their email is directed. IMO, that's far better than a heavy-handed rule enforced by the list administrator, but then that's my personal preference, which matters not either. ;-) Larry Hall http://www.rfk.com You are the first one, so far, that I've responded to that actually set the reply to go back to the list. As a result, replies are going back to the sender only. I am on several mail lists and this is the only one that defaults to the sender, not the list, hence the ease in forgetting to change the reply as to where it is going. There is something wrong with your email client, then. You should investigate that. Again, this site isn't new. The mailing lists here are not new. This issue has been discussed many times and the policy was decided long ago. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Cygwin G++ bug? - Python Extension module #including iostream dies before initialization
Brian Dessent wrote: As you can see, this all is contingent upon a program like GDB using the Windows debug API. Without that, the entire issue is irrelevant, so I can't see how this possibly would apply to Python. Thanks for explaining how the Windows debug API is the one actually catching the exception rather than GDB directly changing how exceptions are caught. This is useful. I will be surprised if there doesn't turn out to be some commonality between the pthread_mutex_init issue and something Python is doing either directly or via the use of dlopen(). Thanks - Jim -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Cygwin: texi2dvi stumbles over texinfo.tex
On Sat, May 27, 2006 at 10:05:20AM +0200, Ralf Wildenhues wrote: Hi Karl, Christopher, * Karl Berry wrote on Sat, May 27, 2006 at 01:21:16AM CEST: [Excluding cygwin, I doubt they care about this part.] Oh yes they will care especially about this part. ;-) $ texindex ./main.au ./main.cp ./main.pg ./main.sb Segmentation fault (core dumped) Regrettably, with both the texindex in the released 4.8, and the texindex from current CVS, I get no seg fault on GNU/Linux (x86). That's because the bug isn't in GNU texinfo-4.8, but in the Cygwin package texinfo-4.8-2. * Christopher Faylor wrote on Fri, May 26, 2006 at 07:28:13AM CEST: That's apparently a call to mktemp, although I can't tell what's causing the problem. Setting the CYGWIN environment variable to error_start:gdb might help with finding what the argument to mktemp is. Thanks for those hints. It turns out to be mktemp. Running under gdb (or with CYGWIN set accordingly) doesn't help much if you don't have source and debugging symbols are not compiled in. So I learned that Cygwin allows to install source packages, rebuilt texinfo-4.8-2, and also built the pristine texinfo-4.8 from gnu.org. The latter worked fine, the former crashes. The diff between both is shown at the end of this message. Thanks very much for looking into it. I released a new version of texinfo last night. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Source C-code for shell (bash) that processes an asterisk as a special symbol
Eric Blake [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Is there any free source C-code on Cygwin that implements wildcard processing? Yes - POSIX requires, and cygwin1.dll provides, glob(). http://www.opengroup.org/onlinepubs/009695399/functions/glob.html -- Eric Blake Thanks. Also http://www.devdaily.com/scw/c/cygwin/src/newlib/libc/sys/linux/include/glob.h.shtml But I didn't fint out glob.c on Cygwin. -- Alex Vinokur email: alex DOT vinokur AT gmail DOT com http://mathforum.org/library/view/10978.html http://sourceforge.net/users/alexvn -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Source C-code for shell (bash) that processes an asterisk as a special symbol
Christopher Faylor [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] On Fri, May 26, 2006 at 12:39:38PM +0300, Alex Vinokur wrote: [snip] Is there any free source C-code on Cygwin that implements wildcard processing? Just the same function that exist on linux: glob(). [snip] I didn't find out free source glob.c via Google. P.S. I don't have Linux. -- Alex Vinokur email: alex DOT vinokur AT gmail DOT com http://mathforum.org/library/view/10978.html http://sourceforge.net/users/alexvn -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: sh script works, zsh script doesn't
On 05/27/2006, Christopher Faylor wrote: On Sat, May 27, 2006 at 01:57:36AM -0500, Vidiot wrote: There is nothing wrong with this mail list, although it may not conform to your personal preference. This list does not dictate to the sender where replies will go. It leaves that up to the sender. If posters want email to go to the list rather than to them, it's simply a matter of setting the Reply-To field to point to the list. For those that want to make sure that they always reply to the list, simply use Reply-All. It's that simple and gives everyone full control over how their email is directed. IMO, that's far better than a heavy-handed rule enforced by the list administrator, but then that's my personal preference, which matters not either. ;-) Larry Hall http://www.rfk.com You are the first one, so far, that I've responded to that actually set the reply to go back to the list. As a result, replies are going back to the sender only. I am on several mail lists and this is the only one that defaults to the sender, not the list, hence the ease in forgetting to change the reply as to where it is going. I may be the first but I'm not the only. :-) I set my Reply-To to the list because I want all replies to my posts to go to the list. I don't want a copy coming to me and the list if someone does a Reply-All and I don't want to have the discussion taken off-list and come only to me personally if someone chooses just Reply. Setting the Reply-To field is an easy way to make sure that my intent is preserved without people replying to my posts having to think about it. There is something wrong with your email client, then. You should investigate that. Either that or you are just hitting Reply instead of Reply-All. Further discussion of this is OT for this list though so if you have further comments that you'd like to share, you'll need to follow-up on the cygwin-talk list. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 838 Washington Street (508) 893-9889 - FAX Holliston, MA 01746 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Source C-code for shell (bash) that processes an asterisk as a special symbol
On Sat, May 27, 2006 at 08:34:53PM +0300, Alex Vinokur wrote: Eric Blake [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Is there any free source C-code on Cygwin that implements wildcard processing? Yes - POSIX requires, and cygwin1.dll provides, glob(). http://www.opengroup.org/onlinepubs/009695399/functions/glob.html Thanks. Also http://www.devdaily.com/scw/c/cygwin/src/newlib/libc/sys/linux/include/glob.h.shtml But I didn't fint out glob.c on Cygwin. You aren't looking too hard, then. However, just *use* the function like you would any other function. There is no need to locate the source code to use it. You don't need open.c to use open. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Source C-code for shell (bash) that processes an asterisk as a special symbol
On Sat, May 27, 2006 at 08:38:57PM +0300, Alex Vinokur wrote: Christopher Faylor [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] On Fri, May 26, 2006 at 12:39:38PM +0300, Alex Vinokur wrote: [snip] Is there any free source C-code on Cygwin that implements wildcard processing? Just the same function that exist on linux: glob(). [snip] I didn't find out free source glob.c via Google. Um. If you type in glob.c into google *the*first*hit* is a free implementation. Typing glob.1 gets you a man page. Again: just use the function. P.S. I don't have Linux. Cygwin emulates linux. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Source C-code for shell (bash) that processes an asterisk as a special symbol
Thanks. Also http://www.devdaily.com/scw/c/cygwin/src/newlib/libc/sys/linux/include/glob.h.sh tml But I didn't fint out glob.c on Cygwin. Then you didn't look hard enough. Cygwin sources are kept in CVS, and you can browse CVS online. http://cygwin.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/glob.c?cvsroot=src -- Eric Blake -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Automated Cygwin install.
Hi Igor. Igor Peshansky [EMAIL PROTECTED] writes: The file is called /etc/setup/installed.db. Simply copy it to the same location on the other machine, then edit it and change all version numbers to 0.0-0. That will ensure that you install the latest versions of the same set of packages. Thank you very much. That is kind of what I was looking for. But I will definitely consider the alternative suggested methods as well. One last thing on this method, can a ensure that a specific version number is being installed (i.e. not the latest one). I consider testing the latest on one machine, then I want the same stuff on the others (without surprises introduced in later versions). The other is to set up a local mirror with a setup.ini that includes all the packages you want installed in the Base category. Running 'setup.exe' and choosing that mirror will install the new list of default packages. See the setup home page for details on this (sorry, no direct pointer). I belive you mean this page: http://www.cygwin.com/cygwin-ug-net/setup-net.html Correct. Actually, you don't really need the whole setup.ini -- it's enough to have one dummy package (empty bin tarball, empty source) in the Base category, which depends on all the packages you want. You can use /etc/setup/installed.db as the source for the list of packages (or run cygcheck -cd, which will print that list to stdout). If you choose to go with this method, you'll need to select one of the official mirrors as well). There are two more ways: one is to set up a local mirror/shared package repository that contains only the packages you want installed, and then select install everything from that mirror/repository, and the other is to use the experimental build of setup mentioned in http://cygwin.com/ml/cygwin-apps/2006-03/msg00109.html. Thank you very much for opening my eyes to other ways of doing this. Would it be an idea to have my question on the cygwin FAQ. Jarl -- Jarl Friis Softace ApS Omøgade 8, 2.sal 2100 København Ø. Denmark Phone: +45 26 13 20 90 E-mail: [EMAIL PROTECTED] LinkedIn: https://www.linkedin.com/in/jarlfriis -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: sh script works, zsh script doesn't
Either that or you are just hitting Reply instead of Reply-All. Further discussion of this is OT for this list though so if you have further comments that you'd like to share, you'll need to follow-up on the cygwin-talk list. Larry Hall http://www.rfk.com Correct, as 99.9% of the e-mail that I get and respond to is a simple reply. Old habits die hard when that is the way I answer the e-mail that I get, and I get tons. I'll just have to suffer through :-) :-) We now return you to your regularly scheduled program. BTW, having cygwin on the XP box has been a lifesaver, figuratively speaking. As far as I am concerned, the XP's GUI idea of setting up timer jobs is extremely cumbersome. Being able to use cron to run a script to start a program to run a DVB-S (satellite broadcast capture) card is extremely useful. Also being able to use split to break up files bigger then 4GB, in order to save them on DVD-ROM is a big plus. I gew up with BSD 4.x, from way back and rather use Unix/Linux any day over Windblows. Kudos to all that have developed cygwin. MB -- e-mail: [EMAIL PROTECTED]/~\ The ASCII \ / Ribbon Campaign [So it's true, scythe matters. Willow 5/12/03] X Against Visit - URL: http://vidiot.com/ / \ HTML Email -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Automated Cygwin install.
On 05/27/2006, Jarl Friis wrote: Igor Peshansky pechtcha at cs dot nyu dot edu writes: ^^^ http://cygwin.com/acronyms/#PCYMTNQREAIYR. Thanks. The file is called /etc/setup/installed.db. Simply copy it to the same location on the other machine, then edit it and change all version numbers to 0.0-0. That will ensure that you install the latest versions of the same set of packages. Thank you very much. That is kind of what I was looking for. But I will definitely consider the alternative suggested methods as well. One last thing on this method, can a ensure that a specific version number is being installed (i.e. not the latest one). I consider testing the latest on one machine, then I want the same stuff on the others (without surprises introduced in later versions). If you want the same versions as you've installed on another machine, you'll need to point 'setup.exe' to your local package directory and install using that rather than from a mirror. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 838 Washington Street (508) 893-9889 - FAX Holliston, MA 01746 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: 1.5.19: changes have broken Qt3
[ I realized that a couple of points in this thread were never addressed -- we
sort of got side tracked on the GDB issue. I just want to reply to these points
and try to convince you that this bug you see does not exist. People have a
tendency to point to the archives and say lookee, it's broken if the thread
does not come to a result. ]
Ralf Habacker wrote:
You said that the testcase runs, yes, but do you have tried to debug the
cygwin dll with this exception handling. Please start the above
mentioned testcase in gdb and enter
b main
r
b pthread_mutexattr::pthread_mutexattr()
c
This breakpoint is never reached (at least in released gdb) and makes it
hard to debug cygwin's threading stuff, probably impossible in this area.
The breakpoint does not fire, correct. But that is because pthread_mutexattr's
constructor is empty (other than the initialization list):
pthread_mutexattr::pthread_mutexattr ():verifyable_object
(PTHREAD_MUTEXATTR_MAGIC),
pshared (PTHREAD_PROCESS_PRIVATE), mutextype (PTHREAD_MUTEX_ERRORCHECK)
{
}
If instead you set a breakpoint for the desired line that calls the constructor
(in this case, thread.cc:3027) then it does fire. And if you use a CVS GDB you
get no spurious faults either.
This means to be able to debug the cygwin dll in this area I have to
recompile a special cygwin version with something like below mentioned.:
/* FIXME: write and test process shared mutex's. */
extern C int
pthread_mutexattr_init (pthread_mutexattr_t *attr)
old:
if (pthread_mutexattr::is_good_object (attr))
return EBUSY;
new:
if (attr pthread_mutexattr::is_good_object (attr))
return EBUSY;
This is totally useless. In order for if (attr) to be false, the function
would have had to been called as pthread_mutexattr_init (NULL) rather than
pthread_mutexattr_init (some_as_yet_uninitialized_variable). Furthermore, if
attr really were false, then the next line:
*attr = new pthread_mutexattr ();
would cause a NULL dereference which would not be caught, causing the program to
crash and burn. The function must always be passed a valid pointer; the thing
it points to might be uninitialized though.
Let's walk through the complete series of events that happens in the testcase
below:
pthread_mutexattr_t mxAttr;
assert(pthread_mutexattr_init(mxAttr) == 0);
This is the thing that you claim is broken, however if you run this testcase
from a regular prompt (outside GDB) it does not assert, and in fact the
mutexattr is correctly initialized. (And if you do run it in a recent GDB it
does not assert nor fault either.)
Let's look at the entire chain of code involved here:
extern C int
pthread_mutexattr_init (pthread_mutexattr_t *attr)
{
if (pthread_mutexattr::is_good_object (attr))
return EBUSY;
*attr = new pthread_mutexattr ();
if (!pthread_mutexattr::is_good_object (attr))
{
delete (*attr);
*attr = NULL;
return ENOMEM;
}
return 0;
}
inline bool
pthread_mutexattr::is_good_object (pthread_mutexattr_t const * attr)
{
if (verifyable_object_isvalid (attr, PTHREAD_MUTEXATTR_MAGIC) !=
VALID_OBJECT)
return false;
return true;
}
static inline verifyable_object_state
verifyable_object_isvalid (void const * objectptr, long magic, void
*static_ptr1, void *static_ptr2, void *static_ptr3)
{
verifyable_object **object = (verifyable_object **) objectptr;
myfault efault;
if (efault.faulted ())
return INVALID_OBJECT;
if ((static_ptr1 *object == static_ptr1) ||
(static_ptr2 *object == static_ptr2) ||
(static_ptr3 *object == static_ptr3))
return VALID_STATIC_OBJECT;
if ((*object)-magic != magic)
return INVALID_OBJECT;
return VALID_OBJECT;
}
So, the call chain will look like this:
pthread_mutexattr_init(mxAttr) -
pthread_mutexattr::is_good_object (mxAttr) -
verifyable_object_isvalid (mxAttr, PTHREAD_MUTEXATTR_MAGIC, NULL,NULL,NULL)
Of course, these last two functions will be expanded inline, so this will all
occur in the context of pthread_mutexattr_init. We are at the point in
verifyable_object_isvalid of:
if ((*object)-magic != magic)
Here, object is mxAttr, so *object is mxAttr. But mxAttr is not yet
initialized, so dereferencing it as mxAttr-magic causes a fault. This causes
verifyable_object_isvalid to return INVALID_OBJECT through the if
(efault.faulted ()) branch.
Consequently, the if() condition in pthread_mutexattr::is_good_object is true,
the function returns false, the if() condition at the beginning of
pthread_mutexattr_init is false, and execution continues to the line *attr =
new pthread_mutexattr (), and finally mxAttr is initialized just as we desire.
I hope that I have shown that even though a fault occurs that execution
continues normally and the mutexattr IS initialized correctly.
Brian
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports:
vim7?
Is a cygwin binary of Vim 7.0 coming soon? -- Luis P Caamano Atlanta, GA USA -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: 1.5.19: changes have broken Qt3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dave Korn schrieb: On 24 May 2006 13:19, Ralf Habacker wrote: This breakpoint is never reached (at least in released gdb) and makes it hard to debug cygwin's threading stuff, probably impossible in this area. How many times do you have to be told? The last released gdb is known to not cope with this. IT IS A KNOWN BUG. IT HAS BEEN FIXED. I have downloaded and compiled gdb weekly snapshot (20060522), but there are still problems with tracing after an internal exception occured. I am using testcase mutex1n.c from cvs path src/winsup/testsuite/winsup.api/pthread and set a breakpoint to pthread_mutexattr_init Breakpoint 1, pthread_mutexattr_init (attr=0x404040) at /netrel/src/cygwin-snapshot-20060522-1/winsup/cygwin/cygtls.h:253 1: x/i $eip 0x610b0f07 pthread_mutexattr_init+7: lea 0xff08(%ebp),%esi (gdb) ni snip 0x610b1005 129 in /netrel/src/cygwin-snapshot-20060522-1/winsup/cygwin/thread.cc 1: x/i $eip 0x610b1005 pthread_mutexattr_init+261: cmpl $0xdf0df049,0x4(%eax) (gdb) here the internal exception occurs and gdb is out of sync until the application ends or a later breakpoint is hit. 0x7c91eaf0 in ntdll!LdrDisableThreadCalloutsForDll () from /c/WINDOWS/system32/ntdll.dll 1: x/i $eip 0x7c91eaf0 ntdll!LdrDisableThreadCalloutsForDll+4: mov(%esp),%ebx (gdb) 0x7c91eaf3 in ntdll!LdrDisableThreadCalloutsForDll () from /c/WINDOWS/system32/ntdll.dll 1: x/i $eip 0x7c91eaf3 ntdll!LdrDisableThreadCalloutsForDll+7: push %ecx (gdb) 0x7c91eaf4 in ntdll!LdrDisableThreadCalloutsForDll () from /c/WINDOWS/system32/ntdll.dll 1: x/i $eip 0x7c91eaf4 ntdll!LdrDisableThreadCalloutsForDll+8: push %ebx (gdb) 0x7c91eaf5 in ntdll!LdrDisableThreadCalloutsForDll () from /c/WINDOWS/system32/ntdll.dll 1: x/i $eip 0x7c91eaf5 ntdll!LdrDisableThreadCalloutsForDll+9: call 0x7c9477c1 ntdll!LdrFindCreateProcessManifest+424 (gdb) Program exited normally. (gdb) Regards Ralf -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEeKSToHh+5t8EXncRAgxiAJsHfqsBSME06zaSaMD/kgrQH4GJAgCeMqUp wSedYnMrgNRpkpXRuny/2YE= =1zgp -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
PROBLEM: Internet apps spit out error about not being able to connect to internet + TEMP_SOLUTION
This was the problem before: In Cygwin, when I want to check out source code from cvs, it spits out something that has to do with: cannot create socket. When I want to browse the WWW with lynx, it spits out an error about cannot access the startpage. Now, just recently, when I want to start up X11, it spits out cannot create socket. The internet features worked before some time, but now it is completely blocked! --- BTW, is this a problem with Cygwin or is this a problem with my config? Now, there's a temporary solution who can't seem to reconfigure security software [or their security software won't let them]: NOTE: This will involve you creating a new batch file (.bat). 1. Open Folder Options, click View, and then uncheck Hide file extensions for known file types. 2. Right click on the desktop, point to New, and then click Text Document. 3. Rename it to shell.bat, or just name it whatever, just make sure that the .bat extension is in place. 4. A dialog will appear cautioning you about changing the file type. Ignore it by clicking OK or Yes. 5. Right click the new file you created and click Edit. 6. Notepad will open with a blank file. 7. Please fill the file with these commands: @echo off D: set CYGWINBASE=C:\cygwin set HOME=%CYGWINBASE%\home\[username] set PATH=%PATH%;%CYGWINBASE%\bin chdir=%CYGWINBASE%\bin cmd 8. When you are done, close Notepad. A dialog will appear asking if you want to save; just click Yes. 9. Double-click the .bat file. All these commands will execute, and then it will bring up a normal command prompt. 10.Execute your normal cygwin commands. Note that if you modified the original cygwin.bat file, you may want to put additional arguments in the new .bat file, like I did here: @echo off color 0f D: set CYGWINBASE=D:\LH34IG2HGB\cygwin set HOME=D:\LH34IG2HGB\HOME set VC=D:\LH34IG2HGB\Microsoft Visual Studio\VC set VCVARS=%VC%\vcvarsall.bat set PSDK=D:\LH34IG2HGB\PFILES\Microsoft Platform SDK call %VCVARS% set PATH=%PATH%;%CYGWINBASE%\bin title Mixed-Mode Command Prompt cls chdir=%CYGWINBASE%\bin cmd BTW, with some more investigating, I found out that this problem arose from /usr/bin/sh. Charli -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
autogen/autoconf/gcc-4.2
Current gnu autogen built out of the box after I rebuilt guile from the cygwin sources. It would not build against the cygwin binaries installed from the osu mirror. gcc-4.2 snapshot from gcc.gnu.org accepts this autogen, but still fails autoconf no input file. That doesn't look like a cygwin issue. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: 1.5.19: changes have broken Qt3
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brian Dessent schrieb:
[ I realized that a couple of points in this thread were never addressed -- we
sort of got side tracked on the GDB issue. I just want to reply to these
points
and try to convince you that this bug you see does not exist. People have a
tendency to point to the archives and say lookee, it's broken if the thread
does not come to a result. ]
Ralf Habacker wrote:
You said that the testcase runs, yes, but do you have tried to debug the
cygwin dll with this exception handling. Please start the above
mentioned testcase in gdb and enter
b main
r
b pthread_mutexattr::pthread_mutexattr()
c
This breakpoint is never reached (at least in released gdb) and makes it
hard to debug cygwin's threading stuff, probably impossible in this area.
The breakpoint does not fire, correct. But that is because
pthread_mutexattr's
constructor is empty (other than the initialization list):
pthread_mutexattr::pthread_mutexattr ():verifyable_object
(PTHREAD_MUTEXATTR_MAGIC),
pshared (PTHREAD_PROCESS_PRIVATE), mutextype (PTHREAD_MUTEX_ERRORCHECK)
{
}
If instead you set a breakpoint for the desired line that calls the
constructor
(in this case, thread.cc:3027) then it does fire.
If you take a look on assembler level you will find two constructors and
the breakpoint is set to the wrong one
0x610ad520 _ZN17pthread_mutexattrC2Ev+0: push %ebp
0x610ad560 _ZN17pthread_mutexattrC1Ev+0: push %ebp
(gdb) b pthread_mutexattr::pthread_mutexattr()
Breakpoint 3 at 0x610ad52c: - _ZN17pthread_mutexattrC2Ev
but called is the other one.
0x610b0f7b pthread_mutexattr_init+123:mov%eax,(%esp)
0x610b0f7e pthread_mutexattr_init+126:mov%eax,%ebx
0x610b0f80 pthread_mutexattr_init+128:call 0x610ad560
_ZN17pthread_mutexattrC1Ev
And if you use a CVS GDB you get no spurious faults either.
This means to be able to debug the cygwin dll in this area I have to
recompile a special cygwin version with something like below mentioned.:
/* FIXME: write and test process shared mutex's. */
extern C int
pthread_mutexattr_init (pthread_mutexattr_t *attr)
old:
if (pthread_mutexattr::is_good_object (attr))
return EBUSY;
new:
if (attr pthread_mutexattr::is_good_object (attr))
return EBUSY;
This is totally useless. In order for if (attr) to be false, the function
would have had to been called as pthread_mutexattr_init (NULL) rather than
pthread_mutexattr_init (some_as_yet_uninitialized_variable). Furthermore, if
attr really were false, then the next line:
*attr = new pthread_mutexattr ();
would cause a NULL dereference which would not be caught, causing the program
to
crash and burn. The function must always be passed a valid pointer; the thing
it points to might be uninitialized though.
Let's walk through the complete series of events that happens in the testcase
below:
pthread_mutexattr_t mxAttr;
assert(pthread_mutexattr_init(mxAttr) == 0);
This is the thing that you claim is broken, however if you run this testcase
from a regular prompt (outside GDB) it does not assert, and in fact the
mutexattr is correctly initialized. (And if you do run it in a recent GDB it
does not assert nor fault either.)
Let's look at the entire chain of code involved here:
extern C int
pthread_mutexattr_init (pthread_mutexattr_t *attr)
{
if (pthread_mutexattr::is_good_object (attr))
return EBUSY;
*attr = new pthread_mutexattr ();
if (!pthread_mutexattr::is_good_object (attr))
{
delete (*attr);
*attr = NULL;
return ENOMEM;
}
return 0;
}
inline bool
pthread_mutexattr::is_good_object (pthread_mutexattr_t const * attr)
{
if (verifyable_object_isvalid (attr, PTHREAD_MUTEXATTR_MAGIC) !=
VALID_OBJECT)
return false;
return true;
}
static inline verifyable_object_state
verifyable_object_isvalid (void const * objectptr, long magic, void
*static_ptr1, void *static_ptr2, void *static_ptr3)
{
verifyable_object **object = (verifyable_object **) objectptr;
myfault efault;
if (efault.faulted ())
return INVALID_OBJECT;
if ((static_ptr1 *object == static_ptr1) ||
(static_ptr2 *object == static_ptr2) ||
(static_ptr3 *object == static_ptr3))
return VALID_STATIC_OBJECT;
if ((*object)-magic != magic)
return INVALID_OBJECT;
return VALID_OBJECT;
}
So, the call chain will look like this:
pthread_mutexattr_init(mxAttr) -
pthread_mutexattr::is_good_object (mxAttr) -
verifyable_object_isvalid (mxAttr, PTHREAD_MUTEXATTR_MAGIC, NULL,NULL,NULL)
Of course, these last two functions will be expanded inline, so this will all
occur in the context of pthread_mutexattr_init. We are at the point in
verifyable_object_isvalid of:
if ((*object)-magic != magic)
Here, object is mxAttr, so
flex?
Hi. i installed everything in order to compile and still i get these errors..please help. [EMAIL PROTECTED] ~/muh-2.2 $ make make all-recursive make[1]: Entering directory `/home/siege/muh-2.2' Making all in src make[2]: Entering directory `/home/siege/muh-2.2/src' gcc -g -O2 -Wall -o muh.exe ascii.o channels.o commands.o dcc.o dlink.o igno re.o irc.o log.o match.o muh.o perm.o table.o tools.o parser.o lexer.o common.o -lcrypt muh.o: In function `read_cfg': /home/siege/muh-2.2/src/muh.c:106: undefined reference to `_yyin' /home/siege/muh-2.2/src/muh.c:110: undefined reference to `_yyrestart' /home/siege/muh-2.2/src/muh.c:115: undefined reference to `_yyin' /home/siege/muh-2.2/src/muh.c:108: undefined reference to `_yyin' /home/siege/muh-2.2/src/muh.c:110: undefined reference to `_yyrestart' /home/siege/muh-2.2/src/muh.c:112: undefined reference to `_yyin' /home/siege/muh-2.2/src/muh.c:115: undefined reference to `_yyin' parser.o: In function `yyparse': /home/siege/muh-2.2/src/parser.c:1293: undefined reference to `_yylex' collect2: ld returned 1 exit status make[2]: *** [muh.exe] Error 1 make[2]: Leaving directory `/home/siege/muh-2.2/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/siege/muh-2.2' make: *** [all] Error 2 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Newer cygwin packages available
There are some newer cygwin packages available from the original vendor(s) that I would like to bring to your attention: --- |Package name|setup.exe version|vendor's version| |GTK+2 |2.6.10 |2.9.1 | |glib2 |2.6.6|2.11.1 | |pango |1.8.1|1.13.1 | |ATK |1.9.1|1.10.3 | --- Charli -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: flex?
ask wrote: Hi. i installed everything in order to compile and still i get these errors..please help. [EMAIL PROTECTED] ~/muh-2.2 $ make make all-recursive make[1]: Entering directory `/home/siege/muh-2.2' Making all in src make[2]: Entering directory `/home/siege/muh-2.2/src' gcc -g -O2 -Wall -o muh.exe ascii.o channels.o commands.o dcc.o dlink.o igno re.o irc.o log.o match.o muh.o perm.o table.o tools.o parser.o lexer.o common.o -lcrypt muh.o: In function `read_cfg': /home/siege/muh-2.2/src/muh.c:106: undefined reference to `_yyin' /home/siege/muh-2.2/src/muh.c:110: undefined reference to `_yyrestart' /home/siege/muh-2.2/src/muh.c:115: undefined reference to `_yyin' /home/siege/muh-2.2/src/muh.c:108: undefined reference to `_yyin' /home/siege/muh-2.2/src/muh.c:110: undefined reference to `_yyrestart' /home/siege/muh-2.2/src/muh.c:112: undefined reference to `_yyin' /home/siege/muh-2.2/src/muh.c:115: undefined reference to `_yyin' parser.o: In function `yyparse': /home/siege/muh-2.2/src/parser.c:1293: undefined reference to `_yylex' collect2: ld returned 1 exit status make[2]: *** [muh.exe] Error 1 make[2]: Leaving directory `/home/siege/muh-2.2/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/siege/muh-2.2' make: *** [all] Error 2 But you don't show where flex failed. Do you mean you are missing -lfl in this command? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Newer cygwin packages available
Charli Li wrote: There are some newer cygwin packages available from the original vendor(s) that I would like to bring to your attention: --- |Package name|setup.exe version|vendor's version| |GTK+2 |2.6.10 |2.9.1 | |glib2 |2.6.6|2.11.1 | |pango |1.8.1|1.13.1 | |ATK |1.9.1|1.10.3 | --- Charli Did you test them? Offering to become cygwin maintainer if consensus develops? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: 1.5.19: changes have broken Qt3
Ralf Habacker wrote: There is only one case where I still believe that there may be a problem. If a pthread_mutexattr_t is constructed on the stack and the magic class membere is be exactly the predefined value, pthread_mutexattr_init() will return EBUSY, although there is no good object, it is only by random. I believe this has been hashed out on the list before as well. I think the conclusion is that the app needs to check the return values so that it can cope with this case. I don't have a link to the thread handy. My currently conclusion is that there are rare conditions in the pthread and/or exception stuff, which corrupts the stack and that there is more work required to find out the problem. This I don't doubt, but I think it will just require someone digging in. If you can whittle down the qt3 stack overflow crash to a testcase, then there's a good chance someone reading will give it more attention. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: vim7?
Luis P Caamano wrote: Is a cygwin binary of Vim 7.0 coming soon? Not immediately, no. The maintainer is currently away. On her return, I'm sure it's something she will look at. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 838 Washington Street (508) 893-9889 - FAX Holliston, MA 01746 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Newer cygwin packages available
Tim Prince wrote: Charli Li wrote: There are some newer cygwin packages available from the original vendor(s) that I would like to bring to your attention: --- |Package name|setup.exe version|vendor's version| |GTK+2 |2.6.10 |2.9.1 | The gtk website http://www.gtk.org/download/ says The current stable version of GTK+ is 2.8. Following the download link for 2.8, we see: LATEST-ATK-1.10.3 LATEST-GLIB-2.8.6 LATEST-GTK-2.8.18 LATEST-PANGO-1.10.4 So, IF the current maintainer wants to update, and only if, then I'd recommend these versions, not the ones you've listed (well, you got atk correct), |glib2 |2.6.6|2.11.1 | |pango |1.8.1|1.13.1 | |ATK |1.9.1|1.10.3 | Just because the gtk.org front page announces availability of something, does NOT mean it is the latest *stable* release. GTK is really really bad about distinguishing stable vs. development on their front page (heck, there are 4 -- count'em, 4 -- ongoing development series of glib: 2.8 (stable), 2.9, 2.10, and 2.11. Each of which appears in a directory with different ongoing development versions of pango (and sometimes gtk and atk, as well). Because of this, my opinion of the gtk developers is pretty low -- it appears to be one of the most chaotic projects ever conceived. So I'd really REALLY suggest staying with the stable version...or maybe a little behind it G. (also, anything newer than 2.6 requires cairo and, optionally, glitz...which may or may not be very stable on cygwin -- I make no claim either way). Did you test them? Offering to become cygwin maintainer if consensus develops? Indeed. -- Chuck -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Newer cygwin packages available
All this info I got was from ftp://ftp.gtk.org/pub. BTW, that webpage you referenced might be misleading. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Charles Wilson Sent: Saturday, May 27, 2006 9:26 PM To: cygwin@cygwin.com Subject: Re: Newer cygwin packages available Tim Prince wrote: Charli Li wrote: There are some newer cygwin packages available from the original vendor(s) that I would like to bring to your attention: --- |Package name|setup.exe version|vendor's version| |GTK+2 |2.6.10 |2.9.1 | The gtk website http://www.gtk.org/download/ says The current stable version of GTK+ is 2.8. Following the download link for 2.8, we see: LATEST-ATK-1.10.3 LATEST-GLIB-2.8.6 LATEST-GTK-2.8.18 LATEST-PANGO-1.10.4 So, IF the current maintainer wants to update, and only if, then I'd recommend these versions, not the ones you've listed (well, you got atk correct), |glib2 |2.6.6|2.11.1 | |pango |1.8.1|1.13.1 | |ATK |1.9.1|1.10.3 | Just because the gtk.org front page announces availability of something, does NOT mean it is the latest *stable* release. GTK is really really bad about distinguishing stable vs. development on their front page (heck, there are 4 -- count'em, 4 -- ongoing development series of glib: 2.8 (stable), 2.9, 2.10, and 2.11. Each of which appears in a directory with different ongoing development versions of pango (and sometimes gtk and atk, as well). Because of this, my opinion of the gtk developers is pretty low -- it appears to be one of the most chaotic projects ever conceived. So I'd really REALLY suggest staying with the stable version...or maybe a little behind it G. (also, anything newer than 2.6 requires cairo and, optionally, glitz...which may or may not be very stable on cygwin -- I make no claim either way). Did you test them? Offering to become cygwin maintainer if consensus develops? Indeed. -- Chuck -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Newer cygwin packages available
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Charli Li wrote: There are some newer cygwin packages available from the original vendor(s) that I would like to bring to your attention: --- |Package name|setup.exe version|vendor's version| |GTK+2 |2.6.10 |2.9.1 | |glib2 |2.6.6|2.11.1 | |pango |1.8.1|1.13.1 | |ATK |1.9.1|1.10.3 | --- Updates to GNOME in the distro are currently pending a few issues. I (as the Cygwin GNOME maintainer) am well aware of the updates necessary (some of the versions above are development branches), and I will update these packages when feasible. Yaakov -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEeR6epiWmPGlmQSMRAizPAJ4uAn0SMre9wW1SDlV2qn080iuRNACgjaHF r7KmGYpGxiEpUqqPLy72DpE= =bxIy -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Updated: texinfo-4.8-3
I've made a new version of 'texinfo' available for installation. This version incorporates a patch from Fedora which should fix the problem mentioned here: http://cygwin.com/ml/cygwin/2006-05/msg00759.html For a brief description of this package, and a listing of the files it contains, see http://cygwin.com/packages/texinfo . 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 keep clicking Next. If you have questions or comments, please send them to the Cygwin mailing list. *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, please use the automated form at: http://cygwin.com/lists.html#subscribe-unsubscribe If this does not work, then look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: [EMAIL PROTECTED] If you need more information on unsubscribing, start reading here: http://sources.redhat.com/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL.
