Hi Teemu,
On 11/18/2024 10:59 PM, Teepean via Cygwin wrote:
2. Compile BWA with rpmalloc and the following patch:
// In thread worker function:
#ifdef __CYGWIN__
rpmalloc_thread_initialize();
#endif
// ... thread work ...
#ifdef __CYGWIN__
rpmalloc_thread_finalize(1);
#endif
How, exactly,
ree hours would take 24 hours or more on an unpatched bwa on Cygwin.
>> 1. The default malloc implementation shows extremely high system time
>> (11.265s) compared to the rpmalloc version (0.327s)
>> 2. Total real time is about 4.5x slower with default malloc
>> 3
ting processing in the usual case?
Analysis
1. The default malloc implementation shows extremely high system time (11.265s)
compared to the rpmalloc version (0.327s)
2. Total real time is about 4.5x slower with default malloc
3. The dramatic difference in system time suggests heavy contention in the
m
tal real time is about 4.5x slower with default malloc
3. The dramatic difference in system time suggests heavy contention in the
memory allocation subsystem
4. The issue only manifests on Cygwin with bwa; the same code performs normally
on native Linux and MacOS
5. The issue manifests with rec
r the cygwin console code because
the local key cache should be able to access from other process
running in the same console. This needs inter-process-communication
or shared memory.
> Alternatively, from research these pseudo key events have Vk=0/Sc=0 values
> (only char and down are set);
I raised the same question under:
https://github.com/microsoft/terminal/issues/17824
*cons_master_thread() should *possibly maintain a local key cache and not
push back events.
Alternatively, from research these pseudo key events have Vk=0/Sc=0 values
(only char and down are set); as such peek th
On Sat, 31 Aug 2024 14:20:04 +0900
Takashi Yano wrote:
> Thanks for the pointer. Unfortunately, the document does not mention
> about the behaviour of WriteConsoleInput() in the win32-inpu-mode.
>
> I expected that ReadConsoleInput() returns the INPUT_RECORDS which
> WriteConsoleInput() sends. How
Thanks for the pointer. Unfortunately, the document does not mention
about the behaviour of WriteConsoleInput() in the win32-inpu-mode.
I expected that ReadConsoleInput() returns the INPUT_RECORDS which
WriteConsoleInput() sends. However, that does not seem true in this
mode.
On Sat, 31 Aug 2024
-raw-mode "\033[?9001h" enabled,
> > after brief input in the application becoming unresponsive and the
> session
> > rapidly consumes all available memory/cpu..
> >
> > Test application attached, plus ticket
> > https://github.com/microsoft/terminal/iss
pplication under a MsTerminal
> session, with win32-raw-mode "\033[?9001h" enabled,
> after brief input in the application becoming unresponsive and the session
> rapidly consumes all available memory/cpu..
>
> Test application attached, plus ticket
> https://github.com/micro
fter brief input in the application becoming unresponsive and the session
rapidly consumes all available memory/cpu..
Test application attached, plus ticket
https://github.com/microsoft/terminal/issues/17824 contains additional
information.
Regards
/*
* win32-input-mode key test
*
* Bui
On Thu, 22 Jun 2023 13:48:53 +0200
Corinna Vinschen wrote:
> On Jun 22 19:19, Takashi Yano via Cygwin wrote:
> > Any suggestions?
> >
> > On Tue, 20 Jun 2023 21:53:00 +0900
> > Takashi Yano wrote:
> > > I looked into this problem, and I think this is a problem regarding
> > > _my_tls initializatio
On Jun 22 19:19, Takashi Yano via Cygwin wrote:
> Any suggestions?
>
> On Tue, 20 Jun 2023 21:53:00 +0900
> Takashi Yano wrote:
> > I looked into this problem, and I think this is a problem regarding
> > _my_tls initialization order, so far. This seems to happen in LDAP
> > environment.
> >
> > M
Any suggestions?
On Tue, 20 Jun 2023 21:53:00 +0900
Takashi Yano wrote:
> On Sat, 10 Jun 2023 13:08:04 +0900 (JST)
> Takashi Yano wrote:
> > "M?min A." wrote:
> > > //windows cmd line
> > > C:\cygwin64\home\maydin\test>cygcheck ./main.exe
> > > C:\cygwin64\home\maydin\test\main.exe
> > > C:\cygw
On Sat, 10 Jun 2023 13:08:04 +0900 (JST)
Takashi Yano wrote:
> "M?min A." wrote:
> > //windows cmd line
> > C:\cygwin64\home\maydin\test>cygcheck ./main.exe
> > C:\cygwin64\home\maydin\test\main.exe
> > C:\cygwin64\bin\cygwin1.dll
> > C:\WINDOWS\system32\KERNEL32.dll
> > C:\WINDOWS\syst
"M?min A." wrote:
> //windows cmd line
> C:\cygwin64\home\maydin\test>cygcheck ./main.exe
> C:\cygwin64\home\maydin\test\main.exe
> C:\cygwin64\bin\cygwin1.dll
> C:\WINDOWS\system32\KERNEL32.dll
> C:\WINDOWS\system32\ntdll.dll
> C:\WINDOWS\system32\KERNELBASE.dll
>
> C:\cygwin64\
> I found a clue.
> I'm using cygwin as in windows environment path, C:\cygwin64\bin
>
> when I open the cygwin terminal , the test is passed but when I close
> cygwin terminal and run again the same test exe file then it fails.
>
> is there any connection about that ?
>
> The test is valid for
gt; #include
> #include
>
> int x = 0;
> int y = 0;
> int r1 = 0;
> int r2 = 0;
>
> pthread_barrier_t barrier;
>
> void* thread1(void* arg) {
> y = 1;
> pthread_barrier_wait(&barrier); // Memory barrier
> r1 = x;
> return NULL;
> }
>
On Thu, 8 Jun 2023 22:58:59 +
Mümin A. wrote:
> r1=0 and r2=0
> That is my result with Cygwin on windows. It’s false.
>
> When I compiled with gcc. The result is correct but when I use lasted Cygwin
> gcc in windows 10. The result is false.
I cannot reproduce your problem.
If I compile main
On Thursday, June 8, 2023 at 06:59:53 PM EDT, Mümin A. via Cygwin
wrote:
>
> r1=0 and r2=0
> That is my result with Cygwin on windows. It’s false.
>
> When I compiled with gcc. The result is correct but when I use lasted Cygwin
> gcc in windows 10. The result is false.
> cmake .
CMake Error
IH/NLM/NCBI) [C]
Sent: Thursday, June 8, 2023 5:37:31 PM
To: Mümin A. ; cygwin@cygwin.com
Subject: RE: [EXTERNAL] Memory Barriers at pthread using CYGWIN
> result should be
>
> r1 = 1, r2 = 1
>
And what was the result you saw?
Anton Lavrentiev
Contractor NIH/NLM/NCBI
--
Problem r
> result should be
>
> r1 = 1, r2 = 1
>
And what was the result you saw?
Anton Lavrentiev
Contractor NIH/NLM/NCBI
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: ht
tions(-D__POSIX_VISIBLE=200112 -D_POSIX_C_SOURCE=200112)
add_executable(test main.cpp)
target_link_libraries(test pthread)#include
#include
int x = 0;
int y = 0;
int r1 = 0;
int r2 = 0;
pthread_barrier_t barrier;
void* thread1(void* arg) {
y = 1;
pthread_barrier_wait(&barrier);
On 2021-02-22 14:50, Hans-Bernhard Bröker wrote:
Am 22.02.2021 um 21:30 schrieb Brian Inglis:
I've often wondered if the heavy activity is due to Windows' defaults to
writing files with F+RX perms which triggers executable virus scans?
That could only be the case if Windows actually had an 'x
Am 22.02.2021 um 21:30 schrieb Brian Inglis:
I've often wondered if the heavy activity is due to Windows' defaults to
writing files with F+RX perms which triggers executable virus scans?
That could only be the case if Windows actually had an 'x' permission bit.
--
Problem reports: https:/
On 2021-02-22 13:12, Doug Henderson wrote:
On Sun, 21 Feb 2021 at 08:21, Satalink wrote:
I deal with a lot of very large files on a regular basis. I've noticed that
when I delve into these directories using in mintty and issue the command ls
-l (or ls -color=auto), a very large junk of m
On Sun, 21 Feb 2021 at 08:21, Satalink via Cygwin wrote:
>
> I deal with a lot of very large files on a regular basis. I've noticed that
> when I delve into these directories using in mintty and issue the command ls
> -l (or ls -color=auto), a very large junk of memory i
On 2021-02-21 08:18, Satalink via Cygwin wrote:
I deal with a lot of very large files on a regular basis. I've noticed that
when I delve into these directories using in mintty and issue the command ls
-l (or ls -color=auto), a very large junk of memory is consumed. The
memory leak see
I deal with a lot of very large files on a regular basis. I've noticed that
when I delve into these directories using in mintty and issue the command ls
-l (or ls -color=auto), a very large junk of memory is consumed. The
memory leak seems to be proportionate to the number and size of
Thomas writes:
>> when trying out uf a certain shared memory allocator would work on
>> Cygwin, I tried out the sample program below (which works on Linunx,
>> *BSD, AIX and Solaris) and got a suprising falure
> Actually, the failure wasn't all that unexpected
I wrote:
when trying out uf a certain shared memory allocator would
work on Cygwin, I tried out the sample program below (which
works on Linunx, *BSD, AIX and Solaris) and got a suprising
falure
Actually, the failure wasn't all that unexpected, given that
I had put the ftruncate int
Hi,
when trying out uf a certain shared memory allocator would
work on Cygwin, I tried out the sample program below (which
works on Linunx, *BSD, AIX and Solaris) and got a suprising
falure with a segmentation fault at the line
*i1 = 42;
mmap() had succeeded.
Is this a known issue, and
[Once again, please don't top-post on this list.]
On 8/4/2020 9:35 AM, Cary Lewis wrote:
Thank you Ken, I followed your instructions and I am now able to use https and
composer with your versions of php.
Did you have to apply any of the cygport patches?
I applied all of them except for one h
:
> [Please don't top-post on this list.]
>
> On 8/3/2020 9:57 PM, Cary Lewis wrote:
> > I am running php on two different Windows 10 computers, and on one
> machine I can
> > run composer with no issues, but on other I get our of memory issues.
> >
> > Both re
[Please don't top-post on this list.]
On 8/3/2020 9:57 PM, Cary Lewis wrote:
I am running php on two different Windows 10 computers, and on one machine I can
run composer with no issues, but on other I get our of memory issues.
Both report:
php -v
PHP 7.3.7 (cli) (built: Jul 21 2019
I am running php on two different Windows 10 computers, and on one machine
I can run composer with no issues, but on other I get our of memory issues.
Both report:
php -v
PHP 7.3.7 (cli) (built: Jul 21 2019 18:10:35) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.3.7, Copyright (c
Hey Ken,
Thanks so much for looking into this further. I thought it was the malloc patch
too, in fact I can compile a PHP out of the box without any of the patches
Cygwin applies and it appears at a cursory glance to run fine and so I'm kinda
unsure as to why there are so many patches for Cygwi
On 7/18/2020 10:11 PM, Ken Brown via Cygwin wrote:
On 7/17/2020 5:39 PM, km2z7kca0oge--- via Cygwin wrote:
Hi there,
Recently I've noticed that PHP seems have to hard 4MB memory limit,
[...]
Example script:
```
file_get_contents('http://mirror.cwcs.co.uk/centos/8.2.2004/isos/x86
On 7/17/2020 5:39 PM, km2z7kca0oge--- via Cygwin wrote:
Hi there,
Recently I've noticed that PHP seems have to hard 4MB memory limit,
[...]
Example script:
```
http://mirror.cwcs.co.uk/centos/8.2.2004/isos/x86_64/CentOS-8.2.2004-x86_64-dvd1.iso');
// A large file such
versions from the `setup-x86-64.exe` (7.3.4-1 and 7.1.16-1)
>From below it appears you have also tested current PHP 7.3.7 with Zend 3.3.7.
One common issue with Cygwin installations causing memory problems is when
autorebase has not run or completed properly, so please try the following
command on
Oh, to add one more thing here, I've noticed there's a patch in the Cygwin
Source Package called `7.1.9-malloc-cygwin.patch` which references something to
do with Page sizes and 4096 which makes me wonder if this is interfering
somehow.
> +#define REAL_PAGE_SIZE 4096
--Jack
--
Problem repo
ws 10 64-bit (10.0.18363)
- One machine is 16GB, the other 8GB RAM.
- All PHP versions from the `setup-x86-64.exe` (7.3.4-1 and 7.1.16-1)
> - you have defaulted to or specified a PHP configuration limit of 4MB memory
> for PHP tasks, or
Nope, as shown in the output of my example, the
Greetings, km2z7kca0oge--- via Cygwin!
> Recently I've noticed that PHP seems have to hard 4MB memory limit, even
> when overridden in the settings. For whatever reason the bundled PHP
> versions with Cygwin have this problem.
> The failing message is `Out of memory` which ind
On 2020-07-17 15:39, km2z7kca0oge--- via Cygwin wrote:
> Recently I've noticed that PHP seems have to hard 4MB memory limit, even when
> overridden in the settings. For whatever reason the bundled PHP versions
> with Cygwin have this problem.
> The failing message is `Out
Hi there,
Recently I've noticed that PHP seems have to hard 4MB memory limit, even when
overridden in the settings. For whatever reason the bundled PHP versions with
Cygwin have this problem.
The failing message is `Out of memory` which indicates PHP thinks the system
has exhausted al
Yes, I reported this last week - composer (composer.phar) gives out of
memory errors, despite having max_memory_limit set to -1.
I have tried to compile php myself, but to no avail - php 7.3.19 doesn't
compile, there are errors in the zend framework.
php-7.3.19/Zend/zend_portability.h:3
I am running cygwin 64 bit and have installed the latest 7.3.7 version of
php.
When I attempt to run composer, I get a fatal out of memory error.
In my php.ini file I have set max memory to -1, and
php -r "echo ini_get('memory_limit').PHP_EOL;"
-1
confirms it.
I saw a s
Greetings, Richard H Lee!
> I've recently gotten out of memory errors with php, with tasks that
> previously have worked fine.
Which errors? Why don't you run your tasks in native PHP?
> Has anybody else experienced this too?
Useless question.
--
With best regards,
I've recently gotten out of memory errors with php, with tasks that
previously have worked fine.
Has anybody else experienced this too?
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs
Greetings, Takashi Yano!
> On Sun, 2 Feb 2020 23:52:26 +0300
> Andrey Repin wrote:
>> Trying to rebase a newly unpacked Cygwin snapshot leads to
>> 0 [main] dash (220072) shared_info::initialize: size of shared memory region
>> changed from 50104 to 49080
>>
>&
On Sun, 2 Feb 2020 23:52:26 +0300
Andrey Repin wrote:
> Trying to rebase a newly unpacked Cygwin snapshot leads to
> 0 [main] dash (220072) shared_info::initialize: size of shared memory region
> changed from 50104 to 49080
>
> Any hints?
Does not rebooting windows solve?
-
Greetings, All!
Trying to rebase a newly unpacked Cygwin snapshot leads to
0 [main] dash (220072) shared_info::initialize: size of shared memory region
changed from 50104 to 49080
Any hints?
--
With best regards,
Andrey Repin
Sunday, February 2, 2020 23:51:26
Sorry for my terrible english
gt; If the medium model is wasteful in clang, that's a clang
> > optimization problem, not a Cygwin problem.
>
> The medium model in Clang is not wasteful.
Your words:
* The memory models work differently in gcc an Clang. Gcc with a medium or
large memory model is using 64-bi
On 18/08/2019 13.57, Corinna Vinschen wrote:
Nope, Cygwin uses the Windows loader.
Then, how do you do the extra linking? What is producing the "Cygwin
runtime failure" message when loading/linking a DLL fails?
If the medium model is wasteful in clang, that's a clang
optimization problem,
the wrong model, that's all. That's
a bug in clang or whatever it's using under the hood. Clang should
follow what GCC does for years, using the medium model on Cygwin.
> When I complained to LLVM they said it was a Cygwin
> issue, and that you were using the wrong memory m
Thanks a lot for your help in clarifying this.
When I complained here about the wasteful 64-bit addresses you said that
it was an LLVM issue. When I complained to LLVM they said it was a
Cygwin issue, and that you were using the wrong memory model.
All this confusion is due to a terrible
", __progname);
}
EOF
$ cat > main.c < gcc is using the small memory model by default in Cygwin64, and it works.
No, it's not, see above.
> clang is using the small memory by default when cross-compiling for a
> Cygwin64 target from Linux, and it works.
...in *your* ex
address, and 64-bit
absolute address. The 32-bit absolute address can be used in Linux, but not in
Win64 and MacOS. This is why the small memory model is different in Linux and
Windows (64 bit).
Dynamic linking is done by the loader, not the linker. If a function in ab.exe
calls function C() in
Hey,
Just my 5 cents to this. As Corinna pointed out, is the case, that a
"small" memory model application works for you, no valid prove that
all application will work on such a model. Another thing, which
cygwin depends heavily on is the pseudo-relocation stuff. It is not
guaranteed
On Aug 16 12:38, Agner Fog wrote:
>
> On 16/08/2019 11.52, Corinna Vinschen wrote:
> > 2 GB. Think errno accessed from another DLL. Your application works only
> > by chance.
>
> Good example.
>
> errno appears to be a global variable for historical reasons, but errno is
> implemented as a macro
On 16/08/2019 11.52, Corinna Vinschen wrote:
2 GB. Think errno accessed from another DLL. Your application works
only by chance.
Good example.
errno appears to be a global variable for historical reasons, but errno
is implemented as a macro that translates to a call to the imported
functio
On Aug 16 11:27, Agner Fog wrote:
> Thanks for your replies.
>
> A Cygwin application with -mcmodel=small appears to work fine.
>
> As I explained, -mcmodel=small does something else when the target is
> Windows. It does not require addresses to be below 2GB, it only requires the
> distance betwe
s a Cygwin application it *must* at least
be compiled with -mcmodel=medium. The reason is the standarized
memory layout of Cygwin application and DLLs.
Linux Clang with --target=x86_64-pc-cygwin gives the small memory model.
Which is wrong.
I took this to the LLVM Bugzilla as you asked me
ast
be compiled with -mcmodel=medium. The reason is the standarized
memory layout of Cygwin application and DLLs.
> Linux Clang with --target=x86_64-pc-cygwin gives the small memory model.
Which is wrong.
> I took this to the LLVM Bugzilla as you asked me to:
> https://bugs.llvm.org/
to my
tests, while the right model is -mcmodel=small
Linux Clang with --target=x86_64-pc-cygwin gives the small memory model.
I took this to the LLVM Bugzilla as you asked me to:
https://bugs.llvm.org/show_bug.cgi?id=42983
Disclaimer: I am not a Cygwin maintainer or the Cygwin Clang maint
Cygwin Clang is using -mcmodel=medium as default for Win64, according to
my tests, while the right model is -mcmodel=small
Linux Clang with --target=x86_64-pc-cygwin gives the small memory model.
I took this to the LLVM Bugzilla as you asked me to:
https://bugs.llvm.org/show_bug.cgi?id=42983
On Jun 6 15:13, Stanislav Kascak wrote:
> > > [...]
> > > I played around a bit and I can confirm it would be consistent with
> > > current behavior:
> > > memwrite <0 - filesize) - no error, written to file
> > > memwrite > > memwrite <4k, 64k) - SIGSEGV
> > > memwrite <64k, mmap alloc size) - S
> > > > > > > > It seems that when mmap() is called with length argument
> > > > > > > > exceeding
> > > > > > > > size of file, only memory to fit that file is allocated.
> > > > > > > > munmap()
&g
On Jun 4 18:01, Stanislav Kascak wrote:
> > > > > > > It seems that when mmap() is called with length argument exceeding
> > > > > > > size of file, only memory to fit that file is allocated. munmap()
> > > > > > > however frees t
> > > > > > It seems that when mmap() is called with length argument exceeding
> > > > > > size of file, only memory to fit that file is allocated. munmap()
> > > > > > however frees the full specified length. [...]
> > > > >
On Jun 4 15:48, Stanislav Kascak wrote:
> > > > > It seems that when mmap() is called with length argument exceeding
> > > > > size of file, only memory to fit that file is allocated. munmap()
> > > > > however frees the full specified length. [...]
&
> > > > It seems that when mmap() is called with length argument exceeding
> > > > size of file, only memory to fit that file is allocated. munmap()
> > > > however frees the full specified length. Since (at least on my
> > > > computer) big chunk
On Jun 4 11:38, Stanislav Kascak wrote:
> > > It seems that when mmap() is called with length argument exceeding
> > > size of file, only memory to fit that file is allocated. munmap()
> > > however frees the full specified length. Since (at least on my
> >
> > It seems that when mmap() is called with length argument exceeding
> > size of file, only memory to fit that file is allocated. munmap()
> > however frees the full specified length. Since (at least on my
> > computer) big chunk of memory allocated by calloc() i
On May 3 13:33, Stanislav Kascak wrote:
> Hello cygwin team,
>
> I came across a problem with memory allocation/deallocation when
> trying to compile and run tests of openldap under cygwin.
>
> I created a test program to simulate sequence of actions. First a
> bigger chu
On 5/3/2019 7:33 AM, Stanislav Kascak wrote:
> I came across a problem with memory allocation/deallocation when
> trying to compile and run tests of openldap under cygwin.
Corinna can give you a definitive response when she returns from vacation, but
I
looked at the code and have a few co
Hello cygwin team,
I came across a problem with memory allocation/deallocation when
trying to compile and run tests of openldap under cygwin.
I created a test program to simulate sequence of actions. First a
bigger chunk of memory (>~262kB) is allocated using calloc(), then
mmap() is called w
> >>>>> 3.22.28) of 2018-05-28
> >>>>> This started happening about the time I upgraded to Cygwin 3.0.x.
> >>>>
> >>>> See http://www.cygwin.org/ml/cygwin/2019-03/msg00122.html, and try the
> >>>> latest cygwin snap
>>> -Original Message-
>>> From: cygwin-ow...@cygwin.com On Behalf Of
>>> Ken Brown
>>> Sent: Thursday, March 07, 2019 9:09 AM
>>>> To: cygwin@cygwin.com
>>>> Subject: Re: emacs-X11 memory leak?
>>
>>>> On 3
On 3/7/2019 3:00 PM, Rockefeller, Harry wrote:
>
>>> -Original Message-
>>> From: cygwin-ow...@cygwin.com On Behalf Of
>>> Ken Brown
>>> Sent: Thursday, March 07, 2019 9:09 AM
>>> To: cygwin@cygwin.com
>>> Subject: Re: emacs-X11 me
>>-Original Message-
>>From: cygwin-ow...@cygwin.com On Behalf Of
>>Ken Brown
>>Sent: Thursday, March 07, 2019 9:09 AM
>>To: cygwin@cygwin.com
>>Subject: Re: emacs-X11 memory leak?
>>On 3/7/2019 9:53 AM, Rockefeller, Harry wrote:
>>>
>-Original Message-
>From: cygwin-ow...@cygwin.com On Behalf Of Ken Brown
>Sent: Thursday, March 07, 2019 9:09 AM
>To: cygwin@cygwin.com
>Subject: Re: emacs-X11 memory leak?
>On 3/7/2019 9:53 AM, Rockefeller, Harry wrote:
>> CYGWIN_NT-6.1 HARRYR-PC 3.0.1(0.3
not claiming
> there is a memory leak, but rather how to test what's going on.
>
> I don't know if this is relevant. I got this error when I started emacs with
> -Q option:
> ** (emacs:2017): WARNING **: Error retrieving accessibility bus address:
> org.freedesktop.DB
CYGWIN_NT-6.1 HARRYR-PC 3.0.1(0.338/5/3) 2019-02-20 10:19 x86_64 Cygwin
GNU Emacs 26.1 (build 1, x86_64-unknown-cygwin, GTK+ Version 3.22.28) of
2018-05-28
I got egg on my face with my last post to Cygwin. So, no, I'm not claiming
there is a memory leak, but rather how to test what'
On Aug 21 16:53, Livio Bertacco wrote:
> Thanks Corinna, I tried the developer snapshot and the VmSize line from
> "status" file looks good now.
>
> What do you think about adding the VmPeak line too? (I can create the patch
> myself).
>
> > On second thought there's more wrong than just that.
>
inschen
> To: cygwin@cygwin.com
> Cc:
> Bcc:
> Date: Fri, 17 Aug 2018 20:44:02 +0200
> Subject: Re: memory reported in /proc/pid/status is wrongly scaled
> On Aug 17 19:14, Corinna Vinschen wrote:
> > On Aug 17 16:05, Livio Bertacco wrote:
> > > Hi,
> > >
On Aug 17 19:14, Corinna Vinschen wrote:
> On Aug 17 16:05, Livio Bertacco wrote:
> > Hi,
> > While playing with reading process memory usage in Linux and cygwin, I
> > found that cygwin reports too large values in /proc/self/status (in 2.10.0
> > and earlier).
> >
On Aug 17 16:05, Livio Bertacco wrote:
> Hi,
> While playing with reading process memory usage in Linux and cygwin, I
> found that cygwin reports too large values in /proc/self/status (in 2.10.0
> and earlier).
> Whenever I was allocating a few kB in my test program, the VmSize
Hi,
While playing with reading process memory usage in Linux and cygwin, I
found that cygwin reports too large values in /proc/self/status (in 2.10.0
and earlier).
Whenever I was allocating a few kB in my test program, the VmSize line in
/proc/self/status was growing several times faster.
Small
8, St=C3=A9phane Mbape via cygwin wrote:
> > > Hello,
> > >=20
> > > While embeding luajit in a c=C2=A0 program, I found myself unable to fork
> > > processes.
> > > Investigations prove that it was related to nmap.
> > > To be accurate, calli
coding: quoted-printable
> >
> > On Dec 9 15:58, St=C3=A9phane Mbape via cygwin wrote:
> > > Hello,
> > >=20
> > > While embeding luajit in a c=C2=A0 program, I found myself unable to fork
> > > processes.
> > > Investigations prove that it w
gt; While embeding luajit in a c=C2=A0 program, I found myself unable to fork
> processes.
> Investigations prove that it was related to nmap.
> To be accurate, calling nmap with hint address in a unmapped memory region
> will cause all forks to fail with
> "fixup_mmaps_after_fork:
;=20
> > While embeding luajit in a c=C2=A0 program, I found myself unable to fork
> > processes.
> > Investigations prove that it was related to nmap.
> > To be accurate, calling nmap with hint address in a unmapped memory region
> > will cause all forks to fail wi
On Dec 9 15:58, Stéphane Mbape via cygwin wrote:
> Hello,
>
> While embeding luajit in a c program, I found myself unable to fork
> processes.
> Investigations prove that it was related to nmap.
> To be accurate, calling nmap with hint address in a unmapped memory region
>
embeding luajit in a c program, I found myself unable to fork
> >>>>> processes.
> >>>>> Investigations prove that it was related to nmap.
> >>>>> To be accurate, calling nmap with hint address in a unmapped memory
> >>>>
lf unable to fork
>>>>> processes.
>>>>> Investigations prove that it was related to nmap.
>>>>> To be accurate, calling nmap with hint address in a unmapped memory
>>>>> region will cause all forks to fail with
>>>>> "fixup_mmaps_af
unmapped
memory
region will cause all forks to fail with
"fixup_mmaps_after_fork: ReadProcessMemory failed for MAP_PRIVATE
address 0x6FE, Win32 error 299"
There is a sample code below.
You forgot to ment
nmap with hint address in a unmapped memory
region will cause all forks to fail with
"fixup_mmaps_after_fork: ReadProcessMemory failed for MAP_PRIVATE
address 0x6FE, Win32 error 299"
There is a sample code below.
You forgot to mention Cygwin version you're using, and ple
ns prove that it was related to nmap.
>>>> To be accurate, calling nmap with hint address in a unmapped memory
>>>> region will cause all forks to fail with
>>>> "fixup_mmaps_after_fork: ReadProcessMemory failed for MAP_PRIVATE
>>>> address 0
rate, calling nmap with hint address in a unmapped memory
>>> region will cause all forks to fail with
>>> "fixup_mmaps_after_fork: ReadProcessMemory failed for MAP_PRIVATE
>>> address 0x6FE, Win32 error 299"
>>> There is a sample code below.
>
1 - 100 of 1029 matches
Mail list logo
