Re: strange behavior of Glib.Io.read_chars ?

Pierre Letouzey <[email protected]> Mon, 12 Nov 2012 20:01:24 +0100 (CET)
Newsgroups gmane.comp.lang.ocaml.lib.gtk
Message-ID <[email protected]>

----- Mail original -----
> Hi,
> 
> It works here, latest lablgtk2 and glib2 2.32. I've never used these
> functions so I can't be very specific.
> 
> Could you try running the application inside GDB, wait for it to
> block
> and then get a backtrace?
> You could do the following:
>   ./your_app
>   <wait for it to become stuck>
>   gdb ./your_app $(pidof your_app)
>   <wait for gdb to finish loading>
>   bt
> 
> This will show where the process is stuck. If you have no debug
> symbol
> it won't be very precise but it'll show which library it is stuck in
> and it'll be a first step.
> 
> You could also try to reproduce the problem directly in C.
> 

Hi
Thanks for the answer. If this issue is fixed on more recent versions
that's fine, I'm planning anyway to upgrade my debian in a few weeks.
Just in case someone wants to investigate more, here's the asked backtrace
(after installing package libglib2.0-0-dbg :-)

(gdb) bt
#0  0x00007fda7bf96870 in read () from /lib/libc.so.6
#1  0x00007fda7c4b9ca2 in g_io_unix_read (channel=0x26ca910, buf=0x27f4340 "", count=1024, bytes_read=0x7fff1f1ad308, err=0x7fff1f1ad390)
    at /scratch/build-area/glib2.0-2.24.2/glib/giounix.c:189
#2  0x00007fda7c46d33c in g_io_channel_fill_buffer (channel=0x26ca910, err=0x7fff1f1ad390) at /scratch/build-area/glib2.0-2.24.2/glib/giochannel.c:1496
#3  0x00007fda7c46da76 in IA__g_io_channel_read_chars (channel=0x26ca910, buf=0x7fda7ed738c8 ' ' <repeats 200 times>..., count=1000, 
    bytes_read=0x7fff1f1ad398, error=0x7fff1f1ad390) at /scratch/build-area/glib2.0-2.24.2/glib/giochannel.c:2045
#4  0x0000000000524c1c in ml_g_io_channel_read_chars ()
#5  0x000000000054ae7c in caml_c_call ()
#6  0x00007fda7ed729f0 in ?? ()
#7  0x00007fda7ed72a60 in ?? ()
#8  0x0000000000000000 in ?? ()

So it seems indeed that the program is stuck in a blocking read, for whatever reason...
Well, let's say for now that Glib.Io.read is the winner ;-)

Best regards,
Pierre