On 1/13/2022 5:56 AM, Takashi Yano wrote:
Ken Brown wrote:
2. You can use the ReturnLength parameter of NtQueryInformationProcess to see
how big a buffer is needed. This might be more efficient than repeatedly
doubling the buffer size.
Even if ReturnLength is used, the first
I am sorry for being absent for a long time.
On Sun, 26 Dec 2021 10:09:57 -0500
Ken Brown wrote:
> On 12/25/2021 11:56 PM, Jeremy Drake wrote:
> > I set up a windows server 2022 VM last night and went nuts stressing
> > pacman/GPGME. I was able to reproduce the issue there:
> >
> > status =
On 29/12/2021 05:45, Jeremy Drake wrote:
On Mon, 27 Dec 2021, Jon Turney wrote:
On 24/12/2021 00:29, Jeremy Drake via Cygwin-patches wrote:
again, so I can't confirm this. I took a core with 'dumper' but gdb
doesn't want to load it (it says Core file format not supported, maybe
something
On Wed, 29 Dec 2021, Ken Brown wrote:
> Takashi must be unavailable also, but it's a simple enough fix that I decided
> to go ahead and push it.
Thanks. Regarding the other hang I'm seeing on ARM64, I tried gdb windbg
and lldb, and none of them seem able to read the 'context' of the main
thread
On 12/26/2021 6:12 PM, Ken Brown wrote:
There are some fixes (though not pipe-related) pending for 3.3.4, so I'll push
it to the 3.3 branch after I've heard from Takashi and/or Corinna.
Takashi must be unavailable also, but it's a simple enough fix that I decided to
go ahead and push it.
On Mon, 27 Dec 2021, Jon Turney wrote:
> On 24/12/2021 00:29, Jeremy Drake via Cygwin-patches wrote:
> > again, so I can't confirm this. I took a core with 'dumper' but gdb
> > doesn't want to load it (it says Core file format not supported, maybe
> > something with msys2's gdb?).
>
> I think
On Sun, 26 Dec 2021, Ken Brown wrote:
> On 12/26/2021 6:23 PM, Jeremy Drake wrote:
> > On Sun, 26 Dec 2021, Ken Brown wrote:
> >
> > > On 12/26/2021 5:43 PM, Jeremy Drake wrote:
> > > > My loops are still going after an hour. I know that ARM64 would have
> > > > hit
> > > > the assert before
On 24/12/2021 00:29, Jeremy Drake via Cygwin-patches wrote:
again, so I can't confirm this. I took a core with 'dumper' but gdb
doesn't want to load it (it says Core file format not supported, maybe
something with msys2's gdb?).
I think you need gdb 11 (for this patch set [1], which is also
On 12/26/2021 6:23 PM, Jeremy Drake wrote:
On Sun, 26 Dec 2021, Ken Brown wrote:
On 12/26/2021 5:43 PM, Jeremy Drake wrote:
My loops are still going after an hour. I know that ARM64 would have hit
the assert before now.
Well, ARM64 hung up, but didn't hit the assert, so maybe there's some
On Sun, 26 Dec 2021, Ken Brown wrote:
> On 12/26/2021 5:43 PM, Jeremy Drake wrote:
> > My loops are still going after an hour. I know that ARM64 would have hit
> > the assert before now.
Well, ARM64 hung up, but didn't hit the assert, so maybe there's some
*other* issue running around.
On 12/26/2021 5:43 PM, Jeremy Drake wrote:
On Sun, 26 Dec 2021, Ken Brown wrote:
+ /* NtQueryInformationProcess can return STATUS_SUCCESS with
+invalid handle data for certain processes. See
+
On Sun, 26 Dec 2021, Ken Brown wrote:
> + /* NtQueryInformationProcess can return STATUS_SUCCESS with
> + invalid handle data for certain processes. See
> +
> https://github.com/processhacker/processhacker/blob/master/phlib/native.c#L5754.
I would recommend using the
On 12/26/2021 4:35 PM, Jeremy Drake wrote:
On Sun, 26 Dec 2021, Ken Brown wrote:
On 12/26/2021 11:04 AM, Ken Brown wrote:
On 12/26/2021 10:09 AM, Ken Brown wrote:
1. For some processes, NtQueryInformationProcess(ProcessHandleInformation)
can return STATUS_SUCCESS with invalid handle
On Sun, 26 Dec 2021, Ken Brown wrote:
> On 12/26/2021 11:04 AM, Ken Brown wrote:
> > On 12/26/2021 10:09 AM, Ken Brown wrote:
> > > 1. For some processes, NtQueryInformationProcess(ProcessHandleInformation)
> > > can return STATUS_SUCCESS with invalid handle information. See the
> > > comment
On 12/26/2021 11:04 AM, Ken Brown wrote:
On 12/26/2021 10:09 AM, Ken Brown wrote:
1. For some processes, NtQueryInformationProcess(ProcessHandleInformation) can
return STATUS_SUCCESS with invalid handle information. See the comment
starting at line 5754, where it is shown how to detect this.
On 12/26/2021 10:09 AM, Ken Brown wrote:
1. For some processes, NtQueryInformationProcess(ProcessHandleInformation) can
return STATUS_SUCCESS with invalid handle information. See the comment starting
at line 5754, where it is shown how to detect this.
If I'm right, the following patch should
On 12/25/2021 11:56 PM, Jeremy Drake wrote:
I set up a windows server 2022 VM last night and went nuts stressing
pacman/GPGME. I was able to reproduce the issue there:
status = 0x, phi->NumberOfHandles = 8261392, n_handle = 256
[#--] 14%
assertion
I set up a windows server 2022 VM last night and went nuts stressing
pacman/GPGME. I was able to reproduce the issue there:
status = 0x, phi->NumberOfHandles = 8261392, n_handle = 256
[#--] 14%
assertion "phi->NumberOfHandles <= n_handle" failed: file
On 12/25/2021 6:00 PM, Jeremy Drake via Cygwin-patches wrote:
On Sat, 25 Dec 2021, Jeremy Drake via Cygwin-patches wrote:
On Sun, 26 Dec 2021, Takashi Yano wrote:
Could you please check the result of the following test case
in that ARM64 platform?
OK, on Windows 11 ARM64 (same machine
On Sat, 25 Dec 2021, Jeremy Drake via Cygwin-patches wrote:
> On Sun, 26 Dec 2021, Takashi Yano wrote:
>
> > Could you please check the result of the following test case
> > in that ARM64 platform?
> >
>
OK, on Windows 11 ARM64 (same machine as I was testing the assert on):
per_process:
On 12/25/2021 2:20 PM, Jeremy Drake via Cygwin-patches wrote:
On Sun, 26 Dec 2021, Takashi Yano wrote:
Could you please check the result of the following test case
in that ARM64 platform?
I will probably not be able to get to this until tomorrow at the earliest.
But keep in mind the issue
On Sun, 26 Dec 2021, Takashi Yano wrote:
> Could you please check the result of the following test case
> in that ARM64 platform?
>
I will probably not be able to get to this until tomorrow at the earliest.
But keep in mind the issue I'm seeing is not deterministic - I have to run
pacman in a
On 25.12.2021 18:16, Takashi Yano wrote:
On Sun, 26 Dec 2021 02:10:10 +0900
Takashi Yano wrote:
if (phi->NumberOfHandles > n_handle) {
HeapFree(GetProcessHeap(), 0, phi);
exit(1);
}
[...]
if (shi->NumberOfHandles > n_handle) {
On Sun, 26 Dec 2021 02:10:10 +0900
Takashi Yano wrote:
> if (phi->NumberOfHandles > n_handle) {
> HeapFree(GetProcessHeap(), 0, phi);
> exit(1);
> }
[...]
> if (shi->NumberOfHandles > n_handle) {
> HeapFree(GetProcessHeap(), 0, shi);
>
On Fri, 24 Dec 2021 21:40:24 -0800 (PST)
Jeremy Drake wrote:
> On Sat, 25 Dec 2021, Takashi Yano wrote:
>
> > On Fri, 24 Dec 2021 19:47:46 -0800 (PST)
> > Jeremy Drake wrote:
> > > phi->NumberOfHandles = 7999168, n_handle = 256
> > > assertion "phi->NumberOfHandles <= n_handle" failed: file
> > >
On Sat, 25 Dec 2021, Takashi Yano wrote:
> On Fri, 24 Dec 2021 19:47:46 -0800 (PST)
> Jeremy Drake wrote:
> > phi->NumberOfHandles = 7999168, n_handle = 256
> > assertion "phi->NumberOfHandles <= n_handle" failed: file
> > "../../.././winsup/cygwin/fhandler_pipe.cc", line 1280, function: void*
>
On Fri, 24 Dec 2021 19:47:46 -0800 (PST)
Jeremy Drake wrote:
> phi->NumberOfHandles = 7999168, n_handle = 256
> assertion "phi->NumberOfHandles <= n_handle" failed: file
> "../../.././winsup/cygwin/fhandler_pipe.cc", line 1280, function: void*
> fhandler_pipe::get_query_hdl_per_process(WCHAR*,
On Sat, 25 Dec 2021, Takashi Yano wrote:
> Could you please try
> assert(phi->NumberOfHandles <= n_handle)
> rather than
> assert(phi->NumberOfHandles < n_handle)
> ?
I thought of that when I was re-reading my email. I also added a printf:
index 9ce140089..4d10451c1 100644
---
On Fri, 24 Dec 2021 16:39:13 -0800 (PST)
Jeremy Drake wrote:
> On Fri, 24 Dec 2021, Ken Brown wrote:
>
> > On 12/24/2021 2:42 PM, Jeremy Drake wrote:
> > > It does seem to happen much more often on Windows on ARM64 (so much so
> > > that at first I thought it was an issue with their emulation).
On Fri, 24 Dec 2021, Ken Brown wrote:
> On 12/24/2021 2:42 PM, Jeremy Drake wrote:
> > It does seem to happen much more often on Windows on ARM64 (so much so
> > that at first I thought it was an issue with their emulation). With this
> > patch I have not seen the issue again.
>
> So can you
On Fri, 24 Dec 2021, Ken Brown wrote:
> So can you test your diagnosis by removing your patch and adding an assertion?
I will attempt to do this. Do I need any special configure args or
anything for assertions to be enabled?
> > Also, it seems to have started cropping up in msys2's CI when the
On 12/24/2021 2:42 PM, Jeremy Drake wrote:
On Fri, 24 Dec 2021, Ken Brown wrote:
I agree that it's hard to see how the line you quoted could cause an
exception. But you were using an optimized build, so I'm not sure how
reliable the line-number information is.
Is it feasible to run your test
On Fri, 24 Dec 2021, Ken Brown wrote:
> I agree that it's hard to see how the line you quoted could cause an
> exception. But you were using an optimized build, so I'm not sure how
> reliable the line-number information is.
>
> Is it feasible to run your test under strace? If so, you could add
On 12/23/2021 7:29 PM, Jeremy Drake via Cygwin-patches wrote:
On Thu, 23 Dec 2021, Ken Brown wrote:
- for (ULONG j = 0; j < phi->NumberOfHandles; j++)
+ for (ULONG j = 0; j < min(phi->NumberOfHandles, n_handle); j++)
Reading the preceding code, I don't see how n_handle could be
On Thu, 23 Dec 2021, Ken Brown wrote:
> > - for (ULONG j = 0; j < phi->NumberOfHandles; j++)
> > + for (ULONG j = 0; j < min(phi->NumberOfHandles, n_handle); j++)
>
> Reading the preceding code, I don't see how n_handle could be less than
> phi->NumberOfHandles. Can you explain?
>
Not
On 12/23/2021 6:10 PM, Jeremy Drake via Cygwin-patches wrote:
diff --git a/winsup/cygwin/fhandler_pipe.cc
b/winsup/cygwin/fhandler_pipe.cc
index ba6b70f55..48713a38d 100644
--- a/winsup/cygwin/fhandler_pipe.cc
+++ b/winsup/cygwin/fhandler_pipe.cc
@@ -1239,7 +1239,7 @@
36 matches
Mail list logo
