Obtendo falhas de segmentação de dentro do glib e do gobject - Penso que quero construir / link estaticamente contra uma versão independente do glib2

1

Eu ainda não entendo completamente como os segfaults e backtraces funcionam, mas tenho a impressão de que se a função no topo da lista referenciar "glib" ou "gobject", você tem Bad Issues (TM) com bibliotecas que geralmente não deve dar errado.

Bem, é isso que estou conseguindo aqui, de dois programas completamente diferentes.

A primeira é a versão mais recente do irssi, compilada (de forma limpa, sem falhas ou erros) diretamente do github.com.

Program received signal SIGSEGV, Segmentation fault.
0xb7cf77ea in g_ascii_strcasecmp () from /usr/lib/libglib-2.0.so.0
(gdb) bt
#0  0xb7cf77ea in g_ascii_strcasecmp () from /usr/lib/libglib-2.0.so.0
#1  0x08103455 in config_node_section_index ()
#2  0x081036b0 in config_node_traverse ()
#3  0x080fb674 in settings_get_bool ()
#4  0x08090bce in command_history_init ()
#5  0x08093d81 in fe_common_core_init ()
#6  0x0805a60d in main ()

O segundo programa que estou tendo problemas é o navegador da Web NetSurf (que também compila 100% de forma limpa) quando construído contra o GTK (quando não compilado para usar o GTK, ele roda bem):

Program received signal SIGSEGV, Segmentation fault.
0xb7c1bace in g_type_check_instance_cast () from /usr/lib/libgobject-2.0.so.0
(gdb) bt
#0  0xb7c1bace in g_type_check_instance_cast () from /usr/lib/libgobject-2.0.so.0
#1  0x080cd31c in nsgtk_scaffolding_set_websearch ()
#2  0x080d05da in nsgtk_new_scaffolding ()
#3  0x080dafd8 in gui_create_browser_window ()
#4  0x0809e806 in browser_window_create ()
#5  0x080c2fa9 in ?? ()
#6  0x0807c09d in main ()

Estou 99,99% confiante de que os problemas que estou vendo são algum tipo de falha com o glib2. O resto do meu sistema funciona 100% bem, apenas estes dois programas estão fazendo coisas estranhas. Estou igualmente confiante de que, se eu tentasse criar outros programas que usassem essas bibliotecas, eles provavelmente também falhariam.

Obviamente, cutucar pessoas e amigos - e cometer um pequeno erro - é uma receita instantânea para fazer praticamente todos os programas do sistema catastroficamente partirem horrivelmente (e falo por experiência com outro sistema, há muito tempo atrás: P).
Dado que eu não tenho absolutamente nenhuma idéia do que estou fazendo com esse tipo de coisa e eu sei disso, eu detesto ir para lá; Eu gostaria de manter minha configuração atual do sistema funcional:)

Eu estava pensando em compilar uma versão new de glib2 (e co.), e então vincular estaticamente esses programas a ela. Eu não tenho ideia de como fazer isso - quais etapas eu preciso executar?

Uma idéia alternativa que tive foi a ./configure --prefix=/usr; make; make install exatamente a mesma versão do glib que eu tenho agora "de volta para" meu sistema, para reinstalá-lo. Vejo que as bibliotecas principais associadas terminam com " 0.3200.4 ":

-rwxr-xr-x 1 root root 1.4M Aug  9  2012 /usr/lib/libgio-2.0.so.0.3200.4
-rwxr-xr-x 1 root root 1.2M Aug  9  2012 /usr/lib/libglib-2.0.so.0.3200.4
-rwxr-xr-x 1 root root  11K Aug  9  2012 /usr/lib/libgmodule-2.0.so.0.3200.4
-rwxr-xr-x 1 root root 308K Aug  9  2012 /usr/lib/libgobject-2.0.so.0.3200.4
-rwxr-xr-x 1 root root 3.7K Aug  9  2012 /usr/lib/libgthread-2.0.so.0.3200.4

Isso possivelmente funcionaria, ou quebraria as coisas horrivelmente? : S
Se for possível, qual versão "0.3200.4" é traduzida para?

Que outras ideias posso experimentar?

Eu não estou necessariamente procurando por correções para corrigir o erro que está acontecendo - ele não está me afetando mal isso . Eu só quero que o irssi e o NetSurf sejam executados corretamente.

    
por i336_ 13.11.2014 / 20:49

1 resposta

2

I get the impression that if the function at the top of the list references "glib" or "gobject", you have Bad Issues(TM) with libraries that usually shouldn't go wrong.

Você tem a impressão errada, se você quer dizer que isso indica que a falha provavelmente está nessas bibliotecas. Isso não significa isso; É mais provável que seja aí que um erro anterior finalmente explodiu. Por natureza, C não possui muitas salvaguardas de tempo de execução, então você pode facilmente passar argumentos que compilarão, mas não serão validados (a menos que você faça você mesmo). Exemplo simples:

int main (void) {
    char whoops[3] = { 'a', 'b', 'c' };
    if (strcmp(whoops, "abcdef")) puts(whoops);

Passa uma string não terminada para várias funções de string diferentes. Isso não compilará nenhum problema e provavelmente será executado corretamente porque a memória violação será muito pequena, mas poderia seg falha em strcmp() ou puts() . Isso não significa que a implementação de strcmp() está com bugs; o erro está claramente ali em main() .

Funções como aquelas que não podem logicamente determinar se um argumento passado está apropriadamente terminado (isto é o que eu quis dizer verificações de tempo de execução do WRT e C "por natureza" sem elas). Não há muito sentido em estipular que o compilador deve verificar, porque na maioria das vezes os dados não serão codificados dessa forma.

As coisas no meio de um backtrace não necessariamente desempenham um papel, embora isso possa acontecer. Geralmente, o lugar para começar a procurar é a entrada last ; é aí que o problema foi rastreado para

.

Mas o bug pode estar em qualquer lugar. Muitas vezes, a comparação de um backtrace aos erros relatados por um verificador de memes como valgrind pode ajudar a restringir as coisas. WRT seus exemplos, pode haver muito a peneirar embora; por último eu verifiquei valgrind e gtk não eram companheiros felizes.

I was thinking of compiling a new version of glib2 (and co.), then statically linking these programs against it.

Você poderia, embora eu não veja nenhum motivo para acreditar que algo funcionará melhor por causa disso. Está agarrando palhas. Você não pode realmente depurar o problema sozinho, o que é compreensível, então você considera o que você pode experimentar por desespero.

O mais provável é que você esteja perdendo muito tempo e se frustrando.

I'm 99.99% confident the issues I'm looking at are some kind of glitch-out with glib2.

Tenho 99% de confiança de que você é excessivamente confiante.

Embora novamente o bug possa estar em qualquer lugar, como regra geral, considere as partes mais amplamente testadas os culpados menos prováveis. Neste caso, o glib é bastante onipresente, enquanto o irssi e o NetSurf são relativamente obscuros.

A melhor coisa a fazer é provavelmente enviar um relatório de bug. Backtraces são geralmente muito apreciados lá. Comece com o irssi e o NetSurf; se você for direto para o simplório, eles dirão, razoavelmente, que não há razão para acreditar que é problema deles, a menos que você possa demonstrar (o que tudo isso não faz). Se, por outro lado, o povo irssi determinar que o está em bom estado, provavelmente eles vão querer prosseguir com isso.

    
por 13.11.2014 / 21:29