Gosmore hangs on startup
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
gosmore (Debian) |
Fix Released
|
Unknown
|
|||
gosmore (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
Precise |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
Impact:
gosmore goes into a busy loop when starting, just using 100% cpu and doing nothing
It is caused by a strict overflow violation in the code, just disabling strict overflow optimizations is the simplest solution until we get something better from upstream.
TEST CASE:
start gosmore
if a window shows up it works, if it just eats 100% not
regression potential:
only disable an optimization flag, fixes a completely broken package, should not cause issues besides maybe some minor performance regressions which are acceptable compared to the current state.
original report:
Installed gosmore on fresh 12.04 machine.
1. Started gosmore - nothing happened.
2. Checked ps - gosmore is inside the proc list. Killed it.
3. Started gosmore. Console output:
$ LC_ALL="C" gosmore
gosmore is in the public domain and comes without warranty
Gtk-WARNING **: Unable to locate theme engine in module_path: "pixmap",
Gtk-WARNING **: Unable to locate theme engine in module_path: "pixmap",
Gtk-WARNING **: Unable to locate theme engine in module_path: "pixmap",
Gtk-WARNING **: Unable to locate theme engine in module_path: "pixmap",
[END OF CONSOLE OUTPUT]
4. One can sigint gosmore from here.
4.a. Expected result: something should happen, I've never used this software before.
Will recompile it with symbols and return with more info.
ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: gosmore 0.0.0.20100711-
ProcVersionSign
Uname: Linux 3.2.0-17-generic x86_64
NonfreeKernelMo
ApportVersion: 1.91-0ubuntu1
Architecture: amd64
Date: Mon Feb 20 18:08:36 2012
EcryptfsInUse: Yes
InstallationMedia: Ubuntu 12.04 LTS "Precise Pangolin" - Alpha amd64 (20120220)
SourcePackage: gosmore
UpgradeStatus: No upgrade log present (probably fresh install)
tags: | added: gosmore |
Changed in gosmore (Debian): | |
status: | Unknown → New |
Changed in gosmore (Debian): | |
status: | New → Confirmed |
description: | updated |
description: | updated |
Changed in gosmore (Debian): | |
status: | Confirmed → Fix Released |
tags: |
added: verification-done removed: verification-needed |
It looks like the flow stays inside the function TagCmp(const char*, const char*), inside a for(;;) statement. There is no exit condition for this statement and thus the application is trapped there eating up 100% CPU. Maybe the break inside the inner for-loop was supposed to break the outer one.