gdm reloads when typing the first letter in the password box

Bug #6119 reported by David Nielsen
This bug report is a duplicate of:  Bug #5967: Evolution crashes on launch. Edit Remove
2
Affects Status Importance Assigned to Milestone
gdm (Ubuntu)
Incomplete
Medium
Ubuntu GNOME

Bug Description

Running dapper using gdm 2.13.0.3-0ubuntu1 gdm reloads whenever one enters the first letter of ones password.

Strangely it works fine for entering the username.

I've tested with both the fglrx and the radeon drivers, with the fglrx one gdm reloads the welcome screen, using the radeon driver it will reload to a blank screen that also dominates the vt' - I can hear from the audio that it loads gdm but I can't make it display it.

Revision history for this message
David Nielsen (davidnielsen-deactivatedaccount) wrote : gdm log

This is the gdm log, I hope this helps identify the issue.

Revision history for this message
David Nielsen (davidnielsen-deactivatedaccount) wrote : gdm trace

The current way I get X, as gdm is broken, is booting to single user mode, exiting, logging on as my user, sudo killall gdm, then the following trace appears. I delete the X lock files and run startx.
A bit cumbersome but it works.

Revision history for this message
Sebastien Bacher (seb128) wrote :

Thanks for your bug. Could you attach your /etc/X11/xorg.conf to the bug?

Changed in gdm:
assignee: nobody → gnome
status: New → NeedInfo
Revision history for this message
David Nielsen (davidnielsen-deactivatedaccount) wrote :
Download full text (3.5 KiB)

I found that possibly all of the bugs I've hit thus far seem to trace back to the same piece of code, namely pango.

I noticed a similar issue to the gdm one when issuing gksu synaptic, it would disappear straight after typing the first letter.

--
david@price:~$ gksu -a -g -d synaptic
xauth: /tmp/libgksu1.2-oSvawr/.Xauthority
cmd[0]: /usr/bin/sudo
cmd[1]: -H
cmd[2]: -S
cmd[3]: -p
cmd[4]: GNOME_SUDO_PASS
cmd[5]: -u
cmd[6]: root
cmd[7]: --
cmd[8]: synaptic
buffer: -GNOME_SUDO_PASS-
Yeah, we're in...

Pango-ERROR **: file basic-fc.c: line 347 (basic_engine_shape): assertion failed: (face != NULL)
aborting...
Trace/breakpoint trap
--

Now if pango is the cause of all these ills, the following should be helpful:

Thread 1 (Thread -1209018144 (LWP 11316)):
#0 IA__g_logv (log_domain=<value optimized out>, log_level=G_LOG_LEVEL_ERROR,
    format=0x4264c298 "file %s: line %d (%s): assertion failed: (%s)",
    args1=0xbff716fc "?+\u03f7[\001") at gmessages.c:503
#1 0x42625ae4 in IA__g_log (log_domain=0x59 <Address 0x59 out of bounds>, log_level=89,
    format=0x59 <Address 0x59 out of bounds>) at gmessages.c:517
#2 0x42625b50 in IA__g_assert_warning (log_domain=0x59 <Address 0x59 out of bounds>,
    file=0x59 <Address 0x59 out of bounds>, line=89,
    pretty_function=0xb7cf2bc3 "basic_engine_shape", expression=0xb7cf2b32 "face != NULL")
    at gmessages.c:552
#3 0xb7cf296e in ?? () from /usr/lib/pango/1.4.0/modules/pango-basic-fc.so
#4 0xb7cf2b02 in ?? () from /usr/lib/pango/1.4.0/modules/pango-basic-fc.so
#5 0xb7cf2b3f in ?? () from /usr/lib/pango/1.4.0/modules/pango-basic-fc.so
#6 0x0000015b in ?? ()
#7 0xb7cf2bc3 in ?? () from /usr/lib/pango/1.4.0/modules/pango-basic-fc.so
#8 0xb7cf2b32 in ?? () from /usr/lib/pango/1.4.0/modules/pango-basic-fc.so
#9 0x00000038 in ?? ()
#10 0x424ba900 in __malloc_initialize_hook () from /lib/tls/i686/cmov/libc.so.6
#11 0xbff71758 in ?? ()
#12 0x423f22ba in free () from /lib/tls/i686/cmov/libc.so.6
#13 0xb7f15bf7 in _pango_engine_shape_shape (engine=0x80d4d30, font=0x81e6758,
    text=0x80cedf0 "\uffff\227\217", length=89, analysis=0x81e6714, glyphs=0x81e6758)
    at pango-engine.c:73
#14 0xb7f24d91 in pango_shape (text=0x59 <Address 0x59 out of bounds>, length=89, analysis=0x0,
    glyphs=0x81e6758) at shape.c:47
#15 0xb7f1951c in shape_run (line=0x81a82e8, state=0xbff71a18, item=0x81e6708)
    at pango-layout.c:2707
#16 0xb7f1bb8b in process_item (layout=0x80b6438, line=0x81a82e8, state=0xbff71a18, force_fit=1,
    no_break_at_end=0) at pango-layout.c:2799
#17 0xb7f1c0e5 in pango_layout_check_lines (layout=0x80b6438) at pango-layout.c:3001
#18 0xb7f1e000 in pango_layout_get_lines (layout=0x80b6438) at pango-layout.c:1022
#19 0x428fdb0f in gtk_entry_adjust_scroll (entry=0x80bf5a0) at gtkentry.c:3425
#20 0x428fe3cb in recompute_idle_func (data=0x80bf5a0) at gtkentry.c:2906
#21 0x4261f734 in g_idle_dispatch (source=0x81de848, callback=0, user_data=0x59) at gmain.c:3761
#22 0x4261d4e7 in IA__g_main_context_dispatch (context=0x8084d00) at gmain.c:1913
#23 0x426204d6 in g_main_context_iterate (context=0x8084d00, block=1, dispatch=1, self=0x8086770)
    at gmain.c:2544
#24 0x426207f8 in IA__g_main_loop_run (loop...

Read more...

Revision history for this message
David Nielsen (davidnielsen-deactivatedaccount) wrote : xorg.conf

as requested, xorg.conf

Revision history for this message
David Nielsen (davidnielsen-deactivatedaccount) wrote :

To the best of my understanding this means that for hidden characters, when hitting the g_assert in line 347

face = pango_fc_font_lock_face (fc_font);
g_assert (face != NULL);

will always be NULL, all of this code was introduced upstream with revision 1.21, no later revision appears to change the logic so I assume this bug is present in upstream CVS as well.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.