Re: regression from 2.6.5 to 2.6.6 ?

2016-10-24 Thread zlists 
On Mon, Oct 24, 2016 at 21:59 (+0100), Dominik Vogt wrote:

> On Sun, Oct 23, 2016 at 11:39:14AM -0300, zli...@ns.sympatico.ca wrote:
>> On Sun, Oct 23, 2016 at 13:25 (+0100), Dominik Vogt wrote:
> ...
>>> Can you please try out the branch "dv/fix-cr-merging" tha I've
>>> just pushed and see if the fix works for you?  (For me, it does.)
>> And it does for me.

> I've overwritten the branch with a new, hopefully portable version
> of the patch.  Can you please try it again?

>> What is slightly weird is that if I have the acroread window wholly
>> contained on my laptop screen and go into full screen, the window
>> warps over to the external monitor.

> Is that something new or has it always been this way?

> I'll have a look at how acroread actually does the transition to
> fullscreen mode.  Maybe it's doing something differently.

I can only say that I'm 99% sure that is new with 2.6.6.  I tried it
on a desktop with two equal-sized monitors and it jumped to the
rightmost monitor (and my laptop's external monitor is to the right).

Maybe fvwm+acroread is some sort of right-wing sort of thing.  (One
might hope not, depending on one's views.)

Cheers.

Re: regression from 2.6.5 to 2.6.6 ?

2016-10-23 Thread zlists 
On Sun, Oct 23, 2016 at 13:25 (+0100), Dominik Vogt wrote:

> On Sat, Oct 22, 2016 at 07:56:31PM -0300, zli...@ns.sympatico.ca wrote:
>> On Sat, Oct 22, 2016 at 23:29 (+0100), Thomas Adam wrote:

>>> On Sat, Oct 22, 2016 at 07:26:50PM -0300, zli...@ns.sympatico.ca wrote:
 On Sun, Jul 17, 2016 at 15:08 (+0100), Thomas Adam wrote:

> On Sun, Jul 17, 2016 at 08:38:10AM -0300, zli...@ns.sympatico.ca wrote:
>> On Sat, Jul 16, 2016 at 23:27 (+0100), Thomas Adam wrote:

>>> On Sat, Jul 16, 2016 at 07:10:24PM -0300, zli...@ns.sympatico.ca wrote:
 I recently upgraded a computer from Slackware64 14.1 to 14.2, which
 bumped by fvwm version from 2.6.5 to 2.6.6.

 With the new system, when I ask Adobe reader 9.5.5 to go full-screen,
 I get a window with no decorations, but it only occupies about 3/4 of
 the screen, off to the lower right.

> I've found the problem but I don't know how to fix it in a proper,
> i.e. portable way.  In FEvent.c we have this function

>   void fev_sanitise_configure_request(XConfigureRequestEvent *cr)
>   {
>   if (cr->value_mask & CWX)
>   {
>   cr->x = (((int)cr->x) & 0x);
>   }
>   ...
>   if (cr->value_mask & CWHeight)
>   {
>   cr->height = (((unsigned int)cr->height) & 0x);
>   }
>   ...
>   }

> This tries to deal with an inconsistency between the X protocol
> and the Xlib structures:  In the X protocol, in the
> ConfirureWindow request, X and Y are signed "INT16" quantities and
> WIDTH and HEIGT are unsigned "CARD16" quantities, while in the
> Xlib structures they are "int" or "unsigned int".

Too bad the Xlib and the X protocol people weren't talking to each
other :-)


> The code tries to cut off the excess bits from X and Y and does it
> wrong.  With 32-bit integers, if cr->x is -1:

>  ((int)-1) & 0x = 0x & 0x
> = 0x
> = 65535

> I'm not sure how to fix this.  The easiest approach would be to
> cast these values to int16_t or uint16_t from stdint.h, but I
> vaguely remember there are some portability issues with the
> inttypes.s/stdint.h headers.

Would not the casts (short) and (unsigned short) do the trick?
(Admittedly, perhaps somewhere there is a machine whose "short" is not
16 bits, but...)



On Sun, Oct 23, 2016 at 13:36 (+0100), Dominik Vogt wrote:

> On Sat, Oct 22, 2016 at 08:36:10PM -0300, zli...@ns.sympatico.ca wrote:
>> On Sun, Oct 23, 2016 at 00:20 (+0100), Thomas Adam wrote:

>>> On Sat, Oct 22, 2016 at 07:56:31PM -0300, zli...@ns.sympatico.ca wrote:
 I cloned the git version about 15 minutes ago and compiled it, and
 acroread still does not go full-screen correctly.

>>> Can you reproduce this using a more accessible program, please?  I'm using
>>> FreeBSD.

>> No, I can't.  That is, all other programs I use which have a
>> "full-screen" mode work fine.

> Can you please try out the branch "dv/fix-cr-merging" tha I've
> just pushed and see if the fix works for you?  (For me, it does.)

And it does for me.

Mostly.  (Close enough that I am happy.)

What is slightly weird is that if I have the acroread window wholly
contained on my laptop screen and go into full screen, the window
warps over to the external monitor.  This does not happen with (e.g.,)
firefox or xournal.

Having said that, this fix takes care of my primary need, so I am
happy.  But if you have another patch which might take care of the
warping-to-other-screen behaviour, I'll be happy to test it.

Thanks for all your efforts.



P.S. If anyone can suggest an fvwm setting so that acroread initially
opens with its window on the same screen as the mouse, rather than
split across the two screens, I'd be happy to hear it.  (As might
other acroread users.)

Re: regression from 2.6.5 to 2.6.6 ?

2016-10-23 Thread zlists 
On Sun, Oct 23, 2016 at 02:44 (+0100), Dominik Vogt wrote:

> As a little bit of explanation how to read this output:

Thanks for the tutorial!

>> cre: 935(1) 0(2) 985(0)x1080(0) fw 0x00401005 w 0x06200031 ew 0x06200031  
>> 'Adobe Reader'
>^^^   ^^^   ^^^   ^^
> X Y   Width  HeightInternal window id

> These are the values from the COnfigureRequest, i.e. the message
> that was generated when the application tried to change the window
> geometry.  If the number is parentheses after the value if zero,
> that bit of information is unused, if it's non-zero, that part of
> the geometry was requested.

> This request looks sensible, and from that I guess your screen is
> 1920x1080 pixels (16:9).
One of my screens is, yes.

>> cre: 0(1) 0(2) 3276(4)x1048(8) fw 0x00401005 w 0x06200031 ew 0x06200031  
>> 'zshguide.pdf - Adobe Reader'

>   "Move window to +0+0 and resize to 3276x1048"

> The width looks weird.
The combination of the internal laptop screen and the external monitor.
(As you probably know at this point.)

>> cre: 0(1) 0(2) 3286(4)x1080(8) fw 0x00401005 w 0x06200031 ew 0x06200031  
>> 'zshguide.pdf - Adobe Reader'

> Similar, but some decorations seem to have been taken into
> account.  From the requested height I assume your window window
> border is 5 pixels thick and the window title is 22 pixels high.
Sounds about right.

>> cre: 65529(1) 65481(2) 3300(4)x1142(8) fw 0x00401005 w 0x06200031 ew 
>> 0x06200031  'zshguide.pdf - Adobe Reader'
>^^
> The program has added space for another border around the window
> by subtracting some pixels from X and Y and adding some to Width
> and Height.  The coordinates have become negative, but the program
> seems to store them as "unsigned short", not as signed int as it
> should.  So it gets a wraparound and requests some astronomically
> huge coordinates (which the X server limits to 16 bits again).

>> cre: 0(0) 0(0) 3300(4)x1142(8) fw 0x00401005 w 0x06200031 ew 0x06200031  
>> 'zshguide.pdf - Adobe Reader'
>   "Resize window (without actually changing its size)

>> cre: 1433(1) 65517(2) 985(4)x1080(8) fw 0x00401005 w 0x06200031 ew 
>> 0x06200031  'zshguide.pdf - Adobe Reader'
> Back to the original size with what looks like random coordinates:
> 1433/18.

> So, is this what you see, a window starting at X=1433 with a page
> that is about 3300 pixels wide?

No.  Well, maybe hard to tell.  The window was occupying the lower
right part of the external monitor, so perhaps it carried on to the
right off the screen for (wild estimate) 3300 - 1400 pixels.



On Sun, Oct 23, 2016 at 11:13 (+0100), Dominik Vogt wrote:

> On Sat, Oct 22, 2016 at 11:26:26PM -0300, zli...@ns.sympatico.ca wrote:
>>> If you have multiple monitors, please describe the geometry of
>>> this setup (coordinates and size of each monitor and on which one
>>> you expect the fullscreen window to appear).
>> Acroread (annoyingly) always starts spread across both screens.  In
>> the above examples, I dragged it completely to the 1920x1080 screen
>> and then typed ^L to get it to go full-screen.

> At least this should be easy to get under control.  Try

NOTE: I tried these by starting a FvwmConsole window and entering them
there, rather than editing my config file.  If that is the Wrong Thing
to do, let me know and I'll do the experiment again.

> Style acroread fixedppos, fixedpsize
[fvwm][style_parse_and_set_window_style]: <> Bad style option: fixedppos

Style acroread fixedpsize

Doesn't help.


> If that doesn't help, try adding

I tried adding your line below (sort of, see below) and then the
EWMHIgnoreStateHints below, and it didn't work.  So I restarted fvwm
and first tried this:

> Style acroread fixeduspos, fixedussize
Style acroread fixeduspos, fixedussize
[fvwm][style_parse_and_set_window_style]: <> Bad style option: fixeduspos

So then I tried
Style acroread fixedussize

> (You may or may not want the fixed...size bit.)
Not sure I understand that comment in its fullness.  Sorry if I am
being thick.

This allows acroread to go into full screen mode, with two problems:
(1) it is spread across both screens, which is fairly useless, and
still isn't like the other programs I use which go into full
screen on just one screen, and
(2) I haven't mentioned this before, but another "feature" of acroread
in 2.6.6 is that once in full screen mode, it becomes
unresponsive to keyboard input.  I can scroll with the mouse
wheel, but keyboard commands are ignored.
(I should have mentioned this, but it was sort of a moot point if
full-screen mode isn't working anyway.)

> And if that doesn't help either, try

> Style acroread EWMHIgnoreStateHints

> (but that will probably prefent fullscreen mode from working.)
> There's also this annoying EWMH feature that allows windows to
> activate themselves at any time.  You may want to remove that or
> replace it with debug output when an application tries to do it:

> destroyfunc

Re: regression from 2.6.5 to 2.6.6 ?

2016-10-22 Thread zlists 
On Sun, Oct 23, 2016 at 02:23 (+0100), Dominik Vogt wrote:

> On Sat, Oct 22, 2016 at 10:00:16PM -0300, zli...@ns.sympatico.ca wrote:
>> On Sun, Oct 23, 2016 at 01:21 (+0100), Dominik Vogt wrote:

>>> On Sat, Oct 22, 2016 at 08:36:10PM -0300, zli...@ns.sympatico.ca wrote:
 On Sun, Oct 23, 2016 at 00:20 (+0100), Thomas Adam wrote:

> On Sat, Oct 22, 2016 at 07:56:31PM -0300, zli...@ns.sympatico.ca wrote:
>> I cloned the git version about 15 minutes ago and compiled it, and
>> acroread still does not go full-screen correctly.

> Can you reproduce this using a more accessible program, please?  I'm using
> FreeBSD.

 No, I can't.  That is, all other programs I use which have a
 "full-screen" mode work fine.

>>> All right, I can see that acroread generates some weird requests
>>> for new size and position.  For me, the size is good, but the
>>> position is totally screwed (x=65600, y=66000).

>>> In fvwm/events.c at line 1077 there is this debug statement:

>>> #if 0
>>> fprintf(stderr,
>>> "cre: %d(%d) %d(%d) %d(%d)x%d(%d) fw 0x%08x w 0x%08x "
>>> ...
>>> #endif

>>> Can you please replace the "#if 0" with "#if 1", rebuild and post
>>> the output that going fullscreen causes on the console?  (Don't
>>> move or resize any windows when doing this to reduce the amount of
>>> output.)  Also, please add this line to the fvwm config file (or
>>> type it in FvwmConsole before starting acroread)

>>> bugopts explainwindowplacement

>>> This will produce some more output that may be helpful.

>> I trust this is what you were looking for?

>> cre: 0(0) 0(0) 48(4)x96(8) fw 0x00400cb3 w 0x0201 ew 0x0201  
>> 'stalonetray'
>> [fvwm][__execute_function]: <> No such command 
>> 'explainwindowplacement'

> The command is

> bugopts explainwindowplacement

My bad.  I tried
FvwmCommand bugopts explainwindowplacement
as a replacement since I don't have a menu item to start up
FvwmConsole, and that was wrong.  But after I sent my previous message
I saw my error and started up the FvwmConsole, but I didn't see
anything which I thought was more interesting.  However, I don't know
what I am looking at, so here is the output *after* giving "bugopts
explainwindowplacement" to FvwmConsole:

cre: 0(1) 0(2) 1910(0)x1048(0) fw 0x00401cd3 w 0x06400031 ew 0x06400031  'Adobe 
Reader'
cre: 0(1) 0(2) 200(0)x200(0) fw 0x00401e30 w 0x064005c8 ew 0x064005c8  
'acroread'
cre: 0(1) 0(2) 3276(4)x1048(8) fw 0x00401cd3 w 0x06400031 ew 0x06400031  
'zshguide.pdf - Adobe Reader'
cre: 0(1) 0(2) 3286(4)x1080(8) fw 0x00401cd3 w 0x06400031 ew 0x06400031  
'zshguide.pdf - Adobe Reader'
cre: 65529(1) 65481(2) 3300(4)x1142(8) fw 0x00401cd3 w 0x06400031 ew 0x06400031 
 'zshguide.pdf - Adobe Reader'
cre: 0(0) 0(0) 3300(4)x1142(8) fw 0x00401cd3 w 0x06400031 ew 0x06400031  
'zshguide.pdf - Adobe Reader'
cre: 0(1) 0(2) 200(0)x200(0) fw 0x00401ed2 w 0x064005f1 ew 0x064005f1  
'acroread'
cre: 1165(1) 44(2) 1910(4)x1048(8) fw 0x00401cd3 w 0x06400031 ew 0x06400031  
'zshguide.pdf - Adobe Reader'

> Uh, even stranger than on my box.
I don't know of anything particularly weird on my machine, unless it
is my screen config:

xrandr
Screen 0: minimum 8 x 8, current 3286 x 1080, maximum 32767 x 32767
LVDS1 connected 1366x768+0+0 (normal left inverted right x axis y axis) 340mm x 
190mm
   1366x768  60.01*+
   1280x720  60.00  
   1024x768  60.00  
   1024x576  60.00  
   960x540   60.00  
   800x600   60.3256.25  
   864x486   60.00  
   640x480   59.94  
   720x405   60.00  
   680x384   60.00  
   640x360   60.00  
DP1 disconnected (normal left inverted right x axis y axis)
HDMI1 connected 1920x1080+1366+0 (normal left inverted right x axis y axis) 
520mm x 290mm
   1920x1080 60.00*+
   1680x1050 59.88  
   1280x1024 75.0260.02  
   1440x900  59.90  
   1280x960  60.00  
   1152x864  75.00  
   1024x768  75.0870.0760.00  
   832x624   74.55  
   800x600   72.1975.0060.3256.25  
   640x480   75.0072.8166.6760.00  
   720x400   70.08  
VGA1 disconnected (normal left inverted right x axis y axis)
VIRTUAL1 disconnected (normal left inverted right x axis y axis)

Earlier this evening I tried turning off the external monitor and
trying acroread in full screen, but even in that situation it still
doesn't do full-screen correctly.

>> Anything else I can provide?

> Yes, a couple of things please:

> 1. What size are your pages, and how many pages do you use on the
> desktop?  On which page do you do this?  Do you have FvwmPager
> running and can see more of the window on other pages?
As it is not, I have 7 desks, each of which has 1 page.  With two
screens as above, the pages are 3286 x 1080.

> If you have multiple monitors, please describe the geometry of
> this setup (coordinates and size of each monitor and on which one
> you expect the fullscreen window to appear).
Acroread

Re: regression from 2.6.5 to 2.6.6 ?

2016-10-22 Thread zlists 
On Sun, Oct 23, 2016 at 00:20 (+0100), Thomas Adam wrote:

> On Sat, Oct 22, 2016 at 07:56:31PM -0300, zli...@ns.sympatico.ca wrote:
>> I cloned the git version about 15 minutes ago and compiled it, and
>> acroread still does not go full-screen correctly.

> Can you reproduce this using a more accessible program, please?  I'm using
> FreeBSD.

No, I can't.  That is, all other programs I use which have a
"full-screen" mode work fine.  For example,
-> firefox
-> xournal
-> evince
-> chrome
-> opera
are all OK.  I may use other programs which work fine too, but
acroread is the one which does not go into full-screen mode correctly.

Re: regression from 2.6.5 to 2.6.6 ?

2016-10-22 Thread zlists 
On Sat, Oct 22, 2016 at 23:29 (+0100), Thomas Adam wrote:

> On Sat, Oct 22, 2016 at 07:26:50PM -0300, zli...@ns.sympatico.ca wrote:
>> On Sun, Jul 17, 2016 at 15:08 (+0100), Thomas Adam wrote:

>>> On Sun, Jul 17, 2016 at 08:38:10AM -0300, zli...@ns.sympatico.ca wrote:
 On Sat, Jul 16, 2016 at 23:27 (+0100), Thomas Adam wrote:

> On Sat, Jul 16, 2016 at 07:10:24PM -0300, zli...@ns.sympatico.ca wrote:
>> I recently upgraded a computer from Slackware64 14.1 to 14.2, which
>> bumped by fvwm version from 2.6.5 to 2.6.6.

>> With the new system, when I ask Adobe reader 9.5.5 to go full-screen,
>> I get a window with no decorations, but it only occupies about 3/4 of
>> the screen, off to the lower right.

> I'm hearing reports of this problem, yes.  Can you try this with
> the version from git (master branch)?  And send me your fvwm
> configuration file, since I can't reproduce this problem.

 The git version as of 10 minutes ago still has this problem, unfortunately.

>>> Thanks; I'll put a fix in later on.

>> Any chance of this getting in to 2.6.7, if it isn't already in?

> I thought I had.  The fact that you're asking suggests it would be
> helpful if you could test 'master' and report back any problems.

I cloned the git version about 15 minutes ago and compiled it, and
acroread still does not go full-screen correctly.

If you have a fix you would like me to try, or if there is something
specific I can report from my system which you need, just let me know.

Re: regression from 2.6.5 to 2.6.6 ?

2016-10-22 Thread zlists 
On Sun, Jul 17, 2016 at 15:08 (+0100), Thomas Adam wrote:

> On Sun, Jul 17, 2016 at 08:38:10AM -0300, zli...@ns.sympatico.ca wrote:
>> On Sat, Jul 16, 2016 at 23:27 (+0100), Thomas Adam wrote:

>>> On Sat, Jul 16, 2016 at 07:10:24PM -0300, zli...@ns.sympatico.ca wrote:
 I recently upgraded a computer from Slackware64 14.1 to 14.2, which
 bumped by fvwm version from 2.6.5 to 2.6.6.

 With the new system, when I ask Adobe reader 9.5.5 to go full-screen,
 I get a window with no decorations, but it only occupies about 3/4 of
 the screen, off to the lower right.

>>> I'm hearing reports of this problem, yes.  Can you try this with the version
>>> from git (master branch)?  And send me your fvwm configuration file, since I
>>> can't reproduce this problem.

>> The git version as of 10 minutes ago still has this problem, unfortunately.

> Thanks; I'll put a fix in later on.

Any chance of this getting in to 2.6.7, if it isn't already in?

Thanks.

Re: regression from 2.6.5 to 2.6.6 ?

2016-07-16 Thread zlists 
On Sat, Jul 16, 2016 at 23:27 (+0100), Thomas Adam wrote:

> On Sat, Jul 16, 2016 at 07:10:24PM -0300, zli...@ns.sympatico.ca wrote:
>> I recently upgraded a computer from Slackware64 14.1 to 14.2, which
>> bumped by fvwm version from 2.6.5 to 2.6.6.

>> With the new system, when I ask Adobe reader 9.5.5 to go full-screen,
>> I get a window with no decorations, but it only occupies about 3/4 of
>> the screen, off to the lower right.

> I'm hearing reports of this problem, yes.  Can you try this with the version
> from git (master branch)?
I will do so ASAP.

> And send me your fvwm configuration file, since I can't reproduce
> this problem.
In order to remove my config from suspicion, I created a new account
with no fvwm config files (and almost nothing else) and just used the
default config that Slackware provides.  Rather than me sending you
that, here is the whole thing that Slackware provides.

ftp://ftp.slackware.com/pub/slackware/slackware64-14.2/slackware64/xap/fvwm-2.6.6-x86_64-1.txz

regression from 2.6.5 to 2.6.6 ?

2016-07-16 Thread zlists 
I recently upgraded a computer from Slackware64 14.1 to 14.2, which
bumped by fvwm version from 2.6.5 to 2.6.6.

With the new system, when I ask Adobe reader 9.5.5 to go full-screen,
I get a window with no decorations, but it only occupies about 3/4 of
the screen, off to the lower right.

I removed fvwm 2.6.6 and installed 2.6.5 from Slackware64 14.1 and now
it does the former (and expected) full-screen behaviour.

Has anyone else seen this?

FWIW, this is on a Fujitsu T900 which has a 13.3" 1280x800 screen and
8GB RAM.

Thanks.

Re: fvwm repeatedly crashing

2016-02-17 Thread zlists 
On Tue, Feb 16, 2016 at 20:30 (-0500), Dan Espen wrote:

> zli...@ns.sympatico.ca writes:

>> Configuration Information [Automatically generated, do not change]:
>> Description:
>> fvwm occasionally crashes (a few times a day).

>> Repeat-By:
>> Since I've started trying to take note of when it crashes,
>> every time it was when I was
>> - switching tabs in firefox,
>> - opening a new tab in firefox, or
>> - closing a tab in firefox.
>> #2  0x00485deb in FlocaleFreeNameProperty 
>> (ptext=ptext@entry=0x25e9710)
>> at Flocale.c:2358

> If you print ptext->name it will probably be "Untitled".

It actually says
(gdb) print ptext->name
$1 = 0x2637de0 " \205c\002"
(which is a much weirder string than "Untitled"), but I'm happy to
ignore that and try the branch you refer me to below.

> It's fixed in the 2_6 branch in CVS.

> If you can, you might want to read through:

> http://www.fvwm.org/documentation/dev_cvs.php

> and get the 2_6 branch like this:

> cvs -d :pserver:anonym...@cvs.fvwm.org:/home/cvs/fvwm checkout -r branch-2_6 
> fvwm

> configure, then make.  There's a shell to help.

Thanks for the detailed instructions.  (Note that I don't love a good
hunt every now and then, but not today.)

I am now running the CVS code as of this morning.

Cheers.

fvwm repeatedly crashing

2016-02-16 Thread zlists 
Configuration Information [Automatically generated, do not change]:
uname: Linux nb2 4.1.2 #1 SMP PREEMPT Fri Jul 17 18:16:03 ADT 2015 x86_64 
Intel(R) Core(TM) i7 CPU   M 620  @ 2.67GHz GenuineIntel GNU/Linux
compiler flags: gcc -Wall -Wno-implicit-int -O2 -fPIC  

FVWM Version:   2.6.5
FVWM_MODULEDIR: /usr/libexec/fvwm/2.6.5
FVWM_DATADIR:   /usr/share/fvwm
FVWM_USERDIR:   /home/sd/.fvwm

Description:
fvwm occasionally crashes (a few times a day).

Repeat-By:
Since I've started trying to take note of when it crashes,
every time it was when I was
- switching tabs in firefox,
- opening a new tab in firefox, or
- closing a tab in firefox.
(I'm currently running ffx 38.6.0esr but this crashing problem
has been occurring on and off for quite a while, so it is not
specific to that particular version of ffx).  However, I'm not
certain that changing tabs in firefox is the only time it
happens.

Notes: here is some of the basic information as reported by gdb
--
% gdb =fvwm2 ~/core 
GNU gdb (GDB) 7.6.1
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-slackware-linux".
For bug reporting instructions, please see:
...
Reading symbols from /usr/bin/fvwm...done.

warning: core file may not match specified executable file.
[New LWP 26140]

warning: Could not load shared library symbols for linux-vdso.so.1.
Do you need "set solib-search-path" or "set sysroot"?
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

warning: no loadable sections found in added symbol-file system-supplied DSO at 
0x7fff4afcd000
Core was generated by `/usr/bin/fvwm2'.
Program terminated with signal 11, Segmentation fault.
#0  0x7f23e2250dbc in free () from /lib64/libc.so.6
Traceback (most recent call last):
  File "/usr/share/gdb/auto-load/usr/lib64/libgobject-2.0.so.0.3600.4-gdb.py", 
line 9, in 
from gobject import register
  File "/usr/share/glib-2.0/gdb/gobject.py", line 3, in 
import gdb.backtrace
ImportError: No module named backtrace
(gdb) where
#0  0x7f23e2250dbc in free () from /lib64/libc.so.6
#1  0x7f23e43a67a6 in XFreeStringList () from /usr/lib64/libX11.so.6
#2  0x00485deb in FlocaleFreeNameProperty (ptext=ptext@entry=0x25e9710)
at Flocale.c:2358
#3  0x004420ff in free_window_names (fw=fw@entry=0x25e9700, 
nukename=nukename@entry=0, nukeicon=nukeicon@entry=1) at add_window.c:3171
#4  0x0047ffbb in EWMH_WMIconName (fw=0x25e9700, 
ev=0x6d1780 , style=, any=)
at ewmh_names.c:175
#5  0x0042f110 in HandlePropertyNotify (ea=0x7fff4af29330)
at events.c:3628
#6  0x0042d874 in dispatch_event (e=e@entry=0x7fff4af293c0)
at events.c:4135
#7  0x0042e120 in HandleEvents () at events.c:4179
#8  0x0040b315 in main (argc=, argv=)
at fvwm.c:2591
(gdb) up
#1  0x7f23e43a67a6 in XFreeStringList () from /usr/lib64/libX11.so.6
(gdb) up
#2  0x00485deb in FlocaleFreeNameProperty (ptext=ptext@entry=0x25e9710)
at Flocale.c:2358
2358Flocale.c: No such file or directory.
(gdb) up
#3  0x004420ff in free_window_names (fw=fw@entry=0x25e9700, 
nukename=nukename@entry=0, nukeicon=nukeicon@entry=1) at add_window.c:3171
3171add_window.c: No such file or directory.
(gdb) up
#4  0x0047ffbb in EWMH_WMIconName (fw=0x25e9700, 
ev=0x6d1780 , style=, any=)
at ewmh_names.c:175
175 ewmh_names.c: No such file or directory.
(gdb) up
#5  0x0042f110 in HandlePropertyNotify (ea=0x7fff4af29330)
at events.c:3628
3628events.c: No such file or directory.
(gdb) up
#6  0x0042d874 in dispatch_event (e=e@entry=0x7fff4af293c0)
at events.c:4135
4135in events.c
(gdb) up
#7  0x0042e120 in HandleEvents () at events.c:4179
4179in events.c
(gdb) up
#8  0x0040b315 in main (argc=, argv=)
at fvwm.c:2591
2591fvwm.c: No such file or directory.
(gdb) quit
--

FWIW: 
(1) I'm using Slackware64-14.1 on a Fujitsu T900 with a Core i7 
M620, 8 GB of ram.
(2) I've let memtest86 churn away for a long time with no reported
problems.  No other program on my system is showing any problems,
so while I'm not certain that it isn't a bad hardware problem, I
don't see any evidence of that either.

I saved a couple of core dumps.  If further information from those
would be of use let me know.