fluff immediately segfaults

[Juanito]

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.

[GNUser]

Thanks, juanito.

Code: [Select]

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

[Juanito]

Did you try gdb?

[GNUser]

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.

[GNUser]

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.

[Juanito]

I just compiled fluff with @Rich patch and ran it with gdb using the new fluxbox - it doesn't crash for me...

[GNUser]

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.

[Juanito]

Could you submit the extension with Rich's patch anyway?

[GNUser]

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.

[Rich]

Hi GNUser
Are you running Xorg, Xvesa, Xfbdev ?

[GNUser]

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.

[GNUser]

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

[GNUser]

Now that I have a working mylocale.tcz again (generated in Pure64 11), fluff's segfaults returned:

Code: [Select]

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

[core.dump]

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.