Libcolumbus

hud-service crashed with signal 7 in Columbus::Trie::append()

Bug #1282261 reported by Jon Champagne on 2014-02-19

10

This bug affects 1 person

Affects		Status	Importance	Assigned to	Milestone
	Libcolumbus	Invalid	Undecided	Unassigned
	hud (Ubuntu)	Fix Released	Medium	Unassigned

Bug Description

Random bug. Not aware of what caused it past heavy workload.

ProblemType: Crash
DistroRelease: Ubuntu 14.04
Package: hud 13.10.1+14.04.20140218.2-0ubuntu1
ProcVersionSignature: Ubuntu 3.11.0-88.8-mptcp
Uname: Linux 3.11.0-88-mptcp x86_64
NonfreeKernelModules: ufsd
ApportVersion: 2.13.2-0ubuntu5
Architecture: amd64
CurrentDesktop: Unity
Date: Wed Feb 19 15:39:52 2014
ExecutablePath: /usr/lib/x86_64-linux-gnu/hud/hud-service
InstallationDate: Installed on 2014-02-12 (7 days ago)
InstallationMedia: It
ProcCmdline: /usr/lib/x86_64-linux-gnu/hud/hud-service
ProcEnviron:
PATH=(custom, no user)
LANGUAGE=en_CA:en
XDG_RUNTIME_DIR=<set>
LANG=en_CA.UTF-8
SHELL=/bin/bash
Signal: 7
SourcePackage: hud
StacktraceTop:
Columbus::Trie::append(char const*, int) () from /usr/lib/x86_64-linux-gnu/libcolumbus.so.1
Columbus::Trie::addNewNode(unsigned int) () from /usr/lib/x86_64-linux-gnu/libcolumbus.so.1
Columbus::Trie::addNewSibling(unsigned int, unsigned int, unsigned short) () from /usr/lib/x86_64-linux-gnu/libcolumbus.so.1
Columbus::Trie::insertWord(Columbus::Word const&, unsigned int) () from /usr/lib/x86_64-linux-gnu/libcolumbus.so.1
Columbus::WordStore::getID(Columbus::Word const&) () from /usr/lib/x86_64-linux-gnu/libcolumbus.so.1
Title: hud-service crashed with signal 7 in Columbus::Trie::append()
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm bumblebee cdrom dip fuse lpadmin plugdev sambashare sudo

Tags:

Revision history for this message

Jon Champagne (jayseejc3191) wrote on 2014-02-19:

#1

Dependencies.txt Edit (5.1 KiB, text/plain; charset="utf-8")
Disassembly.txt Edit (1.4 KiB, text/plain; charset="utf-8")
ProcMaps.txt Edit (125.3 KiB, text/plain; charset="utf-8")
ProcStatus.txt Edit (839 bytes, text/plain; charset="utf-8")
Registers.txt Edit (787 bytes, text/plain; charset="utf-8")
Stacktrace.txt Edit (4.2 KiB, text/plain; charset="utf-8")
ThreadStacktrace.txt Edit (6.8 KiB, text/plain; charset="utf-8")
upstart.hud.log.txt Edit (10.5 KiB, text/plain; charset="utf-8")

Revision history for this message

Apport retracing service (apport) wrote on 2014-02-19:

#2

StacktraceTop:
Columbus::Trie::append (this=0xdbee40, data=0x7fff352135e0 "\377\377\377\377\244\023", size=<optimized out>) at /build/buildd/libcolumbus-1.0.0+14.04.20140120/src/Trie.cc:137
Columbus::Trie::addNewNode (this=this@entry=0xdbee40, parent=parent@entry=5028) at /build/buildd/libcolumbus-1.0.0+14.04.20140120/src/Trie.cc:149
Columbus::Trie::addNewSibling (this=this@entry=0xdbee40, node=node@entry=5028, sibling=5912, l=<optimized out>) at /build/buildd/libcolumbus-1.0.0+14.04.20140120/src/Trie.cc:160
Columbus::Trie::insertWord (this=0xdbee40, word=..., wordID=78) at /build/buildd/libcolumbus-1.0.0+14.04.20140120/src/Trie.cc:186
Columbus::WordStore::getID (this=0x18e9938, w=...) at /build/buildd/libcolumbus-1.0.0+14.04.20140120/src/WordStore.cc:59

Revision history for this message

Apport retracing service (apport) wrote on 2014-02-19: Stacktrace.txt

#3

Stacktrace.txt Edit (8.1 KiB, text/plain)

Revision history for this message

Apport retracing service (apport) wrote on 2014-02-19: StacktraceSource.txt

#4

StacktraceSource.txt Edit (6.1 KiB, text/plain)

Revision history for this message

Apport retracing service (apport) wrote on 2014-02-19: ThreadStacktrace.txt

#5

ThreadStacktrace.txt Edit (9.1 KiB, text/plain)

Changed in hud (Ubuntu):
importance:	Undecided → Medium
tags:	removed: need-amd64-retrace

Revision history for this message

Jussi Pakkanen (jpakkane) wrote on 2014-03-17:

#6

That piece of libcolumbus stores dictionary info to a mmap backed temporary file. The error happens when the system expands the size of the backing store. Signal 7 is SIGBUS so there may be some problems with the way the mmap segment is set up.

The only explanation I can think of offhand is that temp space is filled up for whatever reason and the ftruncate call succeeds but when trying to use the allocated space, the kernel decides not to give the space to us and instead kills the process with the signal.

Charles Kerr (charlesk) on 2014-03-17

information type:

Private → Public

Pete Woods (pete-woods) on 2014-04-15

Changed in hud (Ubuntu):
status:	New → Fix Released
Changed in libcolumbus:
status:	New → Invalid

Report a bug

This report contains Public information

Everyone can see this information.

You are

Subscribing...

Edit bug mail

Other bug subscribers

Remote bug watches

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