[Call for Testing] X.org 7.5 for FreeBSD
yanefbsd at gmail.com
Thu Mar 18 18:54:15 UTC 2010
On Thu, Mar 18, 2010 at 11:16 AM, Torfinn Ingolfsen <tingox at gmail.com> wrote:
> On Mon, Mar 15, 2010 at 11:02 PM, Robert Noland <rnoland at freebsd.org> wrote:
>> On Mon, 2010-03-15 at 22:40 +0100, Torfinn Ingolfsen wrote:
>> > On Sun, Mar 14, 2010 at 9:43 PM, Garrett Cooper <yanefbsd at gmail.com>
>> > wrote:
>> > > Could you compile xfce4-session with -g and attach gdb to it as
>> > > it's starting up to get a backtrace please?
>> > So I am guessing that running gdb on the core file I already have (from
>> > xfce4-session) isn't of any use?
>> > I'll have to figure out how to compil with -g and how to "attach gdb"
>> > then.
>> "make -DWITH_DEBUG all deinstall reinstall"
> Ok, I finally found time to try this. After recompiling xfce4-session as
> stated above, I did a 'startxfce4' as root. After that I did 'gdb
> xfce4-session xfce4-session.core'
> Correct so far?
> On loading gdb prints:
> Core was generated by `xfce4-session'.
> Program terminated with signal 6, Aborted.
> then proceeds and load symbols.
> I then try a backtrace:
> (gdb) bt
> #0 0x0000000804bbf91c in kill () from /lib/libc.so.7
> #1 0x0000000804bbe71b in abort () from /lib/libc.so.7
> #2 0x0000000804171c75 in dbus_malloc () from /usr/local/lib/libdbus-1.so.3
> #3 0x000000080416df55 in dbus_watch_handle () from
> #4 0x0000000804163046 in dbus_message_new_signal () from
> #5 0x00000008040271e9 in dbus_g_connection_register_g_object () from
> #6 0x00000008042909ef in g_closure_invoke () from
> #7 0x00000008042a4547 in g_signal_parse_name () from
> #8 0x00000008042a5f96 in g_signal_emit_valist () from
> #9 0x00000008042a6353 in g_signal_emit () from
> #10 0x000000000040f664 in xfsm_client_set_state (client=0x804e56400,
> state=XFSM_CLIENT_SAVINGLOCAL) at xfsm-client.c:344
> #11 0x0000000000414c35 in xfsm_manager_register_client (manager=0x804e1e810,
> client=0x804e56400, previous_id=0x0) at xfsm-manager.c:909
> #12 0x000000000040da34 in sm_register_client (sms_conn=0x804e39300,
> client_data=0x804e56400, previous_id=0x0) at sm-layer.c:210
> #13 0x0000000800f25abe in _SmsProcessMessage () from
> #14 0x0000000801039cd0 in IceProcessMessages () from
> #15 0x000000000040aeb2 in ice_process_messages (channel=0x804e8c100,
> condition=G_IO_IN, user_data=0x804e72f80) at ice-layer.c:111
> #16 0x00000008043fe692 in g_main_context_dispatch () from
> #17 0x0000000804401a2e in g_main_context_check () from
> #18 0x0000000804401d19 in g_main_loop_run () from
> #19 0x0000000801384743 in gtk_main () from
> #20 0x000000000040bbea in main (argc=1, argv=0x7fffffffea08) at main.c:299
> What next?
>> works in most cases. If your existing core doesn't have symbols, then
>> no it won't offer much insight.
Here's the problem area that needs inspecting:
#2 0x0000000804171c75 in dbus_malloc () from /usr/local/lib/libdbus-1.so.3
1. make -C $PORTSDIR/*/dbus extract
2. Find the file where dbus_malloc is defined.
3. Look for an abort.
The pain in the ass part about dbus is that while it's a fairly well
formed communication bus, if the implementing party isn't properly
transmitting messages, then stuff goes south quickly, but dies without
much helpful noise.
But in the meantime, your console may have some helpful messages worth
More information about the freebsd-ports