fluff immediately segfaults

[GNUser]

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:

Code: [Select]

$ 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?

[curaga]

valgrind may have nicer info. (valgrind fluff)

[GNUser]

Thanks, curaga. Here you go:

Code: [Select]

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.

[GNUser]

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.

[Rich]

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:

Code: [Select]

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.

[GNUser]

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:

Code: [Select]

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

[Rich]

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?

[GNUser]

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:

Code: [Select]

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):

Code: [Select]

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.

[GNUser]

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.

[Rich]

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.

[GNUser]

Maybe your machine has some bad mojo...?

It's a Libreboot ThinkPad running Tiny Core Linux, how could it possibly have bad mojo?

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.

[Rich]

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.

Code: [Select]

--- 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++;
             }
         }

[curaga]

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.

[GNUser]

Thank you both. I will be out of town for next few days. Will be back mid-week.

[GNUser]

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.