[C con Clase] Presentacion y consulta

[Stack Overflow]

Gracias por tu respuesta Gilberto

El tema creo que viene por otro lado,
Estoy haciendo un servidor que usa epoll. Y cuando quiero esperar por un
evento,
llamo a la funcion epoll_wait
El tema es que, por alguna razon (si alguien me puede aclarar porque),
cuando ejecuto
desde gdb, la funcion termina como si hubiera un error EINTR.
Pero esta es una situacion, al parecer, conocida. Y vi ejemplos donde
especificamente se
pregunta si el error es EINTR, que vuelva a ejecutar la funcion epoll_wait.

Con esto puedo evitar la excepcion dentro de gdb.

Saludos

El 29 de enero de 2011 13:52, Gilberto Cuba Ricardo <
gilberto.cuba en ucp.ho.rimed.cu> escribió:

> Hola,
>
> Stack Overflow escribió:
> > Hola lista,
>
> > Estuve bastante tiempo buscando lista de correo en castellano sobre
> programacion avanzada en C/C++
> > Espero aprender y ayudar en todo lo que pueda.
> > Soy programador C, no tanto C++. Trabajo mas que nada en ambientes
> Unix/Linux
>
> Bienvenido a la lista.
>
> > Tengo una consulta sobre programacion con threads.
>
> No soy experto en el tema, pero sí algo atrevido. ;-)
>
> > El punto es que estoy portando un servidor que funciona en Windows,
> > a Linux. Como todo servidor, usa sockets y threads
> > Cuando lo ejecuto, no funciona como espero. Entonces quiero usar el
> debugger para seguirlo.
> > En Linux usamos gdb.
>
> En Windows también se usa, con el MinGW32.
>
> > La cosa es que cuando ejecuto el programa dentro de gdb, obtengo un
> > SIGSEV en un thread, pero el proceso continua corriendo (otro thread
> continua ejecutando).
>
> > Lo extraño es que si ejecuto el programa fuera del gdb, no se ve
> > ningun mensaje que indique que hubo una excepcion SIGSEV.
> >
> > Si alguien tiene experiencia en este tipo de desarrollos, le
> > agradeceria que me aclare este comportamiento.
>
> Realmente no tengo mucha idea de por qué pudiera ser, pero me ha
> pasado eso mismo en algunas ocasiones. Mi idea al respecto es que en
> el código hay algo que dentro de su funcionamiento no explota
> (SIGSEGV), porque no se accede digamos a una ubicación de memoria
> inválida, pero cuando utilizamos el gdb, este sí trata de barrer todos
> los estados y valores de la variables, y ahí es donde se presenta el
> error que conocemos. Claro, a no ser que estuviéramos en presencia de
> un bug en el gdb.
>
> > Debo confiar en lo que indica el gdb o lo que indica el programa que
> ejecuto sin el debugger ?
>
> Yo confiaría en el gdb, aunque no ciegamente. Como también, si veo que
> se me hace muy difícil debuguearlo con el gdb, porque obtengo el
> SIGSEGV muy rápido antes de atrapar el error en alguna línea/posición
> del programa anterior, pues me dedico entonces a realizar una cacería
> exhaustiva con printf()/std::cout seguido de un flush, para ir
> teniendo idea de por dónde va la cosa.
>
> > Realmente puede haber un SIGSEV en un thread y el programa continua
> ejecutando ?
>
> No sabría que decirte, si el gdb no controlara cómo cerrarlo en este
> tipo de casos (que me parece que sí), me imagino entonces que continue
> su ejecución.
>
> > Bueno, saludos y muchas gracias
> > SO32
>
> --
> Saludos,
>  Gilberto Cuba Ricardo
>
>
> _______________________________________________
> Lista de correo Cconclase Cconclase en listas.conclase.net
> http://listas.conclase.net/mailman/listinfo/cconclase_listas.conclase.net
> Bajas: http://listas.conclase.net/index.php?gid=2&mnu=FAQ
>
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://listas.conclase.net/pipermail/cconclase_listas.conclase.net/attachments/20110129/6048acb5/attachment.html>