empathy crashed with SIGSEGV in g_type_check_instance_cast()

[alex]

Binary package hint: empathy

It crashed when I tried to rename an Account (while the account name was empty). It happened twice on 2 different accounts.

ProblemType: Crash
Architecture: i386
Date: Wed Sep 30 19:48:41 2009
DistroRelease: Ubuntu 9.10
ExecutablePath: /usr/bin/empathy
NonfreeKernelModules: nvidia
Package: empathy 2.28.0-0ubuntu2
ProcCmdline: empathy
ProcEnviron:
 PATH=(custom, user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-11.36-generic
SegvAnalysis:
 Segfault happened at: 0x7ccfc2 <g_type_check_instance_cast+50>: mov (%edx),%edi
 PC (0x007ccfc2) ok
 source "(%edx)" (0x752d6e65) not located in a known VMA region (needed readable region)!
 destination "%edi" ok
SegvReason: reading unknown VMA
Signal: 11
SourcePackage: empathy
StacktraceTop:
 g_type_check_instance_cast ()
 ?? ()
 g_cclosure_marshal_VOID__PARAM ()
 g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
 ?? () from /usr/lib/libgobject-2.0.so.0
Title: empathy crashed with SIGSEGV in g_type_check_instance_cast()
Uname: Linux 2.6.31-11-generic i686
UserGroups: adm admin cdrom dialout lpadmin plugdev sambashare

[Pedro Villavicencio (pedro)]

Thanks for your bug report. Please try to obtain a backtrace http://wiki.ubuntu.com/DebuggingProgramCrash and attach the file to the bug report. This will greatly help us in tracking down your problem.

[alex (1alex)]

Backtrace

[Sebastien Bacher (seb128)]

the stacktrace is similar to bug #437111 which is fixed now in karmic

[Daniel Holbert (dholbert)]

The stacktraces don't look very similar to me...

And even if they were similar, bug #437111's patch looks super-targeted to fix its specific crash. it's a _very_ small fix, which just adds a return-if-null immediately before that bug's crash. (specifically, before the call to empathy_account_settings_get_account)

I don't think that return-if-null patch could feasibly fix anything beyond that specific bug.

[Sebastien Bacher (seb128)]

Daniel, could you open a new bug using apport rather than re-opening this one?

[Daniel Holbert (dholbert)]

I didn't file this bug, nor am I sure if it's still reproducible (or how to reproduce it), so I'm not filing a new bug.

I explained why I reopened it in Comment #5 -- I don't agree with (or perhaps understand?) your justification for closing it in the first place. The "fix released" on bug #437111 is highly unlikely to fix this bug, given the stacktrace posted here.

Can you explain why you think this is fixed by bug #437111's patch?