On Wed, Oct 27, 2010 at 12:09 PM, Rainer Hurling <rhurlin@gwdg.de> wrote:

> On 27.10.2010 15:07 (UTC+1), Michael Lawrence wrote:
>
>> On Sat, Oct 23, 2010 at 2:49 AM, Rainer Hurling <rhurlin@gwdg.de
>> <mailto:rhurlin@gwdg.de>> wrote:
>>    On 22.10.2010 22:10 (UTC+1), Rainer Hurling wrote:
>>        On 22.10.2010 16:18 (UTC+2), Rainer Hurling wrote:
>>            On 22.10.2010 14:57 (UTC+1), Michael Lawrence wrote:
>>
>>                On Thu, Oct 21, 2010 at 9:42 AM, Rainer Hurling
>>                <rhurlin@gwdg.de <mailto:rhurlin@gwdg.de>
>>                <mailto:rhurlin@gwdg.de <mailto:rhurlin@gwdg.de>>> wrote:
>>
>>                [moved from R-help]
>>
>>                On 21.10.2010 18:09 (UTC+1), Prof Brian Ripley wrote:
>>
>>                If you do R CMD INSTALL --no-test-load this will skip
>>                the part
>>                that is
>>                hanging and you can try loading in stages (e.g. dyn.load
>>                on the
>>                RGtk2.so).
>>
>>                With '--no-test-load' it installs and ends normal.
>>                Loading per
>>                dyn.load("RGtk2.so") works, just as
>>                dyn.load("RGtk2.so",F) and
>>                dyn.load("RGtk2.so",,F). Unloading works, too.
>>
>>                Normal loading over library(RGtk2) within R does not
>>                work. R than is
>>                hanging.
>>
>>                It seems the problem is not with the library itself?
>>
>>                It looks like something is happening when initializing
>>                GTK+ and the
>>                event loop. This happens in the function R_gtkInit in
>>                Rgtk.c. If you
>>                could run R -d gdb and break on that function, perhaps
>>                you could step
>>                through until it hangs.
>>
>>            Michael, thank you for answering. As I wrote earlier (on
>>            R-help@),
>>            unfortunately I have no experience with debugging (I am not a
>>            programmer). So I would need some more assistence.
>>
>>            Is there a difference between 'library(RGtk2)' and
>>            'dyn.load(RGtk2)' in
>>            initializing GTK+? I am able to dyn.load, but library does
>>            not work.
>>
>>            After starting with 'R -d gdb' is the following right?
>>
>>            (gdb) break R_gtkInit
>>            Function "R_gtkInit" not defined.
>>            Make breakpoint pending on future shared library load? (y or
>>            [n]) y
>>            Breakpoint 1 (R_gtkInit) pending.
>>
>>            When I try to proceed, it gives me the following message
>>
>>            (gdb) run
>>            Starting program: /usr/local/lib/R/bin/exec/R
>>            /libexec/ld-elf.so.1: Shared object "libRblas.so" not found,
>>            required by "R"
>>            Program exited with code 01.
>>
>>        Ok, I am one step further now:
>>
>>        (gdb) run
>>        Starting program: /usr/local/lib/R/bin/exec/R
>>        [..SNIP..]
>>         > library(RGtk2)
>>        [New LWP 100174]
>>        Breakpoint 2 at 0x318bd490: file Rgtk.c, line 104.
>>        Pending breakpoint "R_gtkInit" resolved
>>        [New Thread 2f408b00 (LWP 100174)]
>>        [Switching to Thread 2f408b00 (LWP 100174)]
>>
>>        Breakpoint 2, R_gtkInit (rargc=0x30b11d10, rargv=0x30a98458,
>>        success=0x30afbad0) at Rgtk.c:104
>>        104 Rgtk.c: No such file or directory.
>>        in Rgtk.c
>>        (gdb)
>>
>>        What do you suggest I should do next?
>>
>>    Rgtk.c was not found from gdb because RGtk2 was not build with
>>    DEBUG=T and R_KEEP_PKG_SOURCE=yes.
>>
>>    So this is the next try. I can trace the code until it hangs:
>>
>>    library(RGtk2)
>>    [New LWP 100250]
>>    Breakpoint 2 at 0x458bd490: file Rgtk.c, line 104.
>>
>>    Pending breakpoint "R_gtkInit" resolved
>>    [New Thread 4322ef00 (LWP 100250)]
>>    [Switching to Thread 4322ef00 (LWP 100250)]
>>
>>    Breakpoint 2, R_gtkInit (rargc=0x446d0980, rargv=0x44698618,
>>    success=0x446d09e0) at Rgtk.c:104
>>    104     {
>>    (gdb) n
>>    107       argc = (int) *rargc;
>>    (gdb) n
>>    104     {
>>    (gdb) n
>>    107       argc = (int) *rargc;
>>    (gdb) n
>>    109       if (!gdk_display_get_default()) {
>>    (gdb) n
>>    110         gtk_disable_setlocale();
>>    (gdb) n
>>    111         if (!gtk_init_check(&argc, &rargv)) {
>>    (gdb) n
>>    121         if (!GDK_DISPLAY()) {
>>    (gdb) n
>>    127         addInputHandler(R_InputHandlers,
>>    ConnectionNumber(GDK_DISPLAY()),
>>    (gdb) n
>>    132         if (!pipe(fds)) {
>>    (gdb) n
>>    133           ifd = fds[0];
>>    (gdb) n
>>    134           ofd = fds[1];
>>    (gdb) n
>>    135           addInputHandler(R_InputHandlers, ifd,
>>    R_gtk_timerInputHandler, 32);
>>    (gdb) n
>>    133           ifd = fds[0];
>>    (gdb) n
>>    134           ofd = fds[1];
>>    (gdb) n
>>    135           addInputHandler(R_InputHandlers, ifd,
>>    R_gtk_timerInputHandler, 32);
>>    (gdb) n
>>    136           if (!g_thread_supported ()) g_thread_init (NULL);
>>    (gdb) n
>>    137           g_thread_create(R_gtk_timerThreadFunc, NULL, FALSE,
>> NULL);
>>    (gdb) n
>>
>>    Line 138 (R_CStackLimit = -1;) is hanging. It seems there is
>>    something wrong with piping the file descriptor?
>>
>> Thanks for looking into this. It looks like the g_thread_create line is
>> hanging. I wonder if your version of GTK+/GLib is not built with
>> threading support? But if that were the case, g_thread_init() should
>> have aborted. You could try breaking on the R_gtk_timerThreadFunc just
>> to see if the thread is executed at all or where it is hanging.
>>
>
>
> Michael, I have to thank you :-)  I set a break at 'R_gtk_timerThreadFunc'.
> It seems this function does not return:
>
>
> [..see above..]
> library(RGtk2)
> [New LWP 100172]
> Breakpoint 2 at 0x458bd5c0: file Rgtk.c, line 78.
> Pending breakpoint "R_gtk_timerThreadFunc" resolved
> [New Thread 4322ef00 (LWP 100172)]
> [..hanging from here on..]
>
>
> Next I tried a new run with break at 'g_main_context_new' (line 79), which
> steps into glib-2.0.so.0, before it hangs:
>
>
> library(RGtk2)
> [New LWP 100195]
> Breakpoint 2 at 0x47c7c660
> Pending breakpoint "g_main_context_new" resolved
> [New Thread 4322ef00 (LWP 100195)]
> [Switching to Thread 4322ef00 (LWP 100195)]
> Breakpoint 2, 0x0000000047c7c660 in g_main_context_new () from
> /usr/local/lib/libglib-2.0.so.0
> (gdb) n
> Single stepping until exit from function g_main_context_new,
> which has no line number information.
> 0x0000000047c7aed0 in g_source_set_priority () from
> /usr/local/lib/libglib-2.0.so.0
> (gdb) n
> Single stepping until exit from function g_source_set_priority,
> which has no line number information.
> 0x0000000047c7ac70 in g_main_loop_quit () from
> /usr/local/lib/libglib-2.0.so.0
> (gdb) n
> Single stepping until exit from function g_main_loop_quit,
> which has no line number information.
> 0x0000000047c7a280 in g_source_get_context () from
> /usr/local/lib/libglib-2.0.so.0
> (gdb) n
> Single stepping until exit from function g_source_get_context,
> which has no line number information.
> 0x0000000047c7c6f3 in g_main_context_new () from
> /usr/local/lib/libglib-2.0.so.0
> (gdb) p ctx
> No symbol "ctx" in current context.
> (gdb) p data
> No symbol "data" in current context.
> (gdb) n
> Single stepping until exit from function g_main_context_new,
> which has no line number information.
> 0x0000000047c7c8b2 in g_main_context_default () from
> /usr/local/lib/libglib-2.0.so.0
> (gdb) n
> Single stepping until exit from function g_main_context_default,
> which has no line number information.
> 0x0000000047c7dea5 in g_source_attach () from
> /usr/local/lib/libglib-2.0.so.0
> (gdb) n
> Single stepping until exit from function g_source_attach,
> which has no line number information.
> 0x0000000047c79c50 in g_list_remove_link () from
> /usr/local/lib/libglib-2.0.so.0
> (gdb) n
> Single stepping until exit from function g_list_remove_link,
> which has no line number information.
> 0x0000000047c7dde6 in g_source_attach () from
> /usr/local/lib/libglib-2.0.so.0
> (gdb) n
> Single stepping until exit from function g_source_attach,
> which has no line number information.
> 0x0000000047c7ac70 in g_main_loop_quit () from
> /usr/local/lib/libglib-2.0.so.0
> (gdb) n
> Single stepping until exit from function g_main_loop_quit,
> which has no line number information.
> 0x0000000047c7a280 in g_source_get_context () from
> /usr/local/lib/libglib-2.0.so.0
> (gdb) n
> Single stepping until exit from function g_source_get_context,
> which has no line number information.
> 0x0000000047c7de00 in g_source_attach () from
> /usr/local/lib/libglib-2.0.so.0
> (gdb) n
> Single stepping until exit from function g_source_attach,
> which has no line number information.
> 0x0000000047c7a280 in g_source_get_context () from
> /usr/local/lib/libglib-2.0.so.0
> (gdb) n
> Single stepping until exit from function g_source_get_context,
> which has no line number information.
> 0x0000000047c7de11 in g_source_attach () from
> /usr/local/lib/libglib-2.0.so.0
> (gdb) n
> Single stepping until exit from function g_source_attach,
> which has no line number information.
> 0x000000004608eec8 in gdk_add_client_message_filter () from
> /usr/local/lib/libgdk-x11-2.0.so.0
> (gdb) n
> Single stepping until exit from function gdk_add_client_message_filter,
> which has no line number information.
> [..hanging from here on..]
>
>
> Is there an easy way to find out if GTK+/GLib is built with threading
> support?
>
>
The g_thread_init() call should abort the program if there is no threading
support, so I'm assuming it's there. I'm not sure what's wrong here, but
maybe I'll just #ifdef out the threaded event handling for FreeBSD. A new
RGtk2 will be released in the next few days.

Michael


> Thanks, Rainer
>
>
>
>  Thanks again for taking the time to work on this. Sorry I have been
>> non-responsive.
>>
>> Michael
>>
>
> [..mail deleted from here on..]
>

	[[alternative HTML version deleted]]

