Tiny Core Linux
Tiny Core Extensions => TCE Talk => Topic started by: GNUser on January 30, 2020, 08:08:39 PM
-
I compiled fluff version 1.0.7 on TC-11beta Pure64 exactly as shown in Reply #36 here:
http://forum.tinycorelinux.net/index.php/topic,23439.msg147119.html#msg147119
When I try to run the resulting binary in a terminal, I see a new window for a split second then it disappears. There is no output in the terminal other than "Segmentation fault". So I repeated with strace directed to a file:
$ strace ./fluff >strace.txt 2>&1
Here is strace.txt: https://pastebin.com/NKkchyhF
Does the output offer any hints as to why fluff immediately crashes?
-
valgrind may have nicer info. (valgrind fluff)
-
Thanks, curaga. Here you go:
valgrind ./fluff >valgrind.txt 2>&1Here is valgrind.txt: https://pastebin.com/ensPUnid
Any ideas? Hopefully the problem is with the code and not with my hardware/configuration.
-
Before we invest time troubleshooting, it would be nice if someone could confirm that the code can be successfully compiled and run on a machine with 64-bit processor.
P.S. The -Wno-narrowing flag at compilation step was my addition, to prevent compilation from erroring-out. It seems some of the fluff developer's assumptions regarding the size of char and int are not true on 64-bit architecture.
-
Hi GNUser
... P.S. The -Wno-narrowing flag at compilation step was my addition, to prevent compilation from erroring-out. It seems some of the fluff developer's assumptions regarding the size of char and int are not true on 64-bit architecture.
Size of a char is 8 bits (ASCII strings). Size of an int is machine dependent.
The section of code causing the error is:
struct filetype_hint FiletypeHint[MAXFILEHINT] = {
// filetype, hint_method, offset, pattern, length
{FT_TEXT, HINTMETHOD_STRING, 0, "", 0},
{FT_EXEC, HINTMETHOD_STRING, 1, "ELF", 3},
{FT_SHELLSCRIPT, HINTMETHOD_STRING, 0, "#!/", 3},
{FT_TCZ_EXT, HINTMETHOD_EXTENSION,0, ".tcz", 4},
{FT_LST, HINTMETHOD_EXTENSION,0, ".lst", 4},
// {FT_IMAGE_JPG, HINTMETHOD_BYTES, 0, {0xFF, 0xD8, 0x00, 0x00}, 2 },
{FT_IMAGE_JPG, HINTMETHOD_BYTES, 0, {'\255', '\216', '\0', '\0'}, 2 },
{FT_IMAGE_JPG, HINTMETHOD_STRING, 6, "JFIF", 4 },
{FT_IMAGE_JPG, HINTMETHOD_STRING, 6, "Exif", 4 },
{FT_IMAGE_PNG, HINTMETHOD_STRING, 1, "PNG", 3 },
{FT_IMAGE_GIF, HINTMETHOD_STRING, 0, "GIF", 3 },
{FT_IMAGE_BMP, HINTMETHOD_STRING, 0, "BM", 2 },
{FT_IMAGE_XPM, HINTMETHOD_STRING, 3, "XPM", 3 },
{-1, 0, 0, "", 0 }
};
The values used for HINTMETHOD_BYTES appear to be the issue. HINTMETHOD_BYTES doesn't actually have anything to do
with bytes, which are 8 bits. It's just a symbol whose defined value is 1. The compiler is interpreting the hex values as int but
that field is defined as containing char. I commented out the original version of the HINTMETHOD_BYTES line and added a
corrected version. It now compiles cleanly without -Wno-narrowing.
-
Thanks, Rich. Very nice. After making your edit, I can compile on my laptop (64bit processor running TC11-beta Pure64) without the -Wno-narrowing flag. However, the binary still segfaults:
bruno@box:~/Downloads/fluff_1_0_7_src$ g++ -mtune=generic -Os -fno-exceptions -fno-rtti -fpic -L/usr/lib -lfltk -lfltk_images -lfltk_forms -lpng -o fluff fluff.cpp
fluff.cpp: In member function ‘void Manage_Associations_Window::update()’:
fluff.cpp:2361:40: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
2361 | cmd_list_p->data(n, (void*)i);
| ^
fluff.cpp: In member function ‘void Manage_Filetypes_Window::update()’:
fluff.cpp:2532:45: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
2532 | hint_list_p->data(n, (void*)fh);
| ^~
bruno@box:~/Downloads/fluff_1_0_7_src$ ./fluff
Segmentation fault
bruno@box:~/Downloads/fluff_1_0_7_src$ valgrind ./fluff >valgrind.txt 2>&1
Here is valgrind.txt: https://pastebin.com/CvXunZVX
-
Hi GNUser
I compiled a 64 bit version of fluff under TC11beta1 Pure64 and it runs fine. Binary and installed.txt Emailed.
Maybe your machine has some bad mojo, or some bad RAM?
-
Thank you very much, Rich. I have some interesting news.
Knowing that this binary works for you, I decided to keep testing it until it (hopefully) worked for me.
When I first tried it, it segfaulted. So I figured I'd try decreasing the number and complexity of loaded extensions.
Eventually I got down to this in my onboot.lst:
Xorg-7.7.tcz
flwm.tcz
rxvt.tcz
mylocale.tcz
wpa_supplicant-dbus.tcz
xf86-video-intel.tczWith the above, the 64-bit binary you sent works perfectly :)
So I tried this in onboot.lst (fluxbox is my daily driver WM):
Xorg-7.7.tcz
fluxbox.tcz
rxvt.tcz
mylocale.tcz
wpa_supplicant-dbus.tcz
xf86-video-intel.tczWith the above, the fluff binary segfaults.
It turns out that with either onboot.lst, all of fluxbox's dependencies are loaded. Therefore, fluxbox itself is to blame here. Whenever it is loaded, the fluff binary segfaults. Strange.
(Fortunately, fluxbox plays nicely with xfe which is my file manager of choice.)
I submitted a 64bit fluff extension to juanito.
-
P.S. This is why I love TCL. No other OS provides this kind of modularity--I doubt it would have been possible to figure this out on any other OS.
-
Hi GNUser
... It turns out that with either onboot.lst, all of fluxbox's dependencies are loaded. Therefore, fluxbox itself is to blame here. Whenever it is loaded, the fluff binary segfaults. Strange. ...
Well, maybe fluxbox itself needs a recompile. According to this:
http://tinycorelinux.net/11.x/x86_64/tcz/fluxbox.tcz.info
it was last compiled on 2013/11/10. It's possible the ABI of one of its dependencies changed in that time.
-
Maybe your machine has some bad mojo...?
It's a Libreboot ThinkPad running Tiny Core Linux, how could it possibly have bad mojo? 8)
Well, maybe fluxbox itself needs a recompile.
A good idea, so I went ahead and compiled the latest fluxbox (1.3.7) in TC11-beta Pure64. Compilation went smoothly and the new fluxbox runs fine, but has the same exact issue with fluff (immediate segfault). I'm inclined to just let things be at this point--I have not found any other bugs in the current fluxbox extension (1.3.5) despite many months of heavy use.
-
Hi GNUser
... The compiler is interpreting the hex values as int but
that field is defined as containing char. I commented out the original version of the HINTMETHOD_BYTES line and added a
corrected version. ...
While not fatal, the corrected version in reply #4 is wrong. The notation I used resulted in octal, not decimal. I fixed that and
a few other things in the source and created a patch file. The patch file and the tarball it applies to are attached. I Emailed you
new binaries to try out.
If anyone is versed in CPP please feel free to check my work.
--- fluff.cpp.old 2012-06-26 10:25:42.000000000 +0000
+++ fluff.cpp 2020-02-01 01:36:04.853249676 +0000
@@ -1,8 +1,20 @@
// Fluff -- A fast, light utility for files
// See About_text[] below for copyright and distribution license
-#define APP_VER "1.0.7" // Last update 2012-06-26
-
+#define APP_VER "1.0.8" // Last update 2012-06-26
+/*
+ * Version 1.0.8 updated 2020-02-01 by Rich
+ * Changed #include <Fl/Fl_Hold_Browser.H to #include <FL/Fl_Hold_Browser.H
+ * Changed {0xFF, 0xD8, 0x00, 0x00} to {'\xFF', '\xD8', '\x00', '\x00'} in
+ * struct filetype_hint FiletypeHint. Compiler was generating int instead of byte.
+ * I think the next 2 were typos.
+ * They caused "cast to pointer from integer of different size" compiler warnings.
+ * Changed cmd_list_p->data(n, (void*)i); to cmd_list_p->data(n, (void*)&assoc[i]);
+ * Changed hint_list_p->data(n, (void*)fh); to hint_list_p->data(n, (void*)&file_hint[fh]);
+ * Changed define FIRST_CONFIGURED_FILEHINT 11 to define FIRST_CONFIGURED_FILEHINT 12
+ * because XPM FiletypeHint would not display.
+ */
+
// DEFINE TO 1 TO SEE PROGRESS SLOWLY
#if 0
#define DELAY_FOR_TESTING Fl::wait(1.0)
@@ -88,7 +100,7 @@
#include <FL/Fl_Tooltip.H>
#include <FL/Fl_Browser.H>
#include <FL/Fl_Select_Browser.H>
-#include <Fl/Fl_Hold_Browser.H>
+#include <FL/Fl_Hold_Browser.H>
#include <FL/Fl_Multi_Browser.H>
#include <FL/Fl_Pack.H>
#include <FL/fl_draw.H>
@@ -569,7 +581,7 @@
{FT_SHELLSCRIPT, HINTMETHOD_STRING, 0, "#!/", 3},
{FT_TCZ_EXT, HINTMETHOD_EXTENSION,0, ".tcz", 4},
{FT_LST, HINTMETHOD_EXTENSION,0, ".lst", 4},
- {FT_IMAGE_JPG, HINTMETHOD_BYTES, 0, {0xFF, 0xD8, 0x00, 0x00}, 2 },
+ {FT_IMAGE_JPG, HINTMETHOD_BYTES, 0, {'\xFF', '\xD8', '\x00', '\x00'}, 2 },
{FT_IMAGE_JPG, HINTMETHOD_STRING, 6, "JFIF", 4 },
{FT_IMAGE_JPG, HINTMETHOD_STRING, 6, "Exif", 4 },
{FT_IMAGE_PNG, HINTMETHOD_STRING, 1, "PNG", 3 },
@@ -579,7 +591,7 @@
{-1, 0, 0, "", 0 }
};
int HintCountPerFiletype[MAXFILEHINT] = {0,0,0,0, 0,0,0,0, 0,0,0,0, 0,0,0,0};
-#define FIRST_CONFIGURED_FILEHINT 11
+#define FIRST_CONFIGURED_FILEHINT 12
int FiletypeHints = FIRST_CONFIGURED_FILEHINT;
int AssocCountPerFiletype[MAXASSOC] = {0,0,0,0, 0,0,0,0, 0,0,0,0, 0,0,0,0};
@@ -2358,7 +2370,7 @@
sprintf(buf, "%d. %s: %s", n, assoc[i].action_label,
assoc[i].cmd_spec);
cmd_list_p->add(buf);
- cmd_list_p->data(n, (void*)i);
+ cmd_list_p->data(n, (void*)&assoc[i]);
//printf("Manage... Added assoc[%d] to list: %s\n", i, buf); fflush(0);
if (i == sel_assoc) {
sel_line = n;
@@ -2529,7 +2541,7 @@
hint_list_p->add(buf);
//printf(" %s\n", buf); fflush(0);
- hint_list_p->data(n, (void*)fh);
+ hint_list_p->data(n, (void*)&file_hint[fh]);
n++;
}
}
-
For valgrind output to be useful, like gdb backtraces, you need a debug binary (-g in compile options, no stripping). Otherwise you get all question marks like that.
The output did look like a code bug in fluff, fwiw.
edit: Rich, the pointer changes also changed what is passed. You also need to change the logic on the other side, otherwise that would cause crashes.
-
Thank you both. I will be out of town for next few days. Will be back mid-week.
-
For valgrind output to be useful, like gdb backtraces, you need a debug binary (-g in compile options, no stripping). Otherwise you get all question marks like that.
I recompiled fluff (version 1.0.7 without any patches) with the -g flag. No change in valgrind output (still lots of question marks everywhere).
If you guys would like to leave this bug in peace until it affects a user, fine by me. If you'd like to continue troubleshooting, also fine by me--just give me a hint what to do next and I'll be happy to help.
-
You can use "-ggdb -Og" for more output - note that you might need to recompile some of the deps to get rid of all of the question marks.
-
Thanks, juanito.
$ g++ -ggdb -Og -mtune=generic -fno-exceptions -fno-rtti -fpic -Wno-narrowing -L/usr/lib -lfltk -lfltk_images -lfltk_forms -lpng -o fluff fluff.cpp
fluff.cpp: In member function ‘void Manage_Associations_Window::update()’:
fluff.cpp:2361:40: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
2361 | cmd_list_p->data(n, (void*)i);
| ^
fluff.cpp: In member function ‘void Manage_Filetypes_Window::update()’:
fluff.cpp:2532:45: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
2532 | hint_list_p->data(n, (void*)fh);
| ^~
$ ./fluff
Segmentation fault
$ valgrind ./fluff >valgrind.txt 2>&1
Here is valgrind.txt: https://pastebin.com/4kcQbXPb
It seems there are still too many question marks for the output to be helpful :-\ Oh, well. I don't want to recompile too many libraries just to debug this.
-
Did you try gdb?
-
Is the fluff developer still active in the TCL community? Maybe he'd have some insight. To reproduce the bug, one simply needs to run fluff while fluxbox is running. The result is a consistent, immediate segfault. This is true regardless of architecture (32-bit vs. 64-bit) and fluxbox version.
Alas, I'm weak in both gdb and c++ , so I'd best throw in the towel on this one :-[
If a fix is found, I'll be more than happy to test it and submit updated fluff extensions.
-
FWIW I submitted updated fluxbox extensions for TCL11 (both 32-bit and 64-bit).
I can't help in all the ways I'd like, but will help in all the ways I can.
-
I just compiled fluff with @Rich patch and ran it with gdb using the new fluxbox - it doesn't crash for me...
-
juanito, I just compiled fluff with Rich's patch. It compiles without any warnings or errors, but segfaults even on new fluxbox.
Whenever I've encountered intractable problems like this (i.e., related to graphics drivers or libraries) before, Libreboot was ultimately the culprit. If it's working for everybody but me, it's probably a Libreboot issue.
-
Could you submit the extension with Rich's patch anyway?
-
I'll be happy to. I'll apply Rich's patch and will submit new 32-bit and 64-bit extensions (will bump up the version to 1.0.8 ). I'll do it in flwm so I can test everything. Will submit it later today.
BTW I popped my harddrive into a totally different machine (HP Inspiron laptop with stock BIOS) and fluff still segfaults if fluxbox is running. So this is not an issue with my main laptop's Libreboot or RAM.
-
Hi GNUser
Are you running Xorg, Xvesa, Xfbdev ?
-
I figured it out, finally.
With fluxbox 1.3.7 and fluff 1.0.8, the segfaults would only happen on Pure64 11 when mylocale.tcz (which I copied from Pure64 10.1) was loaded. Creating a new mylocale.tcz on Pure64 11 (via $ tce-load -wi getlocale) fixed the problem.
-
fluff 1.0.8 extensions submitted for both 32bit and 64bit.
In both architectures, compilation succeeds without any warnings or errors (no need for the -Wno-narrowing workaround) thanks to Rich's patch.
The extensions are tested and working perfectly, including with new fluxbox (now that I updated mylocale.tcz... :-[).
-
Now that I have a working mylocale.tcz again (generated in Pure64 11), fluff's segfaults returned:
$ locale
LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=
$ fluff
Segmentation fault
$ LANG=C fluff
[fluff runs fine]
So it seems fluff was crashing NOT because mylocale.tcz was copied over from prior TCL version. If mylocale.tcz was properly generated (in either TCL10.1 or TCL11) and is loaded, then fluff crashes unless the locale is changed to C.
Maybe as currently written, fluff only works with the C locale? I haven't tested others--just en_US.UTF-8 and C.
-
Hi all,
in my installation Fluff segfaults too, but just if I click somewhere in the Filetypes - Associated Apps... dialog.
I'm using Corepure64 (11.x) + Xorg + FLWM, and don't have mylocale.tcz loaded.