Seu malloc devolve algum NULL?
Não. Estou usando a função mallocSafe pra alocar memória. Ela contém o código:
if (ptr == NULL) {
fprintf (stderr, "Socorro! malloc devolveu NULL!\n");
exit (EXIT_FAILURE_MALLOC);
}
Quando tenho o problema da pintura de região grande o erro que recebo é:
Falha de segmentação (imagem do núcleo gravada)
Estou usando o Ubuntu 12.04 em pt_br
Claynon, veja a mensagem abaixo do prof. Hitoshi. Em especiel, veja no FAQ do EP2 "a fórmula para modificar o CodeBlocks no Windows para permitir gerar um executável que aceita um maior número de chamadas recursivas"
Para corrigir esse problema, sugerimos a migração para Linux
Mas colocamos um novo executável para Windows que deve rodar para o arquivo de entrada do enunciado.
Colocamos no FAQ do EP2 a fórmula para modificar o CodeBlocks no Windows para permitir gerar um executável que aceita um maior número de chamadas recursivas.
e boa diversão!
Hitoshi
Eu não estou usando codeblocks nem windows.
Estou usando Ubuntu 12.04, emacs e rodando no prompt com "-ansi -Wall -pedantic arq.c -o arq"
Se a região for realmente grande então a quantidade de recursões realmente gera erro de segmentacão, mesmo no Linux. No meu computador, por exemplo, o executável de teste do EP2 para Linux dá erro para regiões a partir de 365x365. Minha implementacão quebra um pouco antes, então depende de como você está fazendo a parte recursiva.
Oi Claynon,
Estou usando Ubuntu 12.04, emacs e rodando no prompt com "-ansi -Wall -pedantic arq.c -o arq"
Em geral, compile com "-ansi -Wall -pedantic -O2 -Wno-unused-result".
Complementando o que o Herique escreveu. No prompt do linux escreva
meu_prompt> ulimit -a
Isto deve mostrar vários limites do seu sistema. No meu caso mostra:
core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-i) 26052 max locked memory (kbytes, -l) 64 max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) 8192 <<<<<<<<<<<<<< cpu time (seconds, -t) unlimited max user processes (-u) 26052 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited
Veja que o meu stack size é 8192 kbytes. Para alterar esse valor você
pode-se escrever
meu_prompt> ulimit -s 16000
Depois disto veja o resultado de ulimit -a
meu_prompt>ulimit -a core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-i) 26052 max locked memory (kbytes, -l) 64 max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) 16000 <<<<<<<<<<<<<<<<< cpu time (seconds, -t) unlimited max user processes (-u) 26052 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited
Para alterar o stack size você tambem pode proceder como está descrito no FAQ
e compilar com a opção -Wl,--stack,16384000, aproximadamente 16MB.
Por favor, teste estas opções e escreva aqui sobre o que você descobrir.
Esse é o problema mesmo.
Meu stack size padrão também era de 8192kB e estava conseguindo pintar regiões de até 300x295 pixels. Aumentando para 16000kB consegui pintar regiões maiores, passando de 400x400
Fiz alguns testes e percebi que com o stacksize de 8192kB eu consigo pintar apenas regiões menores que 87900 pixels (por exemplo pintando uma região de 102x881 que tem 87900 pixels porque duas colunas e duas linhas da região são pintadas de cor de borda e não na cor da região ((102 - 2) * (881 - 2) =100 * 879 = 87900).
Não tenho ideia do porquê 87900 pixels com stack size de 8192kB, alguém sabe?
Eu não saberia dar uma fórmula exata de como calcular isso. Mas a quantidade de pixels que seu programa consegue segmentar depende também da forma como você implementou a recursão (quantas chamadas você faz por nível, como elas são feitas, etc.).
Basicamente, para cada nova chamada recursiva, o C tem que guardar um novo elemento na pilha (stack) com todas as informações necessárias para que ele possa continuar a ser executada mais tarde (quando ele voltar ao topo da pilha). Assim, depende de quanta memória é gasta para cada novo elemento na pilha. Por isso também depende da sua implementação, caso ela empilhe muitas chamadas e só comece a liberar tudo no final, ela vai conseguir segmentar áreas menores do uma implementação capaz de liberar mais rapidamente espaço na pilha.
Entendi. Obrigado.
Re: Erro em pinturas de regioes grandes
Eu fiz o que dizia no FAQ, mas meu programa continuou não funcionando para as imagens maiores.
Re: Erro em pinturas de regioes grandes
Oi Ana,
assumindo que o seu programa funciona para imagens pequenas, como definida no arquivo entrada1.txt, você conseguiu identificar onde e quando o programa para? Se for um problema da pilha, tente aumentar o tamanho do valor stack=8000000 para algo maior.
ht