I'm a web developer and rely heavily on Bluefish for designing and maintaining customer websites. After a recent emerge -u world and emerge -uD world (lots of libs updated), Bluefish now segfaults on startup. It doesn't matter which user I start Bluefish as, or whether a pre-existing local Bluefish config exists. I've tried re-emerging Blueifsh with USE="-gnome" but this doesn't help, and in fact commenting out my USE flags entirely doesn't help. I'm trying to get last-minute work done for clients before leaving town for a week, so won't be able to give feedback for a while on this. Running Bluefish with strace gives the following, which may be of some help. # strace bluefish [snip] lstat64("/root/3c2000_errors", {st_mode=S_IFREG|0644, st_size=410, ...}) = 0 lstat64("/root/.bash_profile", {st_mode=S_IFREG|0644, st_size=1360, ...}) = 0 lstat64("/root/lvm.conf", {st_mode=S_IFREG|0644, st_size=71, ...}) = 0 lstat64("/root/procps-3.1.9", {st_mode=S_IFDIR|0755, st_size=1752, ...}) = 0 lstat64("/root/.bluefish", {st_mode=S_IFDIR|0755, st_size=480, ...}) = 0 lstat64("/root/evolution", {st_mode=S_IFDIR|0700, st_size=320, ...}) = 0 lstat64("/root/.xsession-errors", {st_mode=S_IFREG|0644, st_size=1742, ...}) = 0 lstat64("/root/MyMusic", {st_mode=S_IFDIR|0755, st_size=48, ...}) = 0 lstat64("/root/ABPEA_FAQ_rules.html", {st_mode=S_IFREG|0644, st_size=106323, ...}) = 0 lstat64("/root/.revdep-rebuild.6_status", {st_mode=S_IFREG|0644, st_size=2, ...}) = 0 lstat64("/root/.mailcap", {st_mode=S_IFREG|0644, st_size=4849, ...}) = 0 lstat64("/root/.fonts.cache-1", {st_mode=S_IFREG|0644, st_size=95, ...}) = 0 getdents64(12, /* 0 entries */, 131072) = 0 munmap(0xb6f57000, 135168) = 0 close(12) = 0 getcwd("/root", 4096) = 6 --- SIGSEGV (Segmentation fault) @ 0 (0) --- +++ killed by SIGSEGV +++
Thanks for taking the time to report this bug. Without a stack trace from the crash it's very hard to determine what caused it. Can you provide us with one? Please see http://live.gnome.org/GettingTraces for more information on how to do so.
OK, thanks. gdb showed me that in fact the problem was with a relatively ancient version of Bluefish in /usr/local/bin, and when I accessed /usr/bin/bluefish everything works OK. Sorry for the noise! It looks as if perhaps a recent gentoo system upgrade changed the default $PATH order, putting /usr/local/bin ahead of /usr/bin, or else, more likely, I've been using bluefish in /usr/local/bin for some time and it finally hit the wall on library issues, and my re-emerges, of course, didn't affect this version. Again, sorry for the false report here, but I'm happy to have the problem solved. I"ve marked the bug INVALID.
