You are currently browsing the category archive for the 'Sistemas' category.
As bibliotecas compartilhadas são carregadas no início da execução de um programa. No Linux, o dynamic loader procura pelas bibliotecas em /lib e /usr/lib. Caso a biblioteca não esteja presente neste caminho, recebemos uma mensagem de erro parecida com a mensagem a seguir:
error while loading shared libraries: libfoo.so: cannot open shared object file: No such file or directory
Imagine um ambiente de desenvolvimento, onde estamos codificando uma biblioteca. Não queremos instalar esta biblioteca no sistema só para testá-la. Uma alternativa é configurar a variável de ambiente LD_LIBRARY_PATH, apontando para o diretório onde se encontra o binário da biblioteca. Assim o dynamic loader vai procurar pela biblioteca também neste diretório.
$ export LD_LIBRARY_PATH=/home/user/libfoo/
Uma segunda opção seria no momento em que seu programa é “linkado”, passar o caminho da biblioteca para a opção -rpath do linker. Isto coloca o caminho de busca pela biblioteca dentro da estrutura do executável (ELF). A opção -Wl do gcc serve para passar parâmetros para o linker (usando “,” no lugar de espaço) que é chamado automaticamente após a compilação.
$ gcc -shared -Wall -o libfoo.so foo.c
$ gcc -Wall -o test test.c -L/home/user/libfoo/ -lfoo
$ ./test # Erro! Não acha a biblioteca libfoo.so
$ gcc -Wall -Wl,-rpath,/home/user/libfoo/ -o test test.c \ -L/home/user/libfoo/ -lfoo
$ ./test # Funciona!
No Linux é muito comum um daemon, durante sua execução, criar um arquivo .pid dentro de /var/run. Dentro do arquivo syslogd.pid, por exemplo, contém o PID da instância do syslogd em execução. Usa-se este mecanismo para impedir que duas instâncias do mesmo processo rodem simultaneamente e conflitem na obtenção de recursos.
Porém, a simples existência do arquivo .pid não garante que o processo esteja em execução. Ele pode ter sido fechado de uma forma inesperada e não o apagou. Então, temos que ler o conteúdo do arquivo .pid e certificar que o processo com aquele número de PID está em execução.
A forma mais fácil de fazer isso é enviando o sinal 0 para o processo. O sinal 0 é especial e não é de fato enviado, caso contrário o processo destinatário poderia ser fechado se não tratasse o sinal, mas o retorno da função indica se um sinal real seria enviado com sucesso. O código a seguir exemplifica como aplicar a técnica em C:
int main(int argc, char **argv)
{
unsigned int pid;
if (argc != 2) {
printf("Uso: %s PID\n", argv[0]);
return 1;
}
pid = (unsigned int) atoi(argv[1]);
if (!kill(pid, 0))
printf("%d esta em execucao.\n", pid);
else
printf("%d nao esta em execucao.\n", pid);
return 0;
}
A mesma técnica pode ser aplicada no terminal:
$ kill -0 123 $ echo $? # Imprime 0 se o PID 123 existir, 1 caso contrario
Note que você precisa ter permissão para enviar um sinal para um determinado processo. Para um usuário sem privilégios especiais, a dica só vai funcionar para verificar a existência de processos iniciados pelo próprio usuário.
Se sua pressão aumenta toda vez que vê essa mensage no Visual Studio, é possível desabilitar totalmente essa funcionalidade:
Vá em: C:\Program Files\Microsoft Visual Studio 8\VC\vcpackages ou equivalente na sua máquina e apague (ou renomeie para algo inócuo) o arquivo feacp.dll.
Isto desabilita o Intellisense para C++, mas não para C# (onde ele funciona melhor). Infelizmente isto também desabilita funcionalidades como o auto-complete ou a navegação “inteligente” entre arquivos.
É, pode ser um preço pequeno a pagar pela manutenção de sua sanidade.
(LANG=C; ifconfig eth0|grep "inet addr"|cut -f2 -d:|cut -f1 -d" ")
Para pegar o endereço de uma interface diferente basta colocar o nome dessa interface no lugar de eth0.
É interessante que o comando seja colocado entre parênteses, para não modificar o valor da variável de ambiente LANG da sua sessão de shell atual (que controla o idioma em que os aplicativos são exibidos).
Algumas vezes uma máquina está conectada à internet de forma indireta, através de um proxy ou mesmo um firewall com múltiplos links de internet. Os comandos seguintes permitem descobrir qual IP a máquina está utilizando na internet.
Utilizando o wget:
echo $(wget -qO- http://www.whatismyip.com/automation/n09230945.asp)
Utilizando o lynx (ou o links2):
lynx -dump http://www.whatismyip.com/automation/n09230945.asp
Palavras-chave: Python, command prompt, prompt de comandos, prompt, DOS, Windows
Quando executamos um programa “.py” no Windows uma janela de prompt irá aparecer automaticamente para que as eventuais saídas de texto do seu programa sejam enviadas para lá.
Mas essa janela pode se tornar incoveniente quando o nosso programa já provê uma interface gráfica pois, neste caso, teríamos duas janelas abertas para a mesma aplicação.
A janela aparece porque a extensão “.py” está associada ao interpretador “X:\PythonXX\python.exe” que está configurado para abrir uma janela de prompt.
Caso você precise executar seu programa sem essa janela é melhor usar o interpretador “X:\PythonXX\pythonw.exe” que é feito justamente para esse propósito.
A extensão “.pyw” é associada à esse interpretador, portanto, basta renomear os seus arquivos .py, .pyc e .pyo para .pyw que as janelas de prompt deixarão de aparecer.
Palavras-chave: linux, cache, buffers, limpeza, memória, carregamento, disco, filesystem
O Linux mantém em memória os dados recentemente carregados do disco, e ali eles ficam enquanto possível. Isso acelera o processo de carregamento destes mesmos dados no futuro, como na execução de programas e leitura de arquivos.
As áreas na memória que carregam esses dados chamam-se caches. Você pode notar os caches em ação quando roda um programa pela segunda vez e ele carrega muito mais rapidamente que na primeira.
Mas às vezes é necessário fazer algum teste onde esse efeito de cache deve ser anulado, por exemplo, medir tempo de carregamento de um programa, ou o tempo necessário para processar algum arquivo. Já vi gente reiniciando a máquina só para poder ter uma medição confiável no tempo de carregamento de um programa.
Para economizar nosso tempo e paciência, e ter um efeito semelhante sem precisar reiniciar a máquina, podemos pedir ao kernel que limpe todos os caches que estiverem em memória. Basta usar uma entrada no /proc, existente nas versões mais recentes do kernel, rodando o comando:
echo 1 > /proc/sys/vm/drop_caches
Palavras-chave: OpenGL, Linux, multi-thread, drivers NVidia, crash, segmentation fault, segfault
Se seu programa explode em uma função OpenGL sem nenhum motivo aparente, verifique se a chamada está sendo feita desde a thread onde a OpenGL foi inicializada.
As bibliotecas que vêm com os drivers da NVidia (libGL.so) para X não são muito tolerantes com programas com multi-threading, enquanto a libGL.so da Mesa parece ser mais tolerante a isso. Isso pode levar à confusa situação de o programa rodar sem problemas em alguns sistemas e morrer em outros.
Nos casos em que tive esse problema, o segfault ocorreu na função glViewport(), mas é provável que ocorra com outras funções.
Não existe solucão mágica, mas um workaround — para ao menos testar a hipótese — é mudar o LD_LIBRARY_PATH para apontar ao libGL.so da xorg (se não a tem instalado, tente copiar de outro lugar etc). Verifique se a biblioteca correta está sendo usada com ldd e teste. Já a solucão definitiva é mover as chamadas OpenGL que acessam o mesmo contexto para uma única thread (ou protegê-las com mutexes).







Comentários Recentes