On Fri, Jul 29, 2005 at 07:21:44PM +0200, Krzysztof Duleba wrote:
> Yitzchak Scott-Thoennes wrote:
>
> >However code like the above does end up using twice the space; it's
> >allocated once to store the result of the x operation and again when
> >it's copied to $a.
>
> Really? I hope you're wrong
Igor Pechtchanski wrote:
However code like the above does end up using twice the space; it's
allocated once to store the result of the x operation and again when
it's copied to $a.
D'oh! I forgot that this was an assignment, not an initialization. I
feel properly chastised. :-)
How come th
On Fri, 29 Jul 2005, Yitzchak Scott-Thoennes wrote:
> On Wed, Jul 27, 2005 at 05:07:23PM -0700, Stephan Mueller wrote:
> > "Igor Pechtchanski wrote:
> > "
> > " On Thu, 28 Jul 2005, Krzysztof Duleba wrote:
> > " > > > I've simplified the test case. It seems that Cygwin perl can't
> > " > > > handl
Yitzchak Scott-Thoennes wrote:
However code like the above does end up using twice the space; it's
allocated once to store the result of the x operation and again when
it's copied to $a.
Really? I hope you're wrong. Avoiding copy operation while declaring a new
variable with a value is a very
On Wed, Jul 27, 2005 at 05:07:23PM -0700, Stephan Mueller wrote:
> "Igor Pechtchanski wrote:
> "
> " On Thu, 28 Jul 2005, Krzysztof Duleba wrote:
> " > > > I've simplified the test case. It seems that Cygwin perl can't
> " > > > handle too much memory. For instance:
> " > > >
> " > > > $ perl -e '$
On Fri, Jul 29, 2005 at 11:45:05AM +0200, Gerrit P. Haase wrote:
>Christopher Faylor wrote:
>
>>On Fri, Jul 29, 2005 at 12:16:42AM +0200, Gerrit P. Haase wrote:
>>
>>>Dave,
>>>
>>>Some comments on your analysis.
>>>
>>>The latest perl uses auto-image-base and the base address should be
>>>differen
On Fri, 29 Jul 2005, Gerrit P. Haase wrote:
> At least we figured that perl crashes when it uses more than 384 MB RAM,
> similar C programs don't crash.
The fact that perl crashes is, IMO, a perl bug, which still needs to be
fixed. Perl shouldn't *crash* (i.e., segfault). It could report an out
Christopher Faylor wrote:
On Fri, Jul 29, 2005 at 12:16:42AM +0200, Gerrit P. Haase wrote:
Dave,
Some comments on your analysis.
The latest perl uses auto-image-base and the base address should be
different than default. It fails anyway.
Perl uses its own malloc, rebuilding with the syst
On Fri, Jul 29, 2005 at 12:16:42AM +0200, Gerrit P. Haase wrote:
>Dave,
>
>Some comments on your analysis.
>
>The latest perl uses auto-image-base and the base address should be
>different than default. It fails anyway.
>
>Perl uses its own malloc, rebuilding with the system malloc shows
>that it
Dave,
Some comments on your analysis.
The latest perl uses auto-image-base and the base address should be
different than default. It fails anyway.
Perl uses its own malloc, rebuilding with the system malloc shows
that it behaves similar than the C examples, I think the recent
changes in Cygw
On Thu, 28 Jul 2005, Dave Korn wrote:
> Original Message
> >From: Igor Pechtchanski
> >Sent: 28 July 2005 14:58
>
> > Hmm, but shouldn't this code fail regardless of the value of
> > heap_chunk_in_mb? Why does increasing heap_chunk_in_mb make this
> > succeed?
>
> Perhaps it only makes
Original Message
>From: Igor Pechtchanski
>Sent: 28 July 2005 14:58
> Hmm, but shouldn't this code fail regardless of the value of
> heap_chunk_in_mb? Why does increasing heap_chunk_in_mb make this succeed?
Perhaps it only makes it succeed if you increase heap_chunk_in_mb until
that
On Thu, 28 Jul 2005, Dave Korn wrote:
> Original Message
> >From: Krzysztof Duleba
> >Sent: 28 July 2005 08:00
>
> > Igor Pechtchanski wrote:
> >> On Thu, 28 Jul 2005, Krzysztof Duleba wrote:
> >>
> >>> I am not. I understand that this is how it should work
> >>> theoretically, but I've _c
Original Message
>From: Krzysztof Duleba
>Sent: 28 July 2005 08:00
> Igor Pechtchanski wrote:
>> On Thu, 28 Jul 2005, Krzysztof Duleba wrote:
>>
>>> I am not. I understand that this is how it should work theoretically,
>>> but I've _checked_ that on a couple of Cygwin boxes with different
Gerrit P. Haase wrote:
Gerrit P. Haase wrote:
Krzysztof Duleba wrote:
Igor Pechtchanski wrote:
Actually, you're right. Perhaps it depends on what kind of malloc the
program uses (i.e., whether it uses the Cygwin builtin malloc, or
something else).
That's strange. How could Perl use so
Gerrit P. Haase wrote:
Krzysztof Duleba wrote:
Igor Pechtchanski wrote:
Actually, you're right. Perhaps it depends on what kind of malloc the
program uses (i.e., whether it uses the Cygwin builtin malloc, or
something else).
That's strange. How could Perl use something essentially differ
Krzysztof Duleba wrote:
Igor Pechtchanski wrote:
Actually, you're right. Perhaps it depends on what kind of malloc the
program uses (i.e., whether it uses the Cygwin builtin malloc, or
something else).
That's strange. How could Perl use something essentially different than
malloc? I thought
Igor Pechtchanski wrote:
On Thu, 28 Jul 2005, Krzysztof Duleba wrote:
I am not. I understand that this is how it should work theoretically,
but I've _checked_ that on a couple of Cygwin boxes with different
versions of cygwin1.dll and gcc. All of them didn't really care that
heap_chunk_in_mb wa
On Thu, 28 Jul 2005, Krzysztof Duleba wrote:
> Igor Pechtchanski wrote:
>
> > > After setting heap_chunk_in_mb to 2048, all those tests passed.
> > > Thanks! But I still don't understand why C isn't bound by
> > > heap_chunk_in_mb and perl is.
> >
> > I think you're confused. All Cygwin programs,
Igor Pechtchanski wrote:
After setting heap_chunk_in_mb to 2048, all those tests passed. Thanks! But I
still don't understand why C isn't bound by heap_chunk_in_mb and perl is.
I think you're confused. All Cygwin programs, including those written in
C, are bound by heap_chunk_in_mb. Unless y
Igor Pechtchanski wrote:
" On Wed, 27 Jul 2005, Stephan Mueller wrote:
" > Igor Pechtchanski wrote:
" >
" > " (I wrote:)
" > " > End result is that the perl internal representation in the
example
" > " > above probably only needs about 200MB of space, and not double
that,
" > " > as suggested.
" >
On Wed, 27 Jul 2005, Stephan Mueller wrote:
> Igor Pechtchanski wrote:
>
> " (I wrote:)
> " > End result is that the perl internal representation in the example
> " > above probably only needs about 200MB of space, and not double that,
> " > as suggested.
> "
> " Umm, that was unclear from the des
Igor Pechtchanski wrote:
" (I wrote:)
" > End result is that the perl internal representation in the example
above
" > probably only needs about 200MB of space, and not double that, as
" > suggested.
"
" Umm, that was unclear from the description on the perlunicode manpage.
" That, combined with P
On Wed, 27 Jul 2005, Stephan Mueller wrote:
> "Igor Pechtchanski wrote:
> "
> " On Thu, 28 Jul 2005, Krzysztof Duleba wrote:
> " > > > I've simplified the test case. It seems that Cygwin perl can't
> " > > > handle too much memory. For instance:
> " > > >
> " > > > $ perl -e '$a="a"x(200 * 1024 *
"Igor Pechtchanski wrote:
"
" On Thu, 28 Jul 2005, Krzysztof Duleba wrote:
" > > > I've simplified the test case. It seems that Cygwin perl can't
" > > > handle too much memory. For instance:
" > > >
" > > > $ perl -e '$a="a"x(200 * 1024 * 1024); sleep 9'
" > > >
" > > > OK, this could have failed
On Thu, Jul 28, 2005 at 12:35:02AM +0200, Krzysztof Duleba wrote:
>Igor Pechtchanski wrote:
>>On Wed, 27 Jul 2005, Krzysztof Duleba wrote:
>
>>>I've simplified the test case. It seems that Cygwin perl can't handle
>>>too much memory. For instance:
>>>
>>>$ perl -e '$a="a"x(200 * 1024 * 1024); sleep
Igor Pechtchanski wrote:
$ cat foo.c
#include
int main(int argc, char * argv[]){
int i;
char * ptrs[1024];
for(i = 0; i < atoi(argv[2]); ++i){
ptrs[i] = malloc(1024 * 1024 * atoi(argv[1]));
memset(ptrs[i], 'a', 1024 * 1024 * atoi(argv[1]));
On Thu, 28 Jul 2005, Krzysztof Duleba wrote:
> Igor Pechtchanski wrote:
> > On Wed, 27 Jul 2005, Krzysztof Duleba wrote:
>
> > > I've simplified the test case. It seems that Cygwin perl can't handle
> > > too much memory. For instance:
> > >
> > > $ perl -e '$a="a"x(200 * 1024 * 1024); sleep 9'
>
Igor Pechtchanski wrote:
On Wed, 27 Jul 2005, Krzysztof Duleba wrote:
I've simplified the test case. It seems that Cygwin perl can't handle
too much memory. For instance:
$ perl -e '$a="a"x(200 * 1024 * 1024); sleep 9'
$ perl -e '$a="a"x(1024 * 1024);my %b; $b{$_}=$a for(1..400);sleep 9'
On Thu, 28 Jul 2005, Krzysztof Duleba wrote:
> Igor Pechtchanski wrote:
>
> > > > > > $ ./inter.pl
> > > > > > perl> sub foo($){$a=shift;foo($a+1);}
> >
> > You do realize you have infinite recursion here, right?
>
> Sure.
>
> > > > > Segmentation fault (core dumped)
> > And this is Windows saying
Igor Pechtchanski wrote:
$ ./inter.pl
perl> sub foo($){$a=shift;foo($a+1);}
You do realize you have infinite recursion here, right?
Sure.
Segmentation fault (core dumped)
And this is Windows saying "I don't think so". :-)
:-)
I don't know. Maybe it is a Windows feature that applicati
Krzysztof Duleba wrote:
But there's plenty of memory left when perl crashes. I have 1 GB RAM and
1 GB swap file.
I've simplified the test case. It seems that Cygwin perl can't handle
too much memory. For instance:
$ perl -e '$a="a"x(200 * 1024 * 1024); sleep 9'
This requires about 525 MB
On Wed, 27 Jul 2005, Krzysztof Duleba wrote:
> Gerrit P. Haase wrote:
>
> > > > $ ./inter.pl
> > > > perl> sub foo($){$a=shift;foo($a+1);}
You do realize you have infinite recursion here, right? So you're most
likely running out of stack (which Perl may be re-allocating on the heap).
> > > > pe
Original Message
>From: Krzysztof Duleba
>Sent: 27 July 2005 17:56
> Then why does the following code fail?
To find out, run /bin/perl.8.6.exe under gdb/insight and breakpoint sbrk.
You'll see that VirtualAlloc is failing. By reassigning $eip to
GetLastError immediately after one of t
Gerrit P. Haase wrote:
$ ./inter.pl
perl> sub foo($){$a=shift;foo($a+1);}
perl> foo 1
Out of memory during request for 4040 bytes, total sbrk() is
402624512 bytes!
Segmentation fault (core dumped)
Another version (with "my $a"):
perl> sub foo($){my $a=shift;foo($a+1);}
perl> foo 1
Out of me
Krzysztof Duleba wrote:
Gerrit P. Haase wrote:
With 5.8.7 I get the core dump after calling `foo 1` the first time:
$ ./inter.pl
perl> sub foo($){$a=shift;foo($a+1);}
perl> foo 1
Out of memory during request for 4040 bytes, total sbrk() is 402624512
bytes!
Segmentation fault (core dumped)
Gerrit P. Haase wrote:
$ ./inter.pl
perl> sub foo($){$a=shift;foo($a+1);}
perl> foo 1
Out of memory during "large" request for 134221824 bytes, total sbrk()
is 273211392 bytes at (eval 18) line 1.
perl> foo 1
Out of memory during request for 67289644 bytes, total sbrk() is
394086400 bytes
!
Krzysztof Duleba wrote:
While playing with perl in interactive mode, I experienced strange
memory error in Cygwin perl. Trying the same scenario on Linux boxes
results in perl being killed after using all memory (tested on machines
with 128 - 2048 MB RAM), but on Cygwin perl dies in a differen
While playing with perl in interactive mode, I experienced strange memory
error in Cygwin perl. Trying the same scenario on Linux boxes results in
perl being killed after using all memory (tested on machines with 128 -
2048 MB RAM), but on Cygwin perl dies in a different way.
The following scr
39 matches
Mail list logo
