Escreva um programa que seja executado para sempre e aloque mais e mais memória no heap quanto mais tempo ele for executado, pelo menos até atingir o limite do sistema operacional na quantidade de memória que pode ser alocada.

Muitos kernels, na verdade, não reservam a memória que você aloca até que você a use para alguma coisa; portanto, se o seu programa estiver em C ou em algum outro idioma de baixo nível, você precisará escrever algo em cada página. Se você estiver usando uma linguagem interpretada, provavelmente não precisará se preocupar com isso.

O menor código vence.

Funge-98 ( cfunge), 1 byte

9

Eu teria postado isso antes, mas decidi testá-lo e demorou um pouco para que meu computador voltasse a um estado utilizável. cfungearmazena a pilha do Funge na pilha do sistema operacional (que é facilmente verificável executando o programa com um pequeno limite de memória, algo que eu deveria ter feito antes!), portanto, uma pilha que cresce infinitamente (como neste programa, que apenas empurra 9repetidamente; Os programas Funge agrupados desde o final de uma linha até o início, por padrão) alocam a memória para sempre. Esse programa provavelmente também funciona em algumas implementações do Befunge-93.

Mais interessante:

"NULL #(4

Essa foi minha primeira ideia e é uma alocação infinita que não depende da pilha Funge (embora ela também exploda a pilha Funge). Para começar, o "comando envia uma cópia do restante do programa para a pilha (é uma string e o programa se enrola, de modo que a cotação próxima também serve como cotação aberta). Em seguida, o Nreflete (não tem significado por padrão), fazendo com que o programa seja executado para trás. Ele "é executado novamente e empurra o programa para a pilha - ao contrário, desta vez, com a Nparte superior da pilha -, em seguida, o programa gira, carregando uma biblioteca com um nome de quatro letras ( 4(; a NULLbiblioteca faz parte de cfungebiblioteca padrão). NULLdefine todas as letras maiúsculas para refletir, de modo que Lreflete, o#pula a carga da biblioteca no caminho de volta, 4empurra o lixo que não nos interessa para a pilha e todo o programa se repete desde o início. Dado que o carregamento de uma biblioteca várias vezes tem efeito e requer que a lista de comandos da biblioteca seja armazenada uma vez para cada cópia da biblioteca (isso é implícito na semântica do Funge-98), ele vaza memória através do armazenamento sem pilha (que é um método alternativo de definição de "heap", relativo ao idioma e não ao SO).

Brainfuck, 5 bytes

+[>+]

Isso requer um intérprete que não tenha limite no comprimento da fita.

Bash + coreutils, 5

ou

Ruby, 5

`yes`

yesproduz uma saída sem fim. Colocar yesbackticks diz ao shell para capturar toda a saída e depois executar essa saída como um comando. O Bash continuará alocando memória para essa sequência interminável até que o heap se esgote. É claro que a saída resultante acabaria sendo um comando inválido, mas devemos ficar sem memória antes que isso aconteça.

Obrigado a @GB por apontar que também é um poliglota em rubi.

Python, 16 bytes

Mantém o aninhamento aaté que seja atingido um erro:

a=0
while 1:a=a,

As primeiras iterações (como tuplas) são assim:

0
(0,)
((0,),)
(((0,),),)

e assim por diante.

> <> (Peixe), 1 byte

0

Experimente aqui!

0 pode realmente ser substituído por qualquer número hexadecimal 1-f.

Explicação

0in> <> simplesmente cria um codebox 1x1 para o peixe nadar. Ele constantemente adiciona um 0na pilha, nada direito, o que volta ao redor 0, adicionando-o novamente à pilha. Isso continuará para sempre.

Java 101 bytes

class A{public void finalize(){new A();new A();}public static void main(String[]a){for(new A();;);}}

Captura do programa principal em um loop sem fim após criar e jogar fora um objeto. A coleta de lixo faz o trabalho de vazar criando 2 objetos para cada um excluído

Perl, 12 bytes

{$"x=9;redo}

Em perl, o xoperador, com uma sequência à esquerda e um número à direita, produz uma sequência repetida. Então "abc" x 3avalia como "abcabcabc".

O x=operador modifica o argumento esquerdo, substituindo o conteúdo da variável à esquerda pelo resultado de repetir o conteúdo tantas vezes quanto o lado direito indicar.

O Perl possui várias variáveis ​​incorporadas de nome estranho, uma das quais é $", cujo valor inicial é um espaço único.

O redooperador pula para o início do gabinete {}.

A primeira vez que o x=operador é feito, ele muda o valor de $"partir " ""para " ", que é de 9 espaços.

Na segunda vez em que o x=operador é concluído, ele altera o valor de $"para " ", que é 81 espaços.

Na terceira vez, $"torna-se uma série de espaços de 729 bytes.

Acho que você pode ver onde isso está indo :).

sed, 5 bytes

Golfe

H;G;D

Uso (qualquer entrada serve)

sed 'H;G;D' <<<""

Explicado

#Append a newline to the contents of the hold space, 
#and then append the contents of the pattern space to that of the hold space.
H

#Append a newline to the contents of the pattern space, 
#and then append the contents of the hold space to that of the pattern space. 
G

#Delete text in the pattern space up to the first newline, 
#and restart cycle with the resultant pattern space.
D

Captura de tela

Experimente Online!

Haskell, 23 19 bytes

main=print$sum[0..]

Imprimir a soma de uma lista infinita

C ++ (usando o compilador g ++), 27 23 15 bytes

Agradeço ao Neop por me ajudar a remover 4 bytes

Essa solução realmente não vaza nenhuma memória porque aloca tudo na pilha e, portanto, causa um estouro de pilha. É simplesmente infinitamente recursivo. Cada recursão faz com que alguma memória seja alocada até a pilha estourar.

main(){main();}

Solução alternativa

Esta solução realmente vaza memória.

main(){for(;;new int);}

Saída Valgrind

Esta é a saída do Valgrind após o término do programa por vários segundos no tempo de execução. Você pode ver que certamente está vazando memória.

==2582== LEAK SUMMARY:
==2582==    definitely lost: 15,104,008 bytes in 3,776,002 blocks
==2582==    indirectly lost: 0 bytes in 0 blocks
==2582==      possibly lost: 16 bytes in 4 blocks
==2582==    still reachable: 4 bytes in 1 blocks
==2582==         suppressed: 0 bytes in 0 blocks

JAVA, 81 79 78 bytes

JAVA (HotSpot) 71 70 bytes

Mais curtas do que as outras respostas Java no momento em que publiquei (81, depois 79 bytes):

class A{public static void main(String[]a){String x="1";for(;;)x+=x.intern();}}

Conforme sugerido por @Olivier Grégoire, um outro byte pode ser salvo:

class A{public static void main(String[]a){for(String x="1";;)x+=x.intern();}}

A colocação x+=x.intern()como o incremento do loop for não ajudaria em nada, porque ainda é necessário um ponto-e-vírgula para finalizar a instrução for.

Conforme sugerido por @ETHproductions, apenas o uso de x+=xobras também:

class A{public static void main(String[]a){String x="1";for(;;)x+=x;}}

O que também pode se beneficiar da dica de @Olivier Grégoire:

class A{public static void main(String[]a){for(String x="1";;)x+=x;}}

Minhas únicas dúvidas sobre isso é que não é garantido alocar dados no heap , pois uma JVM eficiente pode facilmente perceber que xnunca escapa à função local. O uso intern()evita essa preocupação, porque as seqüências internas acabam sendo armazenadas em um campo estático. No entanto, o HotSpot gera um OutOfMemoryErrorcódigo para esse código, então acho que está tudo bem.

Atualização: @Olivier Gregoire também apontou que o x+=xcódigo pode ser executado em StringIndexOutOfBoundsExceptionvez de OOMquando há muita memória disponível. Isso ocorre porque o Java usa o inttipo de 32 bits para indexar matrizes (e Strings são apenas matrizes de char). Isso não afeta a x+=x.intern()solução, pois a memória necessária para o último é quadrática no comprimento da string e, portanto, deve ser dimensionada na ordem de 2 ^ 62 bytes alocados.

Perl 6 , 13 bytes

@= eager 0..*

Explicação:

@ = armazena o resultado em uma matriz sem nome

eager faça a seguinte lista ansiosa

0 .. * faixa infinita começando em zero

///, 7 bytes

/a/aa/a

Substitua constantemente apor aaad nauseum.

Python 3, 16 bytes

i=9
while 1:i*=i

Isso vem do fato de que não há limite para o tamanho inteiro no Python 3; em vez disso, os números inteiros podem ocupar a quantidade de memória que o sistema pode suportar (se algo sobre minha compreensão disso estiver errado, me corrija).

Ferrugem, 46 bytes

fn main(){loop{std::mem::forget(Box::new(1))}}

Percebe algo interessante sobre esse programa Rust, vazando alocações de heap até ficar sem memória?

É isso mesmo, nenhum bloqueio inseguro. O Rust garante a segurança da memória em código seguro (sem leitura de dados não inicializados, leitura após liberação, liberação dupla etc.), mas os vazamentos de memória são considerados perfeitamente seguros. Existe até uma função explícita para fazer o compilador esquecer a limpeza RAII de variáveis ​​fora do escopo, que eu uso aqui.

Conjunto hexagonal TI-83, 7 bytes

PROGRAM:M
:AsmPrgm
:EF6A4E
:C3959D
:C9

Cria appvars indefinidamente até que um ERR:MEMORYseja lançado pelo sistema operacional. Corra com Asm(prgmM). Eu conto cada par de dígitos hexadecimais como um byte.

Python, 8 bytes

2**9**99

O OP permitiu a tecnicidade de um programa que tecnicamente não é executado "para sempre", mas aloca mais memória do que qualquer computador poderia suportar. Este não é um googolplex (ou seja 10**10**100, 11 bytes), mas ingenuamente, a base de log 2 do número é

>>> 9**99.
2.9512665430652752e+94

ou seja, 10 ^ 94 bits para representá-lo. WolframAlpha coloca isso como 10 ^ 76 maior que a deep web (lembre-se de que existem 10 ^ 80 átomos no universo ).

Por que 2 em vez de 9 você pergunta? Não faz muita diferença (usar 9 aumentaria apenas o número de bits por um fator de log2(9) = 3.2, o que nem altera o expoente). Mas, por outro lado, o programa roda muito mais rápido com 2, pois o cálculo é mais simples. Isso significa que ele preenche a memória imediatamente, ao contrário da versão 9, que demora um pouco mais devido aos cálculos necessários. Não é necessário, mas é bom se você quiser "testar" isso (o que eu fiz).

Geléia , 3 2 bytes

-1 byte graças a Dennis ( Wenvoltórios)

Wß

Um link (ou seja, função ou método), que também funciona como um programa completo, que recursivamente agrupa sua entrada em uma lista.

A entrada começa como zero, então a primeira passagem cria a lista. [0]
A segunda passagem faz isso. [[0]]
A terceira passagem faz isso [[[0]]]
e assim por diante ...

3 byter anterior, que vaza muito mais rápido:

;Ẇß

concatena recursivamente todas as sublistas contíguas não vazias de sua entrada para sua entrada.
[0]-> [0,[0]]-> [0,[0],[0],[[0]],[0,[0]]]e assim por diante ...

Java 7, 106 bytes

class A{public void finalize(){for(;;)Thread.yield();}public static void main(String[]a){for(;;)new A();}}

Menos Golfe

class A{
    @Override
    public void finalize(){
        for(;;) {
            Thread.yield();
        }
    }
    public static void main(String[]a){
        for(;;){
            new A();
        }
    }
}

O finalizemétodo é chamado em um objeto pelo coletor de lixo quando a coleta de lixo determina que não há mais referências ao objeto. Eu simplesmente redefinii esse método para fazer um loop para sempre, para que o coletor de lixo nunca libere a memória. No mainloop, crio novos objetos que nunca serão limpos e, eventualmente, isso consumirá toda a memória disponível.

Java 7 (alternativa divertida), 216 bytes

import sun.misc.*;class A{public static void main(String[]a)throws Exception{java.lang.reflect.Field f=Unsafe.class.getDeclaredField("theUnsafe");f.setAccessible(1>0);for(;;)((Unsafe)f.get(null)).allocateMemory(9);}}

Menos Golfe

import sun.misc.*;
class A{
    public static void main(String[]a)throws Exception{
        java.lang.reflect.Field f=Unsafe.class.getDeclaredField("theUnsafe");
        f.setAccessible(true);
        Unsafe u = (Unsafe)f.get(null);
        for(;;) {
            u.allocateMemory(9);
        }
    }
}

Este é mais divertido do que qualquer outra coisa. Esta resposta faz uso da Unsafebiblioteca Sun, que é uma API interna não documentada. Pode ser necessário alterar as configurações do compilador para permitir APIs restritas. Unsafe.allocateMemoryaloca uma quantidade especificada de bytes (sem nenhuma verificação de limite) que não está no heap e não está sob o gerenciamento de coletor de lixo do java, portanto, essa memória permanecerá até você chamar Unsafe.freeMemoryou até que a jvm fique sem memória.

Haskell, 24 bytes

f x=f$x*x
main=pure$!f 9

O principal problema em Haskell é vencer a preguiça. mainprecisa ter algum IOtipo, então simplesmente chamar main=f 9não funcionaria. Usar main=pure(f 9)eleva o tipo de f 9para um IOtipo. No entanto, o uso de construções como main=pure 9não faz nada, 9é retornado ou exibido em lugar nenhum, mas simplesmente descartado; portanto, não há necessidade de avaliar o argumento de pure, portanto main=pure(f 9), não faz com que nenhuma memória seja alocada como fnão é chamada. Para impor a avaliação, o $!operador existe. Simplesmente aplica uma função a um argumento, mas avalia o argumento primeiro. Portanto, usar main=pure$!f 9avalia fe, portanto, aloca continuamente mais memória.

dc, 7 bytes

[ddx]dx

[ddx]envia uma string contendo "ddx" para a pilha. dxduplica e depois executa como código (deixando uma cópia na pilha). Quando executado, ele faz duas duplicatas e depois executa uma, deixando mais uma cópia na pilha de cada vez.

Haskell (usando o ghc 8.0.1), 11 bytes

m@main=m>>m

Recursão não-cauda. mainchama a si mesmo e depois a si próprio novamente.

C (linux), 23 bytes

main(){while(sbrk(9));}

sbrk()incrementa a parte superior do segmento de dados pelo número especificado de bytes, aumentando efetivamente a quantidade de memória alocada para o programa - pelo menos conforme relatado no VIRTcampo de topsaída. Isso funciona apenas no Linux - a implementação do macOS é aparentemente uma emulação que só permite alocação de até 4 MB.

Portanto, uma resposta um pouco mais geral:

C, 25 bytes

main(){while(malloc(9));}

Eu assisti no macOS Activity Monitor. Foi até cerca de 48 GB e, eventualmente, o processo recebeu um sinal SIGKILL. FWIW meu macbook pro tem 16GB. A maior parte da memória usada foi relatada como compactada.

Observe que a pergunta exige efetivamente que cada alocação seja gravada, o que não acontece explicitamente aqui. No entanto, é importante observar que, para cada malloc(9)chamada, não são apenas os 9 bytes solicitados pelo usuário que estão alocados. Para cada bloco alocado, haverá um cabeçalho de malloc que também é alocado de algum lugar no heap, o qual é necessariamente gravado pelos malloc()internos.

Perl, 4 bytes

do$0

Executa-se, no intérprete atual. Quando concluída, a execução retorna ao script de chamada, que requer uma pilha de chamadas.

Raquete, 13 bytes

(let l()(l)1)

Não tenho certeza se minha resposta se enquadra nessa pergunta. Informe-me se devo remover esta resposta.

JavaScript 22 21 17 16 15 bytes

for(a=0;;)a=[a]

Economizou 4 bytes envolvendo a lista em outra lista, como na resposta Jelly de @Jonathan Allan.

Guardado 1 byte graças a @ETHProductions

Solução alternativa 15 bytes (funciona apenas com chamadas de cauda adequadas)

f=a=>f([a]);f()

Ruby, 11 bytes

loop{$*<<9}

Mantém empurrando 9para $*, que é uma matriz inicialmente segurando os argumentos de linha de comando para o processo de rubi.

05AB1E , 2 bytes

[A

Experimente online! Apenas continuará empurrando abcdefghijklmnopqrstuvwyxzpara a pilha por toda a eternidade.

Todas as soluções possíveis de 2 bytes:

[  # Infinite loop.
 A # Push alphabet.
 0 # Push 0.
 1 # Push 1.
 2 # Push 2.
 3 # Push 3.
 4 # Push 4.
 5 # Push 5.
 6 # Push 6.
 7 # Push 7.
 8 # Push 8.
 9 # Push 9.
 T # Push 10.
 X # Push 1.
 Y # Push 2.
 ® # Push -1.
 ¶ # Push \n.
 º # Push len(stack) > 0, so 0 once then 1 for eternity.
 ð # Push a space.
 õ # Push an empty string.
 ¾ # Push 0.
 ¯ # Push [].
 M # Push -inf.
 ) # Wrap current stack in an array.

Python, 35 bytes

def f(a=[]):a.append(a)
while 1:f()

a nunca é liberado e fica maior até você atingir um MemoryError

Você pode ver a execução no Python Tutor .

TI-BASIC, 8

:Lbl A
:While 1
:Goto A

(todos os tokens de 1 byte e duas novas linhas)

Isso vaza memória continuamente porque o fluxo de controle estruturado, como o Whilefechamento antecipado por um Ende empurra algo na pilha (não a pilha do SO, uma pilha separada na memória de pilha) para acompanhar isso. Mas aqui estamos usando Gotopara deixar o loop (para que não Endseja executado para remover a coisa da pilha), ela Whileé vista novamente, a coisa é empurrada novamente, etc. Portanto, ela continua pressionando-a até vocêERR:MEMORY