Re: Segmentation fault in gtk2-perl-application

[Ross McFarland <rwmcfa1 neces com>]

On Wed, 2005-03-30 at 16:59, Stephan Brunner wrote:
> Hello everybody,
>
> first of all, let me say "thank you!" for the great perl-bindings to gtk2. I 
> very much enjoy using them and I'm happy with the progress I made with my 
> first gtk2-perl application.
>
> Unfortunately, I run into a segmentation fault at a specific point in my 
> application. There is a menu-action that calls a certain subroutine; the 
> segfault happens right after this sub has returned, so the application should 
> normally just sit in the main loop and wait for signals.
> The subroutine (called "loadDir") asks the user for a directory 
> (Gtk2::FileChooserDialog), reads that directory and fills a tree and a list 
> based on the contents of that directory (calling a bunch of other subs to 
> perform those tasks). Sometimes, "loadDir" executes and everything is fine -  
> but sometimes, the application segfaults after "loadDir" returned. For some 
> directories, the segfault never happens.
>
> According to muppets advice in 
> http://mail.gnome.org/archives/gtk-perl-list/2003-July/msg00028.html, I built 
> glib and gtk2 with the debugging flag and I'm now able to produce core dumps, 
> but I'm not a C programmer and therefore really don't know what to do with 
> them...
>
> Is it at all possible that a bug in my own perl code (pure perl, nothing fancy 
> at all) causes a segfault? Or am I just unhappy hitting a bug in the 
> libraries?

there should never be a seg-fault from pretty much anything you do with
gtk+/gtk2-perl. that being said it's possible that you've encountered
one caused by either gtk+ or gtk2-perl or some combination thereof. 

> Of course, I do much more trust the libraries than I trust my own code, but 
> I'm only used to *dying* perl scripts (with file, line no. and error 
> message); I never encountered a *segfault* with any perl script!?

you could be doing something wrong, but it shouldn't be causing a
segfault regardless

> I would be very glad if you could help me out with this issue by giving advice 
> on where and how to start investigating what's going (wr)on(g) in my 
> application. Of course, I am happy to provide you any information needed; not 
> knowing what information might help, I only attached the output of gdb for a 
> "bt" command.

that's the first step.

> This is gdb's output when I run "gdb perl core" after a segfault and enter 
> "bt" at the prompt:
>
> (gdb) bt
> #0  0x40769d9c in gtk_path_bar_get_type () from /usr/lib/libgtk-x11-2.0.so.0
> #1  0x402d6ddc in g_main_context_wakeup () from /usr/lib/libglib-2.0.so.0
> #2  0x402d46c2 in g_main_depth () from /usr/lib/libglib-2.0.so.0
> #3  0x402d5748 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
> #4  0x402d5a80 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
> #5  0x402d6023 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
> #6  0x406ca796 in gtk_dialog_run () from /usr/lib/libgtk-x11-2.0.so.0
> #7  0x40437b32 in XS_Gtk2__Dialog_run (my_perl=0x814c008, cv=0x82b4ce4) at 
> GtkDialog.xs:330
> #8  0x080c32d6 in Perl_pp_entersub ()
> #9  0x080bbdc9 in Perl_runops_standard ()
> #10 0x080640c9 in Perl_call_sv ()
> #11 0x08063ec1 in Perl_call_sv ()
> #12 0x40250c04 in gperl_closure_marshal (closure=0x842ca90, return_value=0x0, 
> n_param_values=1, param_values=0xbfffea10, invocation_hint=0xbfffe8f8,
>     marshal_data=0x40769d60) at GClosure.xs:106
> #13 0x402846b6 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
> #14 0x40295ec8 in g_signal_emit_by_name () from /usr/lib/libgobject-2.0.so.0

hrm, if it's gtk2-perl it's likely something going wrong with the
closure/callback. without memory corruption i'm not sure exactly how
gtk_path_bar_get_type would segfault.

is the code that's causing this public/available? if not can you trim it
down to a simple test case that exhibits the problem (maybe hard with
this one.)

-- 
-rm
http://www.neces.com/