[erlang-questions] Recursive Heap Allocation

[CGS]

Hi,

I managed to reproduce the error and the problem is coming from io:format/2
(I suppose writing is too slow for the loop itself, so, the io buffer gets
overflowed). Try this replacing ipv4_addrs:next/1 with this:

test(done) -> done;
test(Addr) -> test(next(Addrs)).

CGS




On Mon, Jul 23, 2012 at 11:50 PM, Greg Martin <greg@REDACTED> wrote:

>  I think you're misunderstanding. It's like a 256 based number scheme.
> 0.255
> is followed by 1.0 not 1.255.
>
> -----Original Message-----
> From: Ronny Meeus [mailto:ronny.meeus@REDACTED]
> Sent: Monday, July 23, 2012 2:00 PM
> To: Bob Ippolito
> Cc: Greg Martin; erlang-questions@REDACTED
> Subject: Re: [erlang-questions] Recursive Heap Allocation
>
> Hello
>
> I think there is an issue in the logic of your code:
>
> next( { First, Second, Third, 255 } ) -> { First, Second, Third + 1, 0 };
> next( { First, Second, Third, Fourth } ) -> { First, Second, Third, Fourth
> +
> 1 }.
>
> If nothing matches, the last clause will do and the last number will be
> incremented until 255 is reached.
> If I understand you well, I would think that the looping continues with the
> last but 1 clause but here is the problem: you pass 0 instead of 255 so
> there is no match and you end up in the last clause again.
> Result is an endless loop.
>
> I think the code should be corrected like this:
> next( { First, Second, Third, 255 } ) -> { First, Second, Third + 1, 255 };
> next( { First, Second, Third, Fourth } ) -> { First, Second, Third, Fourth
> +
> 1 }.
>
> ---
> Best regards,
> Ronny
>
> On Mon, Jul 23, 2012 at 10:04 PM, Bob Ippolito <bob@REDACTED> wrote:
> > You're probably generating output too fast, there's no flow control in
> > io:format/2. You can generate things to print much faster than they
> > get printed, which results in the io server accumulating so many
> > messages in its mailbox that you eventually run out of memory and/or
> > the machine grinds to a halt due to swapping.
> >
> >
> > On Mon, Jul 23, 2012 at 12:50 PM, Greg Martin <greg@REDACTED>
> wrote:
> >>
> >> I'm just learning erlang using Erlang R15B01 (erts-5.9.1) on Windows.
> >> I'm wondering why ipv4_addrs:test(ipv4_addrs:first()) leads to the
> >> crash below and how it can be called so that it doesn't. Thanks.
> >>
> >> {1,2,22,127}
> >> {1,2,22,128}
> >> {1,2,22,129}
> >> {1,2,22,130}
> >> {1,2,22,131}
> >> {1,2,22,132}
> >> {1,2,22,133}
> >> {1,2,22,134}
> >>
> >> Crash dump was written to: erl_crash.dump
> >> eheap_alloc: Cannot allocate 373662860 bytes of memory (of type "heap").
> >>
> >>
> >> Abnormal termination
> >>
> >>
> >> -module(ipv4_addrs).
> >>
> >> -export([first/0, next/1, test/1]).
> >>
> >> first()->
> >>         { 1,1,0,0 }.
> >>
> >> next( { 255, 255, 255, 255 } ) -> done; next( { 9, 255, 255, 255 } )
> >> -> { 11, 0, 0, 0 }; next( { 172, 15, 255, 255 } ) -> { 172, 32, 0, 0
> >> }; next( { 192, 167, 255, 255 } ) -> { 192, 169, 0, 0 }; next( {
> >> First, 255, 255, 255 } ) -> { First + 1, 0, 0, 0 }; next( { First,
> >> Second, 255, 255 } ) -> { First, Second + 1, 0, 0 }; next( { First,
> >> Second, Third, 255 } ) -> { First, Second, Third + 1, 0 }; next( {
> >> First, Second, Third, Fourth } ) -> { First, Second, Third, Fourth
> >> +
> >> 1 }.
> >>
> >> test(done) -> done;
> >> test(Addr) ->
> >>         io:format("~p~n", [Addr]),
> >>         Next = next(Addr),
> >>         test(Next).
> >>
> >> _______________________________________________
> >> erlang-questions mailing list
> >> erlang-questions@REDACTED
> >> http://erlang.org/mailman/listinfo/erlang-questions
> >
> >
> >
> > _______________________________________________
> > erlang-questions mailing list
> > erlang-questions@REDACTED
> > http://erlang.org/mailman/listinfo/erlang-questions
> >
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20120724/80e453fb/attachment.htm>