2009/10/9 Vin Shelton:
>> > #3 0x005151bc in Lstream_really_write (lstr=0x176ea00,
>> > data=0x148d0c0
>> >
>> "c;C:\\cygwin\\cygwin\\tmp\\s360339.aoa\\ï\202\201Ð\201Ð\201Ð\201ï\203\22002ABFxi-string)g)Àâw\001\200ÑH\001Â\200\t",
Hang on, there is a problem with this one: Cygwin doesn't li
2009/10/9 Vin Shelton:
>> > #9 0x0056d4d7 in qxe_realpath (path=0x22248c "",
>> > resolved_path=0x22651c
>> > "c:/cygwin/tmp/s360339.aoa/\201Ð\201Ð\201Ð\201Ð02ABFx",
>> > links_only=0) at
>> > #8 0x0056cd68 in readlink_or_correct_case (name=,
>> > buf=0x21e464
>> >
>> "/tmp/s
Stephen -
Thanks again for taking this up.
On Thu, Oct 8, 2009 at 2:36 PM, Stephen J. Turnbull wrote:
> Vin Shelton writes:
>
> > (gdb) pobj charset
> > Cannot access memory at address 0x4
>
> Urk. That's unexpected. You might want to try going up the stack to
> frame 1 and trying that. If
Steven Woody wrote:
so, to uninstall 1 package, what you did is actually download the
other 99 packages?
No, I have a local download directory that I keep current.
To be precise, I installed the other packages from my local download
directory. No additional internet bandwidth was harmed duri
On Fri, Oct 9, 2009 at 6:35 AM, Ralph Hempel wrote:
> Christopher Faylor wrote:
>
>> It's on my todo list to get rid of the GUI pop-up from setup.exe when
>> -P is used. I know that won't make it like rpm/yum/apt/dpkg/emerge.
>
> Not to put too fine a point on it but ... if I ever want to uninsta
Christopher Faylor wrote:
It's on my todo list to get rid of the GUI pop-up from setup.exe when
-P is used. I know that won't make it like rpm/yum/apt/dpkg/emerge.
Not to put too fine a point on it but ... if I ever want to uninstall
a package (rarely) here's what I do:
1. Rename my current
On Thu, Oct 08, 2009 at 05:25:20PM -0400, Christopher Faylor wrote:
>On Thu, Oct 08, 2009 at 05:23:11PM -0400, Christopher Faylor wrote:
>>I'm wondering if it would just be best for me to continue in this vein.
>
>"this vein" == continue to maintain insight and gdb.
But before I do that I'm gettin
On Thu, Oct 08, 2009 at 05:23:11PM -0400, Christopher Faylor wrote:
>I'm wondering if it would just be best for me to continue in this vein.
"this vein" == continue to maintain insight and gdb.
cgf
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com
On Thu, Oct 08, 2009 at 08:27:42PM +, Eric Blake wrote:
>The gnulib test for utimensat found a bug in utimensat: it truncates time too
>much, and has the result of making time appear to flow backwards.
>
>This sample code sequence shows the problem (when run at speed; of course
>single steppi
On Thu, Oct 08, 2009 at 02:53:57PM -0400, Charles Wilson wrote:
>The existing cygwin gdb/insight 6.8-2 package has the following change:
>
>2007-11-30 Pedro Alves <...>
>
> * i386-tdep.c (struct i386_frame_cache): Rename saved_sp to
> prev_frame_sp. Add saved_sp_regnum field.
>
On 10/08/2009 01:13 PM, Steven Woody wrote:
But I think even not involve in any new design or a new command line
option, the current GUI still have a place to improve. To me, the
big problem is, when I can not change a package's state directly into
'uninstall' without going through other states
The gnulib test for utimensat found a bug in utimensat: it truncates time too
much, and has the result of making time appear to flow backwards.
This sample code sequence shows the problem (when run at speed; of course
single stepping this introduces delays and masks the problem):
close (creat (
Christopher Faylor wrote:
> Use the insight mailing list, Luke. Keith Seitz is a friend and he does
> not hate Cygwin.
Since it was detailed in "gdb/ChangeLog.Cygwin" I figured it was
appropriate here. But...
http://www.cygwin.com/ml/cygwin-announce/2008-04/msg00011.html
"Unlike most cygwin pac
Charles Wilson wrote:
> (patch vs. "regular" gdb-6.8 attached).
Oops.
diff -urN old/insight-6.8/gdb/i386-tdep.c new/insight-6.8/gdb/i386-tdep.c
--- old/insight-6.8/gdb/i386-tdep.c 2008-03-04 14:49:39.0 -0500
+++ new/insight-6.8/gdb/i386-tdep.c 2008-03-22 18:24:36.0 -0400
@@ -296,6
On Thu, Oct 08, 2009 at 02:53:57PM -0400, Charles Wilson wrote:
>The existing cygwin gdb/insight 6.8-2 package has the following change:
>
>2007-11-30 Pedro Alves <...>
>
> * i386-tdep.c (struct i386_frame_cache): Rename saved_sp to
> prev_frame_sp. Add saved_sp_regnum field.
>
The existing cygwin gdb/insight 6.8-2 package has the following change:
2007-11-30 Pedro Alves <...>
* i386-tdep.c (struct i386_frame_cache): Rename saved_sp to
prev_frame_sp. Add saved_sp_regnum field.
(i386_alloc_frame_cache): Update.
(i386_analyze_stack_align
Vin Shelton writes:
> (gdb) pobj charset
> Cannot access memory at address 0x4
Urk. That's unexpected. You might want to try going up the stack to
frame 1 and trying that. If that's not more sensible, what does print
charset say?
Diving into the stack
> #9 0x0056d4d7 in qxe_realpath (pat
On Thu, Oct 08, 2009 at 02:10:28PM -0400, Charles Wilson wrote:
>Christopher Faylor wrote:
>> On Thu, Oct 08, 2009 at 01:37:34PM -0400, Charles Wilson wrote:
>>> Christopher Faylor wrote:
The version of insight that I built works fine for me on Windows XP SP3.
I just tried the sigint prob
>> Is there some sort of Cygwin command that -
>> 1. Closes all Mintty windows
>> 2. Unloads services - such as cron
>> 3. Exits X server
>>
>> in short, gets rid of all Cygwin processes so I can update & restart
>> without having to do all this myself.
>>
> I use the attached script (run it elevat
Christopher Faylor wrote:
> On Thu, Oct 08, 2009 at 01:37:34PM -0400, Charles Wilson wrote:
>> Christopher Faylor wrote:
>>> The version of insight that I built works fine for me on Windows XP SP3.
>>> I just tried the sigint problem test case with it and it worked as
>>> expected.
>> OK. One more
On Thu, Oct 08, 2009 at 01:37:34PM -0400, Charles Wilson wrote:
>Christopher Faylor wrote:
>> The version of insight that I built works fine for me on Windows XP SP3.
>> I just tried the sigint problem test case with it and it worked as
>> expected.
>
>OK. One more try: here's an actual STC. It wor
Christopher Faylor wrote:
> The version of insight that I built works fine for me on Windows XP SP3.
> I just tried the sigint problem test case with it and it worked as
> expected.
OK. One more try: here's an actual STC. It works as expected if compiled
using:
1) gcc-3 -mno-cygwin -o thread_test
> From: news
> Subject: Many Cygwin (mintty) windows - How to close all?
> Date: Thu, 8 Oct 2009 11:05:16 -0500
>
> Is there some sort of Cygwin command that -
> 1. Closes all Mintty windows
> 2. Unloads services - such as cron
> 3. Exits X server
>
> in short, gets rid of all Cygwin processes so
On Thu, Oct 8, 2009 at 9:46 PM, Christopher Faylor
wrote:
> On Thu, Oct 08, 2009 at 06:40:34AM -0400, Ken Jackson wrote:
>>On Thu, 08 Oct 2009 00:49:45 -0400
>>"Larry Hall (Cygwin)" wrote:
>>
>>> On 10/08/2009 12:25 AM, Ken Jackson wrote:
>>> > It would be great to have a command-line package man
On Thu, Oct 08, 2009 at 12:18:35PM -0400, Charles Wilson wrote:
>Christopher Faylor wrote:
>>>This is coming up because any tcl app that I've built -- including
>>>insight -- always dies on exit, as tcl is shutting down its various
>>>utility threads.
>>
>>So why isn't this a problem with the curre
Christopher Faylor wrote:
> On Thu, Oct 08, 2009 at 07:18:49AM -0400, Charles Wilson wrote:
>> is it possible that cygwin
>> is overzealously inserting the _cygtls::call2() function into the return
>> frame stack? Does cygwin manipulate the TIB, even for threads created
>> by direct calls to Creat
Is there some sort of Cygwin command that -
1. Closes all Mintty windows
2. Unloads services - such as cron
3. Exits X server
in short, gets rid of all Cygwin processes so I can update & restart
without having to do all this myself.
--
Problem reports: http://cygwin.com/pro
On Thu, Oct 08, 2009 at 09:48:22AM -0400, Christopher Faylor wrote:
>Uh, yeah. If you are not using Cygwin methods to start threads then it
>is entirely likely that there will be problems, just like if you use
>non-Cygwin methods to do I/O.
OTOH, it is supposed to sort of work. That's what the c
Marco Atzeri ha scritto:
--- Lun 5/10/09, Angelo Graziosi ha scritto:
Marco Atzeri ha scritto:
Hi Angelo,
it is a change of behavior implemented by
upper stream developer 2 years ago
http://article.gmane.org/gmane.comp.video.graphicsmagick.help/857
so it is not my fault and you are the firs
On Thu, Oct 08, 2009 at 09:43:32AM -0400, Christopher Faylor wrote:
>On Thu, Oct 08, 2009 at 05:53:47AM -0300, Pedro Izecksohn wrote:
>>I, Pedro Izecksohn wrote:
>>> Robert Pendell wrote:
I was unable to reproduce this bug on 1.7. ??Compiled using GCC 4.3.4
on 1.7.0-62. ??Gave exit
On Thu, Oct 8, 2009 at 5:13 AM, Stephen J. Turnbull wrote:
> Vin Shelton writes:
>
> > XEmacs people - here is the line of code implicated in the crash:
> >
> > switch (XCHARSET_REP_BYTES (charset))
>
> Can you do a pobj on charset in the debugger and find out what it
> actually
Corinna Vinschen cygwin.com> writes:
> I'm not aware that Windows supports a file open flag similar to the
> O_NOATIME flag. That would require to store and restore the atime every
> time a symlink is read, and we must read the symlink content to fetch the
> correct filesize.
OK, then probably
Charles Wilson wrote:
> I have an idea why this is happening: I'm managing these threads
> manually using the windows API calls: CreateThread, WaitForSingleObject,
> SetEvent, etc. They are NOT actually started by cygwin's thread
> launching facilities (e.g. pthread).
Then you are doomed. Cyg
--- Lun 5/10/09, Angelo Graziosi ha scritto:
> Marco Atzeri ha scritto:
> > Hi Angelo,
> > it is a change of behavior implemented by
> > upper stream developer 2 years ago
> >
> > http://article.gmane.org/gmane.comp.video.graphicsmagick.help/857
> >
> > so it is not my fault and you are the fir
On Thu, Oct 08, 2009 at 07:18:49AM -0400, Charles Wilson wrote:
>I'm getting some weird crashes with threads. When a thread exits, I'm
>getting a SEGV in _cygtls::remove. That is, when the thread function
>returns, it ends up in cygtls::call2 (e.g. at B, below). Oddly, if I
>set a break point at
Hi, can anyone help? Thanks in advance.
On Wed, Oct 7, 2009 at 1:44 PM, Steven Woody wrote:
> Hi,
>
> I removed cygwin1.5 on both of my two computers, one is a laptop and
> another is a desktop, they are all Windows XP. I then installed
> cygwin 1.7 for them, the result is strange. The laptop
On Thu, Oct 08, 2009 at 06:40:34AM -0400, Ken Jackson wrote:
>On Thu, 08 Oct 2009 00:49:45 -0400
>"Larry Hall (Cygwin)" wrote:
>
>> On 10/08/2009 12:25 AM, Ken Jackson wrote:
>> > It would be great to have a command-line package management tool.
>> > For example, if yum were ported to Cygwin, for
On Thu, Oct 08, 2009 at 05:53:47AM -0300, Pedro Izecksohn wrote:
>I, Pedro Izecksohn wrote:
>> Robert Pendell wrote:
>>>
>>> I was unable to reproduce this bug on 1.7. ??Compiled using GCC 4.3.4
>>> on 1.7.0-62. ??Gave exit code 130 every time. ??I used your test case to
>>> do the test.
>>
>> ??
On Oct 8 06:06, Eric Blake wrote:
> I've been trying to use lutimes and utimensat(,AT_SYMLINK_NOFOLLOW) to
> play with symlink timestamps. mtime can be modified just fine, but atime
> changes are lost the moment you lstat() the symlink again (probably
> because path.cc opens the symlink file duri
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I've been trying to use lutimes and utimensat(,AT_SYMLINK_NOFOLLOW) to
play with symlink timestamps. mtime can be modified just fine, but atime
changes are lost the moment you lstat() the symlink again (probably
because path.cc opens the symlink file
Ken Jackson wrote:
I agree. And even for simple operations I find it a bother to have to
start up a gui to install a package or check for updates.
It would be great to have a command-line package management tool. For
example, if yum were ported to Cygwin, for the case you cite, you could
do th
I'm getting some weird crashes with threads. When a thread exits, I'm
getting a SEGV in _cygtls::remove. That is, when the thread function
returns, it ends up in cygtls::call2 (e.g. at B, below). Oddly, if I
set a break point at A, it is never hit...
void
_cygtls::call2 (DWORD (*func) (void *,
On Oct 8 05:53, Pedro Izecksohn wrote:
> I, Pedro Izecksohn wrote:
> > Robert Pendell wrote:
> >>
> >> I was unable to reproduce this bug on 1.7. Compiled using GCC 4.3.4
> >> on 1.7.0-62. Gave exit code 130 every time. I used your test case to
> >> do the test.
> >
> > May be I did not expr
On Thu, Oct 8, 2009 at 6:40 PM, Ken Jackson wrote:
> On Thu, 08 Oct 2009 00:49:45 -0400
> "Larry Hall (Cygwin)" wrote:
>
>> On 10/08/2009 12:25 AM, Ken Jackson wrote:
>> > It would be great to have a command-line package management tool.
>> > For example, if yum were ported to Cygwin, for the cas
On Thu, 08 Oct 2009 00:49:45 -0400
"Larry Hall (Cygwin)" wrote:
> On 10/08/2009 12:25 AM, Ken Jackson wrote:
> > It would be great to have a command-line package management tool.
> > For example, if yum were ported to Cygwin, for the case you cite,
> > you could do this:
> >
> > $ yum remove PA P
Vin Shelton writes:
> XEmacs people - here is the line of code implicated in the crash:
>
>switch (XCHARSET_REP_BYTES (charset))
Can you do a pobj on charset in the debugger and find out what it
actually is?
--
Problem reports: http://cygwin.com/problems.html
FAQ:
I, Pedro Izecksohn wrote:
> Robert Pendell wrote:
>>
>> I was unable to reproduce this bug on 1.7. Compiled using GCC 4.3.4
>> on 1.7.0-62. Gave exit code 130 every time. I used your test case to
>> do the test.
>
> May be I did not express myself well:
>
> When ctrl c is pressed, it always
Robert Pendell wrote:
>
> I was unable to reproduce this bug on 1.7. Compiled using GCC 4.3.4
> on 1.7.0-62. Gave exit code 130 every time. I used your test case to
> do the test.
May be I did not express myself well:
When ctrl c is pressed, it always give exit code 130. The
inconsistenci
cygwin-ow...@cygwin.com wrote on 08.10.2009 05:02:21:
> I think Cygwin should support -municode option.
> The following patches I made might be incorrect and/or incomplete.
>
> diff -u -N -r cygwin-1.7.0-62-old/winsup/mingw/conuni.c
> cygwin-1.7.0-62/winsup/mingw/conuni.c
> --- cygwin-1.7.0-62-ol
49 matches
Mail list logo
