rakarrack Segmentation fault

[funkmuscle]

the past few git installs of rakarrack has been crashing at launch:

$ rakarrack

rakarrack 0.5.8_Equinox - Copyright (c) Josep Andreu - Ryan Billing - Douglas McClendon - Arnout Engelen
Try 'rakarrack --help' for command-line options.
Segmentation fault

I've removed the old and reinstalled a new git and still
Segmentation fault

any help?

[autostatic]

File a bug on their Sourceforge page. And did you delete any old 0.4.x Rakarrack config files? And wow, version is now at 0.5.8! Yesterday it was still 0.5.0
And just compiled the git version, doesn't segfault here.

[funkmuscle]

where would I find those files?? I deleted something in .ftlk

[autostatic]

They're in .fltk/rakarrack.sf.net
But if it worked with another git version then it's probably got nothing to do with it.
And what if you run it with strace (strace rakarrack)?

And another bug would be that they spelled raboof's name wrong

[raboof]

the past few git installs of rakarrack has been crashing at launch

I've removed the old and reinstalled a new git and still Segmentation fault

Hmm, I just did a fresh checkout and it's not segfaulting for me. Could you run rakarrack in gdb and get a backtrace please? If you don't know how, https://wiki.ubuntu.com/Backtrace looks like a good guide. Thanks!

[raboof]

And another bug would be that they spelled raboof's name wrong

what - where? 'Arnout Engelen' is actually correct

[autostatic]

Sorry, you're right of course
Ran through the changelogs a bit too enthusiastically

[funkmuscle]

strace gave this:

this is the end of a massive print out?

stat64("/usr/share/fonts/encodings/large", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
open("/var/cache/fontconfig/5ca8086aeacc9c68e81a71e7ef846b3b-le32d4.cache-3", O_RDONLY) = 7
fstat64(7, {st_mode=S_IFREG|0644, st_size=88, ...}) = 0
read(7, "\4\374\2\374\3\0\0\0X\0\0\0 \0\0\0H\0\0\0\0\0\0\0H\0\0\0\235\201\354J"..., 88) = 88
close(7) = 0
time(NULL) = 1276298592
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++
Segmentation fault

[raboof]

this is the end of a massive print out?

Hmm, that snippet doesn't tell me much beyond that you're using a 64-bit architecture - I'm also on 64-bit, so this can't be the issue.

I think a gdb backtrace would be more useful, or perhaps you could pipe the 'massive print out' into a file and attach that?

[funkmuscle]

that's it... 64bit??? I'm on a 32bit.... I've been using the git version for a long time now... All I do to check out a fresh version is 'git pull' in the existing dir...

where did something go wrong and how did the 64bit app build and install on a 32bit?

[raboof]

that's it... 64bit??? I'm on a 32bit

Hmm sorry got that wrong - 'stat64' doesn't refer to cpu architecture, but allows for statistics on very large files. sorry about the noise.

[funkmuscle]

cool...
I'm wondering, should I deleted the directory too and get it all fresh?

[funkmuscle]

cool...
I'm wondering, should I deleted the directory too and get it all fresh?

just did that and same problem...
how do I get the entire reading from strace to paste here or send it somewhere?

[raboof]

cool...
I'm wondering, should I deleted the directory too and get it all fresh?

just did that and same problem...
how do I get the entire reading from strace to paste here or send it somewhere?

I think the backtrace to the crash would be more useful, see https://wiki.ubuntu.com/Backtrace about how to make one.

[transmogrifox]

File a bug on their Sourceforge page. And did you delete any old 0.4.x Rakarrack config files? And wow, version is now at 0.5.8! Yesterday it was still 0.5.0
And just compiled the git version, doesn't segfault here.

I never saw if you tried deleting the config file in .fltk/rakarrack.sf.net. I walked another person through the compile process the other day & had the same result w/ a segfault on startup.

Deleting the old config file was the solution in this case. I think we need to have a look at the process of loading configs to see if we can find what is causing the seg fault & find a more graceful way to handle old configs. The difference in the case I'm talking about is this person was upgrading from 0.4.2. It's hard to know if your problem is related to the same thing.

AutoStatic: The version number increase is intended to keep ahead of PPA's & live CD's who distribute snapshots from git. We will be making the next stable release on, you guessed it, the Equinox. When this release is made, maybe the version number will change again. Anyway, it is to avoid confusion when handling future bug reports, we can look at the version number and know whether it was an official stable release or a build from git. Right now is a good time to be testing & reporting bugs.

funkmuscle & others who read this post: As AustoStatic mentioned, visit the sourceforge project page & use the bug tracking system or forums. This is a good way for us to keep track of bugs & work our way down the list.

Whether removing the config files makes a difference, a backtrace would be really helpful for us. A Segmentation fault means the program is doing something bad and the Linux police have killed it at the scene of the crime.