scim-bridge crashed with SIGSEGV in scim::Module::unload() - fixed by "rm -Rf ~/.scim/"

StacktraceTop:scim::Module::unload (this=0x53454741) at scim_module.cpp:258
~Module (this=0x53454741) at scim_module.cpp:132
ScimBridgeAgentImpl::finalize_scim (this=0x98ca2b8)
ScimBridgeAgentImpl::finalize (this=0x98ca2b8)
~ScimBridgeAgentImpl (this=0x98ca2b8)

just upgraded. had been working

Bug still there after all upgrades/updates

Is this bug reproduceable or only after the first login? I'm asking, because I don't see this crash on my system.

Is this the same bug as https://bugs.edge.launchpad.net/ubuntu/+source/scim-bridge/+bug/199592 ?
Can you please try to remove ~/.scim/ and optionally reinstall the scim and scim-bridge packages?

This still happens with 1.4.9-1ubuntu1 as confirmed by rxy in bug 419592

rxy, can you reproduce the problem on every login or does it only happen sometimes? As Arne said in comment 7, does the problem go away when you remove (or move away) ~/.scim/ and reinstall scim and scim-bridge?

I'm not getting any crash reports in Debian. I wonder if this isn't again a regression introduced by one of the Ubuntu patches? If so, it must be one that's been applied for quite a while.

We're seeing a lot of dupes reported for this ticket so it seems that quite a number of users are affected. Alas, neither Arne nor I seem to run into this.

Can those affected please report whether the problem remains even after you remove (or move away) ~/.scim/ and reinstall the scim and scim-bridge package?

removing the ~/.scim/ directory, then re-installing the packages mentioned seems to have remedied the error.

Arne, you asked for this information. What does it mean as far as fixing this bug is concerned?

If removing the ~/.scim/ directory resolves this issue, I guess we cannot fix this bug. It seems to me that it is a configuration conflict between older versions and the current one. The user needs to do this step manually anyways as packages are not supposed to delete data in the users' home directory.

However, if this bug is a duplicate of bug #199592, which I cannot confirm as I cannot read stack traces (I'm not a programmer), it suggests that there is something else going on.

Therefor I'm uncertain what to do with this. I cannot reproduce any of the reported scim related crashes at all.

Unfortunately, there is apparently nothing that can be done from the packaging side. As such, I'm "resolving" this into a question so that others can find the explanation how to deal with the issue.

SBKch, please mark it as solved soon.

I'm resetting this back to a bug for now. My apologies. I skimmed over Arne's comment 13 too quickly that there is still work left to be done to properly understand all the issues here.

hggdh confirmed in #ubuntu-bugs today that the stack traces match. Will mark as dupe.

the two bugs are now finally merged. It's still unclear how to proceed from here since there is currently no known fix that does not involve user intervention.

Maybe a call to postinst could be added that backs up ~/.scim for all users, removes that directory and sends a mail to root about this being done, together with a link to this ticket for further information. Sounds generally like a good way forward, but I somehow seem to recall that postinst scripts should not touch ~/

Fumbling around user directories from postinst is not a good idea. I have added some information in the README instead now. That's the best way to deal with this bug.

See attached patch

why is the sponsors team once more sitting on their "behinds" fiddling thumbs and doing nothing?

Excuse the maybe ignorant question, but why is it assumed to be "just the way it is" if a package chokes on its own config data after an update? Certainly it should be expected to handle such a conflict in some graceful way?

Mario, the first time this bug was reported is over two years ago. Upstream is more or less dead. Ubuntu has moved to ibus.

This is a serious problem, but with an easy enough fix. Feel free to send a patch if you disagree with the proposed solution. I wish we could come up with a proper patch. But as things stand that is extremely unlikely to ever going to happen. Therefore, the best way to deal with this is to document the problem and the workaround and let the user handle it.

There's more rewarding fish to fry and most of them are easier to catch for the people who actually have the skills for properly fix this. Even if there was a fix, in the light of things, it may be bloat. I honestly believe that "rm -Rf ~/.scim" is the most appropriate way this problem should be handled, if and when it occurs. That's my jugment as the Debian maintainer of the scim (not the scim-bridge) package. You're entitled to have a different opinion, of course, and I would respect that.

Oh, I was not aware of the situation as you described it. I understand now, thanks.

This should be forwarded to the upstream developers with a tarball of the ~/.scim directory that exposes the behaviour. Writing this into the documentation is not enough to fix this bug.

Daniel, before I comment on #24, let me ask you whether you think the currently proposed patch is a step in the right direction or not.

I see no sign that upstream is dead. Therefore I agree with Daniel. Please forward the bug report with an example ~/.scim directory tarball to upstream to get a real fix for this bug. Then come back and resubscribe ubuntu-sponsors.

Guys, do as you please. You're not doing Ubuntu a favor by withholding this documentation, that's for sure. Having it documented is better than the current situation. Who knows, it's quite well possible this problem was introduced by one of Ubuntu's ill-guided patches in the past. FWIW, I don't get this kind of report from Debian users.

As Debian maintainer of the scim package and part of the upstream team, you may as well stop second-guessing my judgment about upstream's activities. We're all just there to keep the project limping along, I don't see any real development work for years.

If you have a better solution, we'd be all ears, but don't expect upstream to do original dev work for you. By doing so and withholding an incremental improvement from your user base you are doing them a disservice.

for all those who think that upstream is alive and kicking I have some recommended reading:

http://bugs.debian.org/591467
http://bugs.debian.org/591468

resubscribing sponsors on advice from Daniel Holbach

This bug was fixed in the package scim-bridge - 0.4.16-2ubuntu4

---------------
scim-bridge (0.4.16-2ubuntu4) maverick; urgency=low

  * add some information to the README about crashes induced apparently by
    incompatible data structures in old config files. (LP: #338217)
 -- Rolf Leggewie <email address hidden> Sun, 21 Feb 2010 22:28:50 +0100

Rolf Leggewie, sorry for assuming that upstream is still alive (due to the upstream releases). Stating that you are part of upstream would have given your comment more weight.

scim-bridge was rewritten from scratch and has moved to the scim package. Please reopen a ticket there if you still experience this problem. You can reference this bug if what you see is similar