Bug 132010

Created attachment 56258 [details]
backtrace of evolution crash

The only relevant difference appears to be federico's interpolation patch.

How weird - the stack trace doesn't run into the interpolation code path at all.

How do you reproduce this?  I have that patched libgnomecanvas and neither gdmgreeter nor evolution crash for me.

I am using the latest and greatest from EDGE (STABLE).  This is still a problem.  I have to used the SL 10.0 packages.

Reproduction is just start Evolution or GDM and they crash on startup.

I can't reproduce it with evolution.

However, it gives me a certain critical warning which is bad:

(evolution:21551): Gdk-CRITICAL **: gdk_gc_set_foreground: assertion `GDK_IS_GC (gc)' failed

It appears a number of times when I activate the calendar, and it always happens here:

#0  0x41223134 in g_log () from /opt/gnome/lib/libglib-2.0.so.0
#1  0x412232bc in g_return_if_fail_warning () from /opt/gnome/lib/libglib-2.0.so.0
#2  0x41069b72 in gdk_gc_set_foreground () from /opt/gnome/lib/libgdk-x11-2.0.so.0
#3  0x400646d3 in e_url_entry_get_entry () from /opt/gnome/lib/evolution/2.4/libemiscwidgets.so.0
#4  0x411c60eb in g_cclosure_marshal_VOID__OBJECT () from /opt/gnome/lib/libgobject-2.0.so.0
#5  0x411b8637 in g_cclosure_new_swap () from /opt/gnome/lib/libgobject-2.0.so.0
#6  0x411b8d19 in g_closure_invoke () from /opt/gnome/lib/libgobject-2.0.so.0
#7  0x411c89a7 in g_signal_stop_emission () from /opt/gnome/lib/libgobject-2.0.so.0
#8  0x411c9e80 in g_signal_emit_valist () from /opt/gnome/lib/libgobject-2.0.so.0
#9  0x411ca1f5 in g_signal_emit () from /opt/gnome/lib/libgobject-2.0.so.0
#10 0x40067deb in e_canvas_item_grab_focus () from /opt/gnome/lib/evolution/2.4/libemiscwidgets.so.0

Hmm, this is weird:

1. I got the new libgnomecanvas package, built it with debug info.  Evolution didn't crash.

2. My gdmgreeter from the version of GDM that came in Suse 10 did not crash.

3. I did "rug install gdm" for the latest gdm.  It crashed when I ran it.

4. I downloaded the sources, patches and specfile for that latest GDM, and built it with debug info and no optimizations.

5. gdmgreeter did not crash.

I smell something fishy with that new gdm package.  I'll rebuild it with optimizations to see if it crashes that way.

Created attachment 57297 [details]
evolutio n crash with debuginfo packages

this is on a SUSE LINUX 10.1 alpha 3 system.

Created attachment 57300 [details]
gdb disassemble output

Further note, packages with the post 10.0 patch built against plus and installed on stable work.

Two guess:
1) libgnomecanvas is doing something evil in  that finally got exposed

2) gcc problem

I looked for build warnings in libgnomecanvas, but saw none.

Next data point, build without binlinear patch (only patch since 10.0) built against stable has the same problem.

Is this bug maybe exposed somewhere without the threading stuff?  That would be a lot easier to debug.  Also, does gdmgreeter crash at startup?  Can you give some more information on how to reproduce the crash?

Btw, which architecture is this on?

It would be really nice if you could create a little program which just creates
the arguments to the segfaulting uta_union_clip as they are and call the function.
This should reproduce the problem if this is a gcc problem.  From a quick look at gcc debugging output you might want to try -fno-ivopts on gnome-canvas.c and see if that fixes the problem.

If you can create that small testcase I'll take over debugging.

Thanks,
Richard.

SMP i386 here, I believe cameron is i386 single processor.

I built the package with -fno-ivopts and it made no difference.

Did the compiler change between STABLE and PLUS?  It wouldn't be the first time that microtile-related code has exposed a compiler bug :)

Created attachment 57545 [details]
132010.c

This little program has the function that crashes (uta_union_clip).  It runs the function with the parameters that get passed in the real crash.

I don't have the actual *contents* of the microtile array from the crash, just its size, but I hope that's enough for now.

Created attachment 57546 [details]
Disassembly, stack contents, registers, etc.

This is the irc log I had with cmeadors; he was running gdb on the crashed program.

The crash is in uta_union_clip+356:

    mov 0x4(%esi),%edx

There, %esi = 0.

This gets set in uta_union_clip+336:
  mov 0xffffffb0(%ebp),%esi

Look at the stack dump near the bottom of the file; the line marked with asterisks has four 0 bytes at the beginning.

I *think* those bytes get set at uta_union_clip+25, near the beginning of the function:
  mov %edx,0xffffffb0(%ebp)

But I couldn't grok to what %edx corresponded there.

I guess it would be good to look at the disassembly of the same function compiled for PLUS.

The 132010.c testcase compiles fine for me and reproduces the bug with -O2 -fno-inline.  I'll investigate.

It's a compiler bug.  You can work around it using -floop-optimize2 (no guarantee that this won't break something else, though) or disabling RTL loop optimization with -fno-loop-optimize.

This defect is tracked by gcc bugzilla
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24899

Worked around with -fno-loop-optimize for now, Richard please assign back to us to pull the compiler flag from autobuild when we have a fixed gcc

Wow, thanks a lot, Richard :)  I hope the gcc guys get to it soon.

This should be fixed now in STABLE.