CVSROOT:/cvs/src
Module name:src
Changes by: yselkow...@sourceware.org 2011-05-12 06:13:03
Modified files:
winsup/cygwin : ChangeLog fhandler_proc.cc
Log message:
* fhandler_proc.cc (format_proc_meminfo): Rewrite to use sysinfo().
Support RAM and
On May 11 22:58, Yaakov (Cygwin/X) wrote:
On Mon, 2011-05-09 at 09:55 +0200, Corinna Vinschen wrote:
I'm not sure I understand this new format. Why do you keep the Mem: and
Swap: lines? Linux doesn't have them and top appears to work without
them. And then, why do you print MemShared,
On May 11 21:31, Corinna Vinschen wrote:
On May 11 13:46, Ryan Johnson wrote:
Given that Heap32* has already been reverse-engineered by others,
the main challenge would involve sorting the set of heap block
addresses and distilling them down to a set of allocation bases. We
don't want to
On 12/05/2011 11:09 AM, Corinna Vinschen wrote:
On May 12 14:10, Corinna Vinschen wrote:
On May 11 21:31, Corinna Vinschen wrote:
On May 11 13:46, Ryan Johnson wrote:
Given that Heap32* has already been reverse-engineered by others,
the main challenge would involve sorting the set of heap
On 11/05/2011 3:31 PM, Corinna Vinschen wrote:
On May 11 13:46, Ryan Johnson wrote:
Also, the cygheap isn't a normal windows heap, is it? I thought it
was essentially a statically-allocated array (.cygheap) that gets
managed as a heap. I guess since it's part of cygwin1.dll we already
do sort
On May 12 12:31, Ryan Johnson wrote:
On 12/05/2011 11:09 AM, Corinna Vinschen wrote:
On May 12 14:10, Corinna Vinschen wrote:
On May 11 21:31, Corinna Vinschen wrote:
On May 11 13:46, Ryan Johnson wrote:
Given that Heap32* has already been reverse-engineered by others,
the main challenge
On May 12 12:37, Ryan Johnson wrote:
On 11/05/2011 3:31 PM, Corinna Vinschen wrote:
On May 11 13:46, Ryan Johnson wrote:
Also, the cygheap isn't a normal windows heap, is it? I thought it
was essentially a statically-allocated array (.cygheap) that gets
managed as a heap. I guess since it's
On May 12 18:55, Corinna Vinschen wrote:
On May 12 12:31, Ryan Johnson wrote:
On 12/05/2011 11:09 AM, Corinna Vinschen wrote:
-void *base;
+unsigned heap_id;
+uintptr_t base;
+uintptr_t end;
+unsigned long flags;
};
We don't actually need the end pointer:
On 12/05/2011 12:55 PM, Corinna Vinschen wrote:
struct heap
{
heap *next;
-void *base;
+unsigned heap_id;
+uintptr_t base;
+uintptr_t end;
+unsigned long flags;
};
We don't actually need the end pointer: we're trying to match an
No, we need it. The heaps
On 12/05/2011 1:11 PM, Corinna Vinschen wrote:
On May 12 18:55, Corinna Vinschen wrote:
On May 12 12:31, Ryan Johnson wrote:
On 12/05/2011 11:09 AM, Corinna Vinschen wrote:
-void *base;
+unsigned heap_id;
+uintptr_t base;
+uintptr_t end;
+unsigned long flags;
};
We
On May 12 13:53, Ryan Johnson wrote:
On 12/05/2011 12:55 PM, Corinna Vinschen wrote:
struct heap
{
heap *next;
-void *base;
+unsigned heap_id;
+uintptr_t base;
+uintptr_t end;
+unsigned long flags;
};
We don't actually need the end pointer: we're
On May 12 13:53, Ryan Johnson wrote:
On 12/05/2011 1:11 PM, Corinna Vinschen wrote:
On May 12 18:55, Corinna Vinschen wrote:
On May 12 12:31, Ryan Johnson wrote:
On 12/05/2011 11:09 AM, Corinna Vinschen wrote:
-void *base;
+unsigned heap_id;
+uintptr_t base;
+uintptr_t end;
On May 12 20:42, Corinna Vinschen wrote:
I created a test application with several heaps [...]
Btw., here's my test app. It's ugly but it's just for testing the
results anyway.
Corinna
#include stdio.h
#define _WIN32_WINNT 0x0601
#include windows.h
#include ddk/ntddk.h
#include ddk/ntapi.h
On 12/05/2011 2:48 PM, Corinna Vinschen wrote:
On May 12 13:53, Ryan Johnson wrote:
On 12/05/2011 1:11 PM, Corinna Vinschen wrote:
On May 12 18:55, Corinna Vinschen wrote:
On May 12 12:31, Ryan Johnson wrote:
On 12/05/2011 11:09 AM, Corinna Vinschen wrote:
-void *base;
+unsigned
On 12/05/2011 2:42 PM, Corinna Vinschen wrote:
On May 12 13:53, Ryan Johnson wrote:
On 12/05/2011 12:55 PM, Corinna Vinschen wrote:
heap *heaps;
This is a misnomer now -- it's really a list of heap regions/blocks.
I don't think so. The loop stores only the blocks which constitute
the
On May 12 15:19, Ryan Johnson wrote:
On 12/05/2011 2:48 PM, Corinna Vinschen wrote:
Nope. As I wrote in my previoous mail and as you can still see in my
quote above, the two virtual memory areas from 0x2 to 0x3 and
from 0x3 to 0x23 together constitute a single start block in
On May 12 20:42, Corinna Vinschen wrote:
As for the big blocks, they are apparently identified by the value in
the Unknown member of the DEBUG_HEAP_BLOCK structure. Here's what I
figured out so far as far as Unknown is concerned:
Scratch that. I finally *really* figured out what the unknown
Den 2011-05-11 19:34 skrev Corinna Vinschen:
On May 11 16:52, Peter Rosin wrote:
Hello!
The following STC hints at a problem in strptime:
...
Opengroup has this to say about only filling in some fields:
It is unspecified whether multiple calls to strptime()
using the same tm
Hi Chuck,
Would it be possible to get a p7zip update? The latest release is 9.20.1.
Thank you,
Chris
--
Chris Sutcliffe
http://emergedesktop.org
http://www.google.com/profiles/ir0nh34d
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
On May 12 11:01, Peter Rosin wrote:
Den 2011-05-11 19:34 skrev Corinna Vinschen:
On May 11 16:52, Peter Rosin wrote:
Hello!
The following STC hints at a problem in strptime:
...
Opengroup has this to say about only filling in some fields:
It is unspecified whether multiple calls
On May 12 13:11, Corinna Vinschen wrote:
On May 12 11:01, Peter Rosin wrote:
Maybe someone with a copyright assignment [...]
Btw., that could be you! It's not that hard to send one. See the
Before you get started section on http://cygwin.com/contrib.html,.
Corinna
--
Corinna Vinschen
Hi Andrew and Corinna,
Yep, something about FAT32 appears to be the problem. As Corinna correctly
notes, permissions are faked on FAT32. Doesn't matter what chmod I run, it's
all 644 or 755. Apparently, GNU screen does not like this, but apparently it
also doesn't give any error message
This permissions problem has existed for awhile, and I'd like to find
a solution.
CMD.EXE is able to create files inside directories on a standard
Windows share, but from a Bash shell on Cygwin, a permission denied
message occurs, and this is in most if not all directories:
-bash:
On 5/12/2011 11:47 AM, Keith Christian wrote:
This permissions problem has existed for awhile, and I'd like to find
a solution.
CMD.EXE is able to create files inside directories on a standard
Windows share, but from a Bash shell on Cygwin, a permission denied
message occurs, and this is in
On 5/12/2011 1:54 PM, Keith Christian wrote:
Thank you for the reply, Larry.
Requested output is either pasted or attached.
Is the getVolInfo output from a network appliance or is it simply an
internal disk on another Windows machine?
Potential app conflicts:
ZoneAlarm Personal Firewall
On May 12 09:47, Keith Christian wrote:
This permissions problem has existed for awhile, and I'd like to find
a solution.
CMD.EXE is able to create files inside directories on a standard
Windows share, but from a Bash shell on Cygwin, a permission denied
message occurs, and this is in most
On May 12 15:01, Larry Hall (Cygwin) wrote:
On 5/12/2011 1:54 PM, Keith Christian wrote:
Thank you for the reply, Larry.
Requested output is either pasted or attached.
Is the getVolInfo output from a network appliance or is it simply an
internal disk on another Windows machine?
The flags
On 12/05/11 01:57, Larry Hall (Cygwin) wrote:
On 5/11/2011 5:04 PM, Tim Allen wrote:
Hi Larry
On 11/05/11 15:45, Larry Hall (Cygwin) wrote:
On 5/11/2011 6:44 AM, Tim Allen wrote:
Hi
I have happily used Cygwin ssh from DOS command prompt for many
years but
on upgrading to V1.7 get this error
On May 12 15:17, Keith Christian wrote:
Corinna, the bash.trace output is attached. Thank you for checking
into this problem.
But I can't really help. The problem is that the Windows call to open
tjhe file simply fails:
39 146109 [main] bash 2020 fhandler_base::open: C022 = NtCreateFile
I am configuring a set of servers of which most are running Server2003, but two
are running Server2008 (64 bit). Cron works fine on all of the Server2003
servers. But the two Server2008 servers display this error in ~/cron.log:
2 [main] cron 2800 C:\cygwin\usr\sbin\cron.exe: *** fatal
30 matches
Mail list logo
