ant that functionality. I haven't needed it yet.
Thoughts?
Ryan
# HG changeset patch
# Parent 1420f18fd5c5647e475df8339486020b456fb9d8
diff --git a/ChangeLog b/ChangeLog
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,12 @@
+2011-05-10 Ryan Johnson
+
+ * fhandler_process.cc (dos_d
On 11/05/2011 6:31 AM, Corinna Vinschen wrote:
Hi Ryan,
On May 11 01:27, Ryan Johnson wrote:
Hi all,
Please find attached three patches which extend the functionality of
/proc/*/maps.
Thanks!
I applied youyr two first patches with a couple of changes:
- Formatting: Setting of curly braces
On 11/05/2011 9:20 AM, Corinna Vinschen wrote:
On May 11 08:53, Ryan Johnson wrote:
On 11/05/2011 6:31 AM, Corinna Vinschen wrote:
- I replaced the call to GetMappedFileNameEx with a call to
NtQueryVirtualMemory (MemorySectionName). This avoids to add another
dependency to psapi. I
On 11/05/2011 10:13 AM, Christopher Faylor wrote:
On Wed, May 11, 2011 at 09:59:53AM +0200, Corinna Vinschen wrote:
On May 11 02:18, Ryan Johnson wrote:
Please find attached five patches [...]
Oops, wrong mailing list...
Btw., it would be nice if you could create patches with the diff -p
On 11/05/2011 12:16 PM, Christopher Faylor wrote:
Please: One patch per message. One ChangeLog entry per message, not
sent as a diff.
Resend? Or just note for future reference?
Ryan
On 11/05/2011 7:14 AM, Corinna Vinschen wrote:
On May 11 01:27, Ryan Johnson wrote:
The second (proc-maps-heaps) adds reporting of Windows heaps (or
their bases, at least). Unfortunately there doesn't seem to be any
efficient way to identify all virtual allocations which a heap owns.
Ther
Hi all,
This is the first of a series of patches, sent in separate emails as
requested.
The first patch allows a child which failed due to address space
clobbers to report cleanly back to the parent. As a result, DLL_LINK
which land wrong, DLL_LOAD whose space gets clobbered, and failure to
Hi all,
This patch has the parent sort its dll list topologically by
dependencies. Previously, attempts to load a DLL_LOAD dll risked pulling
in dependencies automatically, and the latter would then not benefit
from the code which "encourages" them to land in the right places. The
dependency
Hi all,
This patch fixes a bug in the reserve_at function which caused it to
sometimes reserve space needed by the dll it was supposed to help land.
This happens when the dll tries to land in a free region which overlaps
the desired location. The new code exploits the image introspection
(pat
Hi all,
This patch rewrites dll_list::load_after fork. The new version
eliminates reserve_upto() and release_upto(), which were expensive (the
process repeats for each dll) and buggy (release_upto could free
allocations reserve_upto did not make). Instead, the effect of
reserve_upto is achiev
Hi all,
This last patch adds a small optimization which reserves the lower 4MB
of address space early in the process's lifetime (even if it's not a
forkee). This was motivated by the observation that Windows tends to
move things around a lot in that area, increasing the probability of
future
On 11/05/2011 12:16 PM, Christopher Faylor wrote:
On Wed, May 11, 2011 at 10:21:14AM -0400, Ryan Johnson wrote:
On 11/05/2011 10:13 AM, Christopher Faylor wrote:
On Wed, May 11, 2011 at 09:59:53AM +0200, Corinna Vinschen wrote:
On May 11 02:18, Ryan Johnson wrote:
Please find attached five
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 alrea
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 c
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 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 cons
Any feedback on these patches?
On 11/05/2011 2:31 PM, Ryan Johnson wrote:
Hi all,
This is the first of a series of patches, sent in separate emails as
requested.
The first patch allows a child which failed due to address space
clobbers to report cleanly back to the parent. As a result
On 21/05/2011 9:41 PM, Christopher Faylor wrote:
On Wed, May 11, 2011 at 02:31:23PM -0400, Ryan Johnson wrote:
Hi all,
This is the first of a series of patches, sent in separate emails as
requested.
The first patch allows a child which failed due to address space
clobbers to report cleanly
On 21/05/2011 9:44 PM, Christopher Faylor wrote:
On Wed, May 11, 2011 at 02:31:37PM -0400, Ryan Johnson wrote:
Hi all,
This patch has the parent sort its dll list topologically by
dependencies. Previously, attempts to load a DLL_LOAD dll risked pulling
in dependencies automatically, and the
On 23/05/2011 3:31 AM, Corinna Vinschen wrote:
On May 22 14:42, Ryan Johnson wrote:
On 21/05/2011 9:44 PM, Christopher Faylor wrote:
On Wed, May 11, 2011 at 02:31:37PM -0400, Ryan Johnson wrote:
Hi all,
This patch has the parent sort its dll list topologically by
dependencies. Previously
On 24/05/2011 12:14 PM, Corinna Vinschen wrote:
On May 22 14:42, Ryan Johnson wrote:
On 21/05/2011 9:44 PM, Christopher Faylor wrote:
On Wed, May 11, 2011 at 02:31:37PM -0400, Ryan Johnson wrote:
Hi all,
This patch has the parent sort its dll list topologically by
dependencies. Previously
On 24/05/2011 9:05 AM, Corinna Vinschen wrote:
On May 24 07:27, Ryan Johnson wrote:
On 23/05/2011 3:31 AM, Corinna Vinschen wrote:
On May 22 14:42, Ryan Johnson wrote:
In theory, this should completely eliminate the case where us
loading one DLL pulls in dependencies automatically
On 22/05/2011 4:29 PM, Christopher Faylor wrote:
On Sun, May 22, 2011 at 09:04:40AM -0400, Ryan Johnson wrote:
On 21/05/2011 9:41 PM, Christopher Faylor wrote:
On Wed, May 11, 2011 at 02:31:23PM -0400, Ryan Johnson wrote:
Hi all,
This is the first of a series of patches, sent in separate
On 23/05/2011 3:31 AM, Corinna Vinschen wrote:
On May 22 14:42, Ryan Johnson wrote:
On 21/05/2011 9:44 PM, Christopher Faylor wrote:
On Wed, May 11, 2011 at 02:31:37PM -0400, Ryan Johnson wrote:
Hi all,
This patch has the parent sort its dll list topologically by
dependencies. Previously
On 28/05/2011 4:50 PM, Christopher Faylor wrote:
On Wed, May 11, 2011 at 02:31:37PM -0400, Ryan Johnson wrote:
This patch has the parent sort its dll list topologically by
dependencies. Previously, attempts to load a DLL_LOAD dll risked pulling
in dependencies automatically, and the latter
On 28/05/2011 8:23 PM, Christopher Faylor wrote:
On Sat, May 28, 2011 at 06:40:30PM -0400, Ryan Johnson wrote:
On 28/05/2011 4:50 PM, Christopher Faylor wrote:
On Wed, May 11, 2011 at 02:31:37PM -0400, Ryan Johnson wrote:
This patch has the parent sort its dll list topologically by
On 29/05/2011 12:37 AM, Daniel Colascione wrote:
On 5/28/11 7:35 PM, Ryan Johnson wrote:
On 28/05/2011 8:23 PM, Christopher Faylor wrote:
On Sat, May 28, 2011 at 06:40:30PM -0400, Ryan Johnson wrote:
On 28/05/2011 4:50 PM, Christopher Faylor wrote:
On Wed, May 11, 2011 at 02:31:37PM -0400
On 30/05/2011 2:24 AM, Christopher Faylor wrote:
On Sun, May 29, 2011 at 12:27:45PM -0400, Christopher Faylor wrote:
On Sun, May 29, 2011 at 01:51:35AM -0400, Ryan Johnson wrote:
So, I defined this small function:
static void break_cmalloc(int depth, int maxdepth) {
void* x = cmalloc
Hi all,
Based on the feedback on cygwin-dev, I've put together a revised pair of
faq.using entries: one listing briefly the symptoms of fork failures and
what to do about it, and the other giving some details about why fork
fails (sometimes in spite of everything we do to compensate).
Hi all,
Based on the feedback from cygwin-dev, I've put together a revised pair
of faq.using entries: one listing briefly the symptoms of fork failures
and what to do about it, and the other giving some details about why
fork fails (sometimes in spite of everything we do to compensate).
Ooops. Mailer hiccup. Please ignore this one.
On 25/08/2011 10:08 PM, Ryan Johnson wrote:
Hi all,
Based on the feedback on cygwin-dev, I've put together a revised pair
of faq.using entries: one listing briefly the symptoms of fork
failures and what to do about it, and the other giving
y the first FAQ
question? That would at least cut traffic to the cygwin ML a bit.
Ryan
On 30/08/2011 2:00 AM, Corinna Vinschen wrote:
Hi Ryan,
Thanks for the FAQ entry. I had a look now, finally. Two nits:
On Aug 25 22:08, Ryan Johnson wrote:
Index: winsup/do
On 29/08/2011 2:15 PM, jojelino wrote:
On 2011-08-30 AM 5:23, Christopher Faylor wrote:
Maybe Corinna will disagree but I think there is way too much code
change here for me to be comfortable with including it. It looks like
it would be an ongoing maintenance issue, requiring constant vigilance
On 28/03/2012 10:55 PM, Ein Terakawa wrote:
> Lastly first third of the patch is a workaround of a problem observed
> with cygwin1.dll of cvs HEAD.
> To reproduce:
> 1. Launch a terminal emulator like rxvt or mintty.
> 2. Execute cmd.exe or more.com from shell prompt.
> 3. Type in Enter, Ctrl-C, th
Hi all
While trying to build the cygwin dll from source, I accidentally left my
home-built gcc-4.6 in PATH... and it complains loudly about all kinds of
things, some of which might actually be of interest. I'll follow up
shortly with two patches that fix those problems in a backwards
compatib
On 29/03/2012 10:36 AM, Ryan Johnson wrote:
Patch 1: fix function attribute conflicts
* dcrt0.cc (getstack): Simplify function attribute declarations.
(do_exit): Remove conflicting function attributes.
* environ.cc (various): Ditto.
* errno.cc (various): Ditto
On 29/03/2012 10:36 AM, Ryan Johnson wrote:
Patch 2: fix compiler misc. warnings
* fhandler_disk_file.cc (fhandler_disk_file::fchmod): Fix harmless
out of bounds array access.
* hookapi.cc (find_first_notloaded_dll): Remove write-only
variable.
* net.cc
On 03/05/2012 11:46 PM, Christopher Faylor wrote:
On Thu, May 03, 2012 at 05:03:23PM -0500, Yaakov (Cygwin/X) wrote:
On 2012-05-03 10:24, Christopher Faylor wrote:
Right. I've noticed the incompleteness of elf.h from time to time too but
extending it would be tedious since you can't just cut/p
On 24/10/2012 5:16 AM, Kai Tietz wrote:
Hello,
this patch replaces the inline-assember used in string.h by C implementation.
There are three reasons why I want to suggest this. First, the C-code might
be optimized further by fixed (constant) arguments. Secondly, it is
architecture
independent
On 22/02/2013 9:44 AM, Corinna Vinschen wrote:
On Feb 22 09:32, Christopher Faylor wrote:
On Fri, Feb 22, 2013 at 11:02:55AM +0100, Corinna Vinschen wrote:
On Feb 22 10:51, Corinna Vinschen wrote:
On Feb 22 03:40, Yaakov wrote:
On Fri, 22 Feb 2013 09:49:51 +0100, Corinna Vinschen wrote:
acce
42 matches
Mail list logo
