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
On Thu, Jun 08, 2023 at 05:29:59PM +0300, cygwin wrote:
> Hi,
>
> I wrote a simple test for pthread_barrier_wait. it won't work as expected.
>
> result should be
>
> r1 = 1, r2 = 1
>
> Thanks,
> Mümin
> cmake_minimum_required(VERSION 3.26)
>
> project(test)
>
> set(CMAKE_CXX_STANDARD 14)
> set(CMA
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 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).
> > Whenever I was allocating a few
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 line in
> /proc/sel
Marco
Thanks for the information. It has proved helpful. And apologies posting to the
wrong email address.
Martin O'Shea.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe
please reply on the mailing list and
use bottom post for replies as standard practice.
On 22/03/2017 07:50, Martin O'Shea wrote:
Thanks for the response but can I ask that you clarify what you mean?
I am something of a Cygwin newbie.
I also do not understand why the memory checker program ret
On 22/03/2017 00:06, Martin O'Shea wrote:
Hello
I am using a 64 bit GCC compiler in NetBeans to compile a series of C
programs which use the GMP multiple precision library to calculate numbers
with varying lengths of zeroes. The programs are called from a shell script
run from NetBeans or using
Hello,
I have test my patch, but it not resolve my memory issue (
http://cygwin.com/ml/cygwin/2011-04/msg00292.html )
Regards,
Thomas
2011/4/20 Corinna Vinschen
> On Apr 20 15:16, Thomas Stalder wrote:
>> I don't know, it's just a question. The patch are not tested.
>
> Maybe you should actuall
On Apr 20 15:16, Thomas Stalder wrote:
> Hello,
>
> I just have a question, the same change would it not necessary for the
> functions: serial_cleanup, mailslot_cleanup and socket_cleanup in
> select.cc (like attached patch) ?
>
> I don't know, it's just a question. The patch are not tested.
May
Hello,
I just have a question, the same change would it not necessary for the
functions: serial_cleanup, mailslot_cleanup and socket_cleanup in
select.cc (like attached patch) ?
I don't know, it's just a question. The patch are not tested.
Regards,
Thomas
2011/4/20 Christopher Faylor
>>2011-04
Den 2011-04-20 03:10 skrev Christopher Faylor:
> On Tue, Apr 19, 2011 at 11:31:38PM +0200, Peter Rosin wrote:
>>> Den 2011-04-18 13:43 skrev Peter Rosin:
Using the following STC, I'm seeing what appears to be a memory
leak in select(2).
>> Back with a patch this time. Fixes i
On Tue, Apr 19, 2011 at 11:31:38PM +0200, Peter Rosin wrote:
>Den 2011-04-18 21:23 skrev Peter Rosin:
>> Den 2011-04-18 17:28 skrev Christopher Faylor:
>>> On Mon, Apr 18, 2011 at 11:24:41AM -0400, Christopher Faylor wrote:
On Mon, Apr 18, 2011 at 04:32:10PM +0200, Peter Rosin wrote:
> Den
Den 2011-04-18 21:23 skrev Peter Rosin:
> Den 2011-04-18 17:28 skrev Christopher Faylor:
>> On Mon, Apr 18, 2011 at 11:24:41AM -0400, Christopher Faylor wrote:
>>> On Mon, Apr 18, 2011 at 04:32:10PM +0200, Peter Rosin wrote:
Den 2011-04-18 14:23 skrev Peter Rosin:
> Den 2011-04-18 13:43 sk
Den 2011-04-18 17:24 skrev Christopher Faylor:
> On Mon, Apr 18, 2011 at 04:32:10PM +0200, Peter Rosin wrote:
>> Den 2011-04-18 14:23 skrev Peter Rosin:
>>> Den 2011-04-18 13:43 skrev Peter Rosin:
Hi!
Using the following STC, I'm seeing what appears to be a memory
leak in select
Den 2011-04-18 17:28 skrev Christopher Faylor:
> On Mon, Apr 18, 2011 at 11:24:41AM -0400, Christopher Faylor wrote:
>> On Mon, Apr 18, 2011 at 04:32:10PM +0200, Peter Rosin wrote:
>>> Den 2011-04-18 14:23 skrev Peter Rosin:
Den 2011-04-18 13:43 skrev Peter Rosin:
> Hi!
>
> Using t
On Mon, Apr 18, 2011 at 11:24:41AM -0400, Christopher Faylor wrote:
>On Mon, Apr 18, 2011 at 04:32:10PM +0200, Peter Rosin wrote:
>>Den 2011-04-18 14:23 skrev Peter Rosin:
>>> Den 2011-04-18 13:43 skrev Peter Rosin:
Hi!
Using the following STC, I'm seeing what appears to be a memory
On Mon, Apr 18, 2011 at 04:32:10PM +0200, Peter Rosin wrote:
>Den 2011-04-18 14:23 skrev Peter Rosin:
>> Den 2011-04-18 13:43 skrev Peter Rosin:
>>> Hi!
>>>
>>> Using the following STC, I'm seeing what appears to be a memory
>>> leak in select(2).
>>>
>> 8<---(selectleak.c)-
Den 2011-04-18 14:23 skrev Peter Rosin:
> Den 2011-04-18 13:43 skrev Peter Rosin:
>> Hi!
>>
>> Using the following STC, I'm seeing what appears to be a memory
>> leak in select(2).
>>
> 8<---(selectleak.c)-
> #include
> #include
>
> int
> main(void)
> {
> fd_set fds
Den 2011-04-18 13:43 skrev Peter Rosin:
> Hi!
>
> Using the following STC, I'm seeing what appears to be a memory
> leak in select(2).
>
> 8<---(selectleak.c)-
> #include
> #include
> #include
>
> int
> main(void)
> {
> fd_set fdset;
> struct timeval tv;
>
On Wed, Oct 08, 2008 at 11:07:05PM +0200, Bob van Loosen wrote:
>Larry Hall (Cygwin) wrote:
>>Bob van Loosen wrote:
>>>Christopher Faylor wrote:
On Wed, Oct 08, 2008 at 02:45:55AM +0200, Bob van Loosen wrote:
>Christopher Faylor wrote:
>>This should be fixed in the next snapshot.
Larry Hall (Cygwin) wrote:
Bob van Loosen wrote:
Christopher Faylor wrote:
On Wed, Oct 08, 2008 at 02:45:55AM +0200, Bob van Loosen wrote:
Christopher Faylor wrote:
This should be fixed in the next snapshot. If you are looking for a
workaround, specifically set the sigev_notify_attribut
Bob van Loosen wrote:
Christopher Faylor wrote:
On Wed, Oct 08, 2008 at 02:45:55AM +0200, Bob van Loosen wrote:
Christopher Faylor wrote:
This should be fixed in the next snapshot. If you are looking for a
workaround, specifically set the sigev_notify_attributes to
PTHREAD_CREATE_DETACH
Christopher Faylor wrote:
On Wed, Oct 08, 2008 at 02:45:55AM +0200, Bob van Loosen wrote:
Christopher Faylor wrote:
This should be fixed in the next snapshot. If you are looking for a
workaround, specifically set the sigev_notify_attributes to
PTHREAD_CREATE_DETACHED.
Thanks, t
On Wed, Oct 08, 2008 at 02:45:55AM +0200, Bob van Loosen wrote:
> Christopher Faylor wrote:
>> This should be fixed in the next snapshot. If you are looking for a
>> workaround, specifically set the sigev_notify_attributes to
>> PTHREAD_CREATE_DETACHED.
>
> Thanks, that fixed it.
> Shouldn't PTHRE
Christopher Faylor wrote:
On Wed, Oct 08, 2008 at 12:08:52AM +0200, Bob van Loosen wrote:
Hi all,
When using a timer I seem to be getting a memory leak.
It eats up about 8 kilobyte per second.
Here's some example code:
#include
#include
#include
#include
#include
void nothing(){}
voi
On Wed, Oct 08, 2008 at 12:08:52AM +0200, Bob van Loosen wrote:
> Hi all,
>
> When using a timer I seem to be getting a memory leak.
> It eats up about 8 kilobyte per second.
>
> Here's some example code:
>
> #include
> #include
> #include
> #include
> #include
>
> void nothing(){}
> void Die(
Bob van Loosen wrote on 07 October 2008 23:09:
> Hi all,
>
> When using a timer I seem to be getting a memory leak.
> It eats up about 8 kilobyte per second.
Mmmm, yeah, how interesting. Confirmed: the WS just keeps getting bigger
and there's a constant rate of pagefaults per second. Somethi
Michael Chen schrieb:
What do the Cygwin development team recommend for checking memory
leaks/violations in Cygwin applications (C/C++)?
Valgrind is not available for Cygwin, and I am told by IBM/Rational that
PurifyPlus for Windows does not (and I confirmed) support GCC compiled code.
I only
Corinna Vinschen wrote:
On Feb 5 17:23, Jerry DeLisle wrote:
Corinna Vinschen wrote:
On Feb 4 17:24, Christopher Faylor wrote:
On Mon, Feb 04, 2008 at 01:25:27PM -0800, Jerry DeLisle wrote:
The test also appears very clean on Linux. The gfortran library is
implemented in C. I need to exam
On Feb 5 17:23, Jerry DeLisle wrote:
> Corinna Vinschen wrote:
>> On Feb 4 17:24, Christopher Faylor wrote:
>>> On Mon, Feb 04, 2008 at 01:25:27PM -0800, Jerry DeLisle wrote:
The test also appears very clean on Linux. The gfortran library is
implemented in C. I need to examine some du
Corinna Vinschen wrote:
On Feb 4 17:24, Christopher Faylor wrote:
On Mon, Feb 04, 2008 at 01:25:27PM -0800, Jerry DeLisle wrote:
The test also appears very clean on Linux. The gfortran library is
implemented in C. I need to examine some dumps from the compiler and I
will get back with you of
On Feb 4 17:24, Christopher Faylor wrote:
> On Mon, Feb 04, 2008 at 01:25:27PM -0800, Jerry DeLisle wrote:
> >The test also appears very clean on Linux. The gfortran library is
> >implemented in C. I need to examine some dumps from the compiler and I
> >will get back with you off list if I don't
Dave Korn wrote:
On 04 February 2008 22:25, Christopher Faylor wrote:
On Mon, Feb 04, 2008 at 01:25:27PM -0800, Jerry DeLisle wrote:
The test also appears very clean on Linux. The gfortran library is
implemented in C. I need to examine some dumps from the compiler and I
will get back with yo
On 04 February 2008 22:25, Christopher Faylor wrote:
> On Mon, Feb 04, 2008 at 01:25:27PM -0800, Jerry DeLisle wrote:
>> The test also appears very clean on Linux. The gfortran library is
>> implemented in C. I need to examine some dumps from the compiler and I
>> will get back with you off list
On Mon, Feb 04, 2008 at 01:25:27PM -0800, Jerry DeLisle wrote:
>The test also appears very clean on Linux. The gfortran library is
>implemented in C. I need to examine some dumps from the compiler and I
>will get back with you off list if I don't spot the problem.
I am fairly certain that Corinn
Corinna Vinschen wrote:
On Feb 3 11:24, Jerry DeLisle wrote:
I have confirmed this problem on Cygwin reported here:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35063
I am not very familiar with the windows environment. Having patched most
of the gfortran I/O library in the last 2-3 years I
On Feb 3 19:03, Jerry DeLisle wrote:
> I have continued my testing here and I am seeing this with valgrind on
> linux. When I was running the 1 loops I did not see these errors roll
> by upfront initially.
>
> ==25454== Conditional jump or move depends on uninitialised value(s)
> ==25454==
On Feb 3 11:24, Jerry DeLisle wrote:
> I have confirmed this problem on Cygwin reported here:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35063
>
> I am not very familiar with the windows environment. Having patched most
> of the gfortran I/O library in the last 2-3 years I can say that we d
Angelo Graziosi wrote:
Jerry DeLisle wrote:
I have confirmed this problem on Cygwin reported here:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35063
I do not know if this can help, but...
Building the above test with G95, it does not fail!
If I have understood it, I have pressed 1 ENTER
Jerry DeLisle wrote:
I have confirmed this problem on Cygwin reported here:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35063
I do not know if this can help, but...
Building the above test with G95, it does not fail!
If I have understood it, I have pressed 1 ENTER without problem!
With
Dave Korn wrote:
On 03 February 2008 19:24, Jerry DeLisle wrote:
I have confirmed this problem on Cygwin reported here:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35063
Those of you most familiar with the Windows environment could perhaps help
here. Is this a bug in Cygwin memory manag
On 03 February 2008 19:24, Jerry DeLisle wrote:
> I have confirmed this problem on Cygwin reported here:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35063
> Those of you most familiar with the Windows environment could perhaps help
> here. Is this a bug in Cygwin memory management?
Ar
On 2008-02-03 19:24Z, Jerry DeLisle wrote:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35063
[...]
> Is this a bug in Cygwin memory management?
According to this report (marked in bugzilla as a duplicate):
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35064
a similar problem was observed
Jerry DeLisle wrote:
I have confirmed this problem on Cygwin reported here:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35063
I am not very familiar with the windows environment. Having patched
most of the gfortran I/O library in the last 2-3 years I can say that
we do a lot of memory alloca
On 21 June 2007 08:31, Edgar Matzinger wrote:
> Hi Dave,
>
> On 06/10/2007 11:46:35 PM, Dave Korn wrote:
>> On 10 June 2007 13:00, Edgar Matzinger wrote:
>>
>>> Hello list,
>>>
>>> I wonder if there is a memory leakage problem with the current cygwin
>>> release. After upgrading to it, and tr
Hi Dave,
On 06/10/2007 11:46:35 PM, Dave Korn wrote:
> On 10 June 2007 13:00, Edgar Matzinger wrote:
>
> > Hello list,
> >
> > I wonder if there is a memory leakage problem with the current cygwin
> > release. After upgrading to it, and trying to compile Gnome (using
> > garnome), the memory u
Christopher Faylor cygwin.com> writes:
On Sun, Jun 10, 2007 at 10:16:41PM +, Mark Geisert wrote:
> [original question and my incorrect analysis elided...]
>
> ...and if all Cygwin processes are subsequently exited then it isn't
> Cygwin's fault either. Let's not go down this path again. Cyg
On 11 June 2007 00:21, Christopher Faylor wrote:
> On Sun, Jun 10, 2007 at 10:16:41PM +, Mark Geisert wrote:
>> Dave Korn writes:
>>>
>>> On 10 June 2007 13:00, Edgar Matzinger wrote:
>>>
>> I run this for a while and see gradually increasing memory usage. Even
>> when all Cygwin processes
On Sun, Jun 10, 2007 at 10:16:41PM +, Mark Geisert wrote:
>Dave Korn writes:
>>
>> On 10 June 2007 13:00, Edgar Matzinger wrote:
>>
>> > I wonder if there is a memory leakage problem with the current cygwin
>> > release. After upgrading to it, and trying to compile Gnome (using
>> > garnome
Dave Korn writes:
>
> On 10 June 2007 13:00, Edgar Matzinger wrote:
>
> > I wonder if there is a memory leakage problem with the current cygwin
> > release. After upgrading to it, and trying to compile Gnome (using
> > garnome), the memory usage keeps increasing. Even after I've stopped
> > the
On 10 June 2007 13:00, Edgar Matzinger wrote:
> Hello list,
>
> I wonder if there is a memory leakage problem with the current cygwin
> release. After upgrading to it, and trying to compile Gnome (using
> garnome), the memory usage keeps increasing. Even after I've stopped
> the building proces
From: Reini Urban
emacs user schrieb:
I have reported this problem to the gnu emacs developers a few
times, but it seems that emacs is not actively maintained for cygwin
right now. perhaps someone here can help? I am happy to provide more
details if needed. thanks...
A brief problem d
emacs user schrieb:
I have reported this problem to the gnu emacs developers a few times,
but it seems that emacs is not actively maintained for cygwin right
now. perhaps someone here can help? I am happy to provide more details
if needed. thanks...
A brief problem description:
memory us
Ugh, top-posting... Reformatted.
On Mon, 12 Jun 2006, Thomas SMETS wrote:
> From: Igor Pechtchanski
> To: Thomas Baker
> Cc: cygwin at cygwin dot com
> Date: Mon, 6 Jun 2005 10:26:26 -0400 (EDT)
> Subject: Re: Memory error with PDKSH 5.2.14-3?
>
> > On Mon, 6 Jun
One year later (with the same/latest version)
Using :
set -x
set -v
in a script generates a similar error around line 50whatever code I put in the
script
\T,
Re: Memory error with PDKSH 5.2.14-3? From: Igor Pechtchanski To: Thomas Baker Cc:
cygwin at cygwin dot comDate: Mon
One year later (with the same/latest version)
Using :
set -x
set -v
in a script generates a similar error around line 50whatever code I put in the
script
\T,
Re: Memory error with PDKSH 5.2.14-3? From: Igor Pechtchanski To: Thomas Baker Cc:
cygwin at cygwin dot comDate
On Wed, Mar 15, 2006 at 02:39:45PM -0600, Paul Mattes wrote:
>I believe I have found a memory leak in the Cygwin version of
>vsnprintf(). If it is called with a NULL 'str' parameter and a 0
>'length', it leaks a BUFSIZ-sized buffer. (Per C99 and SUSv3, calling
>vsnprintf() with a NULL 'str' an
On Mon, Jun 06, 2005 at 10:26:26AM -0400, Igor Pechtchanski wrote:
> On Mon, 6 Jun 2005, Thomas Baker wrote:
> > Just wanted to report that I was seeing error messages such as the
> > following in Korn shell scripts:
> >
> > /home/tbaker/u/bin/urlists[50]: internal error: alloc: freeing
> >
On Mon, 6 Jun 2005, Thomas Baker wrote:
> Just wanted to report that I was seeing error messages such as the
> following in Korn shell scripts:
>
> /home/tbaker/u/bin/urlists[50]: internal error: alloc: freeing
> memory outside of block (corrupted?)
>
> By running the scripts in debug mo
Charles D. Russell wrote:
The following seems important enough to fortran users
> to be indexed by an appropriate subject header.
I am reluctant to upgrade because the use of large static
fortran arrays with cygwin/g77 seems to be a fragile issue
and my current installation is now working (but
On Feb 25 09:39, Bertalan Fodor wrote:
> Dear developers and experts,
>
> is there a way in Cygwin to use facilities like those available in GNU
> libc for memory/stream handling, like documented in:
>
> http://www.gnu.org/software/libc/manual/html_node/String-Streams.html
> http://www.gnu.org/s
Charles D. Russell wrote:
Dante Chialvo wrote:
I think the following quote is from a message of mine...
> I have the same problem. I have g77, g95 and >grfortran (gfc)
installed (see below). With >heap_chunk_in_mb set to 1024, on a machine
with >1024 MiB RAM< I can run a simple Fortran >program
Dante Chialvo wrote:
> I have the same problem. I have g77, g95 and >grfortran (gfc)
installed (see below). With >heap_chunk_in_mb set to 1024, on a machine
with >1024 MiB RAM< I can run a simple Fortran >program with an array of
up to ~ 1023 MiB. With >g77 & gfc the limit is 156 MiB and beyond
At 07:27 AM 1/27/2005, you wrote:
>-
>Dear Cygwin Developers,
>
>I have a problem with running code which require High RAM Memory,
>if I run this code in Windows Xp enviroment it runs,
>if I use regular Redhat Linux also, but if I use Cygwin it produce message:
>
>MapViewOfFileEx(0x728, in_h 0x728
Dave Korn wrote:
From: cygwin-owner On Behalf Of Mark Hadfield
Sent: 10 January 2005 21:18
Is there a cure that would allow a simple-minded, grey-haired Fortran
programmer like me to rely on Cygwin g77 (or gfortran) for
moderate-sized computational tasks?
LOL, I love the subtle sense of understa
> -Original Message-
> From: cygwin-owner On Behalf Of Mark Hadfield
> Sent: 10 January 2005 21:18
> Is there a cure that would allow a simple-minded, grey-haired Fortran
> programmer like me to rely on Cygwin g77 (or gfortran) for
> moderate-sized computational tasks?
LOL, I love the
Dave Korn wrote:
From: cygwin-owner On Behalf Of Mark Hadfield
Dante R. Chialvo wrote:
2) Use g77 using the Wl option, ie,
g77 -O2 -o mybigprogram -Wl,--stack,1 mybigprogram.f
That's odd. Increasing the stack size definitely does not
work for me.
It just causes the program to terminate
> -Original Message-
> From: cygwin-owner On Behalf Of Mark Hadfield
> Sent: 09 January 2005 21:27
> Dante R. Chialvo wrote:
> > Thanks for the suggestions
> > Bottom line both ideas work fine in my case:
> >
> > 1) Install the g95 compiler,
> > or
> > 2) Use g77 using the Wl option, ie,
Dante R. Chialvo wrote:
Thanks for the suggestions
Bottom line both ideas work fine in my case:
1) Install the g95 compiler,
or
2) Use g77 using the Wl option, ie,
g77 -O2 -o mybigprogram -Wl,--stack,1 mybigprogram.f
So thanks a lot,
That's odd. Increasing the stack size definitely
Thanks for the suggestions
Bottom line both ideas work fine in my case:
1) Install the g95 compiler,
or
2) Use g77 using the Wl option, ie,
g77 -O2 -o mybigprogram -Wl,--stack,1 mybigprogram.f
So thanks a lot,
Dante
Dave Korn wrote:
>
> > -Original Message-
> > From: cy
Dave Korn wrote:
It may also be possible to workaround the problem by fooling around with the
default stack allocation size; this can have knock-on effects which clear up the
reserved area of the process' memory map that error message is complaining
about.
See
http://www.cygwin.com/ml/cygwin/
> -Original Message-
> From: cygwin-owner On Behalf Of Mark Hadfield
> Sent: 06 January 2005 00:58
> Dante Chialvo wrote:
> > I have similar problem than the one posted a while ago in
> >
> > http://www.cygwin.com/ml/cygwin/2003-02/msg00842.html
> >
> > Using cygwin/g77, in a PC with 102
Dante Chialvo wrote:
I have similar problem than the one posted a while ago in
http://www.cygwin.com/ml/cygwin/2003-02/msg00842.html
Using cygwin/g77, in a PC with 1024 Mb of physical memory.
After compiling and running the following test program
the limit of 160 Mb cannot be surpassed.
implici
Dan Osborne schrieb:
Reini Urban wrote:
Great shame that valgrind isn't ported to cygwin!
but dmalloc is.
after libtoolizing and autoreconf with latest autotools just add
AM_WITH_DMALLOC to your configure.in
Hmmm, I've yet to bite the libtool bullet but if it gets dmalloc working
maybe nows the tim
Reini Urban wrote:
>>> Great shame that valgrind isn't ported to cygwin!
>
> but dmalloc is.
> after libtoolizing and autoreconf with latest autotools just add
> AM_WITH_DMALLOC to your configure.in
Hmmm, I've yet to bite the libtool bullet but if it gets dmalloc working
maybe nows the time to do
Maarten Boekhold schrieb:
Dan Osborne wrote:
Could you get the test program to work? That shows how it wants to play.
The only problem I found with it was that it wouldn't follow shared
objects.
Yeah, that seems to be the problem I have to. Unfortunately the memory
corruption I'm looking for is
Dan Osborne wrote:
Could you get the test program to work? That shows how it wants to play.
The only problem I found with it was that it wouldn't follow shared objects.
Yeah, that seems to be the problem I have to. Unfortunately the memory
corruption I'm looking for is *in* a shared object. And c
splint is available via setup also.
www.splint.org
Maarten Boekhold wrote:
Hi all,
I have a program that segfaults, and it's quite obvious that this is
caused due to some memory corruption. Except it segfaults at a place
where, if running it in gdb, there shouldn't be a problem. There seems
to b
There's a package called Memory Watcher/memwatch designed for cygwin which
I've used.
I can't find a URL but this is from the README and a web search should find
it ...
Memory Watcher
==
This is a little library for tracing memory related api calls on cygwin
using gcc.
Features:
- d
At 12:56 PM 30/05/04, you wrote:
At 10:55 PM 5/29/2004, you wrote:
>I have 512 MB RAM but my application (openDX) will not access more than
24 MB (even though its docum'n says it will grab 7/8 of free RAM by
default). I have seen postings by other users with different apps (e.g.
ImageMagick) tha
On Sun, 30 May 2004 12:55:35 +1000, Allen H. Nugent wrote:
> I have 512 MB RAM but my application (openDX) will not access more than 24 MB
The Cygwin default is 384 MB, so I'm not sure if Cygwin is causing your problem.
> Are there some settings I can tweak so that cygwin will allocate a decent
At 10:55 PM 5/29/2004, you wrote:
>I have 512 MB RAM but my application (openDX) will not access more than 24 MB (even
>though its docum'n says it will grab 7/8 of free RAM by default). I have seen
>postings by other users with different apps (e.g. ImageMagick) that were also limited
>to 24 MB u
> -Original Message-
> From: cygwin-owner On Behalf Of Dave Korn
> I can confirm that there are definitely memory management
> problems in Agnitum outpost. [...SNIP!...]
Heh, let me just make the implications of that last post explicit: In reply
to the original poster, I regularly
> -Original Message-
> From: cygwin-owner On Behalf Of Luc Hermitte
> * On Fri, Jan 30, 2004 at 04:25:20PM +0600, Mike Jastrebtsoff
> wrote:
> > While fulfilling of any building procedure under cygwin via make,
> > configure(utils, that widely use spawning of other
> processes) appea
Hello,
* On Fri, Jan 30, 2004 at 04:25:20PM +0600, Mike Jastrebtsoff <[EMAIL PROTECTED]>
wrote:
> While fulfilling of any building procedure under cygwin via make,
> configure(utils, that widely use spawning of other processes) appears
> memory leak, that leads to termination of building process:
Benson Margulies wrote:
Would anyone be willing to elaborate on how the existing code is going
about accomplishing the task at hand? If not, at least knowing that this
is the goal of the exercise should make it easier to get a clue.
I believe that there is some documentation in a file in the CVS f
I've belatedly located Corinna Vinschen's email message about the
requirement for the stack address in fork.
Would anyone be willing to elaborate on how the existing code is going
about accomplishing the task at hand? If not, at least knowing that this
is the goal of the exercise should make it e
On Dec 9 12:55, Benson Margulies wrote:
> I assume that there's a very strong reason why this code can't just
> allocate a stack any-old-place (calling VirtualAlloc with first arg 0)
> and use it. What I don't understand is the nature of the constraints. If
> the parent needs to know, why not have
This looks like a logic error in fork.cc/dcrt0.cc to me, but I'm
probably not understanding something.
alloc_stack_hard_way assumes that the memory at ci->stacktop is
available. ci->stacktop is set to be the region of memory that contains
a stack variable in the parent process at the time that sta
The error message rather unambiguously indicates that VirtualAlloc is
returning 0 with GetLastError() == 0. The call in question calls
VirtualAlloc with parameters derived from a call to VirtualQuery against
some stack storage. It seems that this version of Windows is not
altogether pleased to see
cc: (bcc: Jurgen Defurne/BRG/CE/PHILIPS)
Subject: Re: Memory Management on AMD64 in 32-bit mode
Classification:
On Mon, Dec 08, 2003 at 07:30:17PM -0500, Benson Margulies wrote:
>I happen to have access to a an AMD64 system running Windows. All the
>cygwin sh
On Mon, Dec 08, 2003 at 07:30:17PM -0500, Benson Margulies wrote:
>I happen to have access to a an AMD64 system running Windows. All the
>cygwin shells fail to fork with the following. I'd be willing to try
>coding and running a patch if the experts would care to offer an idea of
>what to try.
Sor
1 - 100 of 106 matches
Mail list logo
